NEK for computational fluid dynamics moving to C++?

[Beliavsky]

@Certik has stated that the Fortran community should try to understand why important Fortran codes are migrated to C++. There are two versions of NEK, a fast and scalable high-order solver for computational fluid dynamics. NEK5000, described as “our classic” is mostly Fortran, and nekRS, “our next generation code … an open-source Navier Stokes solver based on the spectral element method targeting classical processors and hardware accelerators like GPUs” is mostly C++.

CFD is a common use of Fortran, judging from GitHub. Looking at the source of NEK5000,

dir /s *.f90 says

 Total Files Listed:
           9 File(s)        232,775 bytes

and dir /s *.f says

 Total Files Listed:
         309 File(s)      7,902,772 bytes

so it is possible that most of the code were never modernized. I know that one can use modern Fortran features in fixed source form code, but I don’t think this is common. The .f files don’t use allocatable arrays.

[shahmoradi]

I firmly believe in the accuracy of your hypothesis; people do not know about modern Fortran, because they have never been taught modern Fortran. I was taught F77 in graduate school. Had I not picked up Metcalf’s book by myself to learn Fortran2008, I would have also developed a sense of disconnection with Fortran and would have moved on to some other world.

[jacobwilliams]

The continued existence of F77 code and the insistence by the committee and compiler vendors that we have backward compatibility at all costs is killing Fortran. It’s very clear to me. No one who sees this stuff or has to deal with it wants anything to do with Fortran.

[certik]

Thank you @Beliavsky, very helpful. Yes, indeed I believe we should try hard to understand why codes are moving to C++.

I agree with @shahmoradi and @jacobwilliams. To clarify: I think it is technically possible to keep F77 code to keep compiling and working forever and have modern Fortran that does not need to carry around the “baggage”. (There are in fact many such ways, but one is to use a compiler option for older code, while the default options would only compile modern code.)

[Beliavsky]

@jacobwilliams

The continued existence of F77 code and the insistence by the committee and compiler vendors that we have backward compatibility at all costs is killing Fortran. It’s very clear to me. No one who sees this stuff or has to deal with it wants anything to do with Fortran.

If the committee removed fixed source form and compilers such as gfortran stopped supporting it, some groups that use Fortran would not upgrade to the latest version of gfortran, and that would slow the adoption of new Fortran features.

[pcosta]

Researchers at KTH in Sweden decided to use modern Fortran instead, and the approach shows promise .

Neko: A Modern, Portable, and Scalable Framework for High-Fidelity...

[everythingfunctional]

I predict that codes written today targeting specific hardware or parallel “assembly” languages (like mpi), will hit a wall when new hardware comes along, but code written using standards conforming modern Fortran will be (relatively) easy to port to new machines and parallel run-times.

As for the modern vs legacy Fortran battle, I’m taking the “win by proliferation” approach, and just writing lots of modern Fortran and making it publicly available. I’m on the fence about breaking backwards compatibility. I worry it will fracture the community and ecosystem more than it will push it to update. But I think subtle shifts in defaults might be able to tip the scale in a positive direction.

[milancurcic]

The first sentence of the nekRS README says:

nekRS is an open-source Navier Stokes solver based on the spectral element method targeting classical processors and hardware accelerators like GPUs.

It sounds to me like the motivation is to run on GPUs.

@shahmoradi

I firmly believe in the accuracy of your hypothesis; people do not know about modern Fortran, because they have never been taught modern Fortran.

I understood that the hypothesis was

@Beliavsky

so it is possible that most of the code were never modernized.

and that is correct, to the best of my knowledge. NEK5000 is a famously succesful F77 FEM Navier-Stokes solver over complex geometries that scaled to over a million cores. It seems unreasonable to me to assume that NEK5000 is F77 because its author has not been taught modern Fortran. It’s easy to learn modern features when you’re versed in F77. Reasons that seem to me more likely to not modernize:

• F77 works: modern features are not needed for the application
• Cost of development: time spent on updating the code to F90 or later could be spent on improving numerical methods, parallel scaling, physical processes, running simulations, etc.

F2018 would still not save it from a rewrite to C++.

[milancurcic]

@jacobwilliams

The continued existence of F77 code and the insistence by the committee and compiler vendors that we have backward compatibility at all costs is killing Fortran. It’s very clear to me. No one who sees this stuff or has to deal with it wants anything to do with Fortran.

I think backward compatibility has been one of the major reasons for Fortran’s success and remaining in active use today. Unfortunately, either statement is impossible to prove.

[certik]

As I said, I think it is technically possible not to break backwards compatibility.

The main issue is that modern Fortran tooling and community is just not on par with C++ yet. I think more natural defaults can be fixed with fpm and newer compilers (such as using free form and no implicit typing by default).

[Beliavsky]

The Fortran 2018 standard lists obsolescent features in section B.3.1 (quoted below), and Fortran compilers have options to warn about the use of obsolescent features and to turn those warnings into errors. I wonder what would be gained by deleting obsolescent features.

The obsolescent features are those features of Fortran 90 that were redundant and for which better methods were available in Fortran 90. The nature of the obsolescent features is described in 4.4.3. The obsolescent features in this document are the following.

(1) Alternate return — see B.3.2.
(2) Computed GO TO — see B.3.3.
(3) Statement functions — see B.3.4.
(4) DATA statements amongst executable statements — see B.3.5.
(5) Assumed length character functions — see B.3.6.
(6) Fixed form source — see B.3.7.
(7) CHARACTER* form of CHARACTER declaration — see B.3.8.
(8) ENTRY statements — see B.3.9.
(9) Label form of DO statement – see B.3.10.
(10) COMMON and EQUIVALENCE statements, and the block data program unit – see B.3.11.
(11) Specific names for intrinsic functions – see B.3.12.
28 (12) FORALL construct and statement – see B.3.13

[R_cubed]

@Beliavsky Is this essentially the same document that is listed as N2159 on the standards website as ISO copyrighted and for sale?

[everythingfunctional]

The link @Beliavsky shared is to the final “draft” of the standard before it was submitted to ISO for publication. As such it is not the actual standard and is ok to redistribute, but is so close to the published standard to make no difference as reference material.

DISCLAIMER: I’m NOT a copyright lawyer, so I may be wrong, but that’s the explanation I’ve been given by other members of the standards committee.

[R_cubed]

Thanks for the background. I ask because I wanted to look at the standard for myself, and see what could be done to address the issue of test case generation in this thread:

Fortran Compiler Testing Framework

The Fortran Testing Framework, FTFramework, a collection of Python and Bash scripts by Agustin Forero to enable easy testing of Fortran compilers using the Bash Automated Testing System (BATS), may interest compiler writers.

[MarDie]

I totally agree. Backward compatibility was a major advantage when people used punch cards and editing code was not an option. Today it is good practice to have unit tests and contiguous integration to ensure that modifications do not break anything. In the case of a backward incompatible change in a compiler or library, one simply spends the required time on modernizing the code until it works with the new version of the library or compiler.

Unfortunately, many developers never get used to incremental changes and modern software engineering practice. Now there codes are cruft and modernization is impossible or too expensive.

@Beliavsky: People who still use fixed form don’t use new features anyways. I find it strange to expect that a 1980 program runs on 2021 hardware and compiles with a 2021 compiler. Outside of the Fortran bubble, programmers with such expectations are not taken seriously.
@milancurcic: I would not call it a success that Fortran is mainly used for old projects. Even in science and engineering, which is Fortran’s core domain, C++ or even C are seen as better alternatives today.

[Beliavsky]

@MarDie

@Beliavsky: People who still use fixed form don’t use new features anyways. I find it strange to expect that a 1980 program runs on 2021 hardware and compiles with a 2021 compiler. Outside of the Fortran bubble, programmers with such expectations are not taken seriously.

Free source form codes are much more likely to use other new features of Fortran than fixed source form, I agree, but there are exceptions. Glmnet is a widely-used R package for “Lasso and Elastic-Net Regularized Generalized Linear Models” that uses the Fortran code here, which almost functions as a Fortran museum. It is fixed source form, and the first lines are

c     mortran 2.0     (version of 7/04/75 mod 7/4/87 (ajc))             
      subroutine get_int_parms(sml,eps,big,mnlam,rsqmax,pmin,exmx,itrace
     *)
      implicit double precision(a-h,o-z)                                
      data sml0,eps0,big0,mnlam0,rsqmax0,pmin0,exmx0,itrace0  /1.0d-5,1.
     *0d-6,9.9d35,5,0.999,1.0d-9,250.0,0/

Mortran is a Fortran preprocessor, created in the early 1970s, from Stanford, where several of the authors of glmnet are from. The code starts with implicit double precision and a data statement. Soon there are several entry statements:

      entry chg_fract_dev(arg)                                          
      sml0=arg                                                          
      return                                                            
      entry chg_dev_max(arg)                                            
      rsqmax0=arg                                                       
      return                                                            
      entry chg_min_flmin(arg)

However, the code also uses features from Fortran 90. There are allocatable arrays, declarations with ::, and even array operations:

      do 10101 j=1,ni                                                   
      cl(:,j)=cl(:,j)*xs(j)                                             
      10101 continue

Array operations in a block demarcated by do … continue instead of do … enddo are a special touch.

Use of the glmnet package is discussed in the highly regarded book An Introduction to Statistical Learning (freely available), whose 2nd edition was published this year.

So there are important Fortran codes where ancient and modern Fortran features are intertwined, and the Fortran community should not leave them behind. As a practical matter, if gfortran ever removes the dusty deck features, R developers will just standardize on an old version of gfortran, stifling developers who want to use a current version of gfortran with new features.

[certik]

@MarDie

@Beliavsky: People who still use fixed form don’t use new features anyways. I find it strange to expect that a 1980 program runs on 2021 hardware and compiles with a 2021 compiler. Outside of the Fortran bubble, programmers with such expectations are not taken seriously.

Actually, the very successful SciPy Python library does precisely that: it uses Fortran code from 1980s and it runs on today’s hardware, very well in fact. I also tested FFTPACK, written in 1983 I believe, and it runs extremely well on modern hardware with a modern Fortran compiler.

I agree with your overall sentiment, as I mentioned above. There is more nuance to this. But as I also mentioned above, we can have both! There is no reason why compilers could not compile older codes. And the language can still evolve, even in slightly backwards incompatible way if needed.

[MarDie]

This code with line numbers and and without indentation looks horrible to me, the little use of arrays does not make it better. No wonder that less and less people choose Fortran.

I have expressed my opinion on removing old features already on Formulate long term vision for Fortran in terms of features · Issue #59 · j3-fortran/fortran_proposals · GitHub, so I don’t think I need to repeat them.

As a final thought: You are proposing to continue as before, i.e. keep backward compatibility the holy grail of Fortran. Why do you think the something will change and Fortran will become popular again? This always reminds me of the saying Insanity is doing the same thing over and over again but expecting different results (not Einstein). Maybe it is time to try something new, leave the slow ones behind and focus on developers who do not ignore 40 years of progress in software engineering.

[MarDie]

I don’t say that we can’t have both, I’m just saying that it comes at a price. The price is that the language grows in complexity and new features are implemented slowly. Look at the new ifx compiler from Intel: Fortran 95 is feature complete (Intel® Fortran Compiler for oneAPI Release Notes) which means that obsolescent features are supported but F2003 to F2018 features are still missing. You probably also spend some of your time on implementing obsolescent features into LFortran.

I also find it nice to see that SciPy relies on code from the 1980s, but for the Fortran language it would be beneficial if this code would have been modernized to have a nice Fortran interface. I’m using LAPACK in Fortran and I understand everyone who prefers

invA = scipy.linalg.inv(A)

over

call dgetrf(size(A,1),size(A,1),invA,size(A,1),ipiv,ierr)
call dgetri(size(A,1),InvA,size(A,1),ipiv,work,size(work,1),ierr)

I also agree to you that community building and better tooling are also very important for Fortrans future.

[Beliavsky]

@MarDie

I also find it nice to see that SciPy relies on code from the 1980s, but for the Fortran language it would be beneficial if this code would have been modernized to have a nice Fortran interface. I’m using LAPACK in Fortran and I understand everyone who prefers

invA = scipy.linalg.inv(A)

over

call dgetrf(size(A,1),size(A,1),invA,size(A,1),ipiv,ierr)
call dgetri(size(A,1),InvA,size(A,1),ipiv,work,size(work,1),ierr)

There are Lapack95 and MFI: Modern Fortran interfaces to BLAS and LAPACK and similar projects. It should certainly be as easy to use Fortran libraries from modern Fortran as from Python, R, or Matlab, but deleting old features will not accomplish this.