NEK for computational fluid dynamics moving to C++?

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.


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).

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

1 Like

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

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.


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:

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.

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.

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)                                          
      entry chg_dev_max(arg)                                            
      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                                                   
      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.

1 Like

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.

1 Like

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.

1 Like

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)


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.


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.

@MarDie I agree with your overall sentiment. I think we have already discussed this at the phone call, but I am always happy to discuss more. I love discussing precisely this topic.

I have slightly different perspective on some minor technical details, but I agree 100% with you on the overall picture.

Yes, we have to implement tons of obsolescent (even removed!) features in LFortran, otherwise it won’t compile SciPy, or established production HPC codes. However, I am in close contact with the SciPy developers and they are willing to change the Fortran code so that it would compile with LFortran. They are also interested in modernizing the code, precisely as you said.

So there is no philosophical disagreement, but the work still has to be done. I will be able to tell you the exact answer in about a year, once LFortran can compile most codes, but so far at least implementing some of the old features is not that big of a deal, the majority of my time is spent implementing the new features. The old features do not seem too much of a lost time, or technical debt in the compiler. But once everything is done, I will be able to tell you if that is still the case.

1 Like

I also like the discussion and normally I would not repeat my arguments from a previous discussion. But @jacobwilliams post was just too tempting.

It’s good to hear that SciPy is interested in modernization. I would be happy to contribute to this or other modernization projects.

1 Like

unfortunately, the “normal” LAPACK is the only version that is available on all systems (e.g. on Ubuntu) without extra effort. So it is a natural choice to use it.
I would be optimistic that there are volunteers that would modernize important libraries if that is needed. But as long as there is no need or incentive, it will not happen. A hint of the sort “your code is not conforming to the newest standard” could nudge people out of their comfort zone. A similar thing has happened when gfortran enabled stricter type/dimension checking. Sloppy code now compiles only with -fallow-argument-mismatch.

1 Like

What is motivating the SciPy developers to consider modernizing the Fortran code? Often the approach of Matlab/Octave, SciPy, and R developers is to leave working Fortran code alone, even if it is old-fashioned. What tangible benefits are envisioned to end users who will never look at the underlying Fortran and C code of the packages they use?

Sure some would try to do that. But so what? We’re going to lose those people anyway and their codes will die with them. Others will update their codes to modern Fortran, which is what we need going forward. It’s time to move on (long past time).


Re: SciPy. This is encouraging. Getting all that F77 code in SciPy converted to modern code should be a top priority of the Fortran community. It’s doing great harm to the perception of Fortran.


I have at least 4 reasons for modernizing old code:

  1. Remove optimization tricks that are not needed or even harmful today.
  2. Replace an algorithm by a better variant (numerical mathematics did not stop in the 80s of the last century).
  3. Improve readability and maintainability
  4. Implement parallelism.

Thanks. I am counting on you @jacobwilliams and @MarDie to help with modernizing SciPy. :slight_smile: I will be in touch in a few months. My first goal is to get LFortran to compile it. LFortran can actually convert the fixed form to free form already for the things it can parse. Converting to modules would be the next natural step, and so on.

1 Like