An evaluation of risks associated with relying on Fortran for mission critical codes for the next 15 years

This is a report written by some of my former colleagues at LANL. I asked them to correct a citation from our “State of Fortran” paper (update: they cited the introduction, not the conclusion, so it is actually accurate citation). I spent hours discussing with LANL managers about exactly the issues touched in the paper. In 2019 I asked them, give us 3 years, before making the decision on Fortran. And to their credit, they did. As you know, I gave it my absolute best, and I described some of our efforts in Resurrecting Fortran, and the “State of Fortran” paper and in the LFortran effort (which is doing great btw!). Changing culture about Fortran is hard, and I think I made a non-trivial dent in the direction of the ship, but not enough. I am of course sad to see this, as LANL might be the last National Lab with mission codes in Fortran. Sandia and LLNL already moved pretty much fully to C++.

One can argue with details, but the arguments in the paper are to be taken seriously. In fact, if I was in their shoes, I would maybe have to make the same decision to move from Fortran to C++, it’s a complex decision that involves hiring, maintaining, mission success, tax payers money, and technical reasons. If anyone here doubts what is written in the report, you can simply ask me, and I am happy to support their argument. Yes, of course if I was in their shoes I would investigate an option to fund Fortran tooling. But at some point it is just not possible to justify it to the sponsors and the people involved, that is just the reality.

A simple technical reason is that it’s always best to use just one language for a big project. This is based on my personal experience, but many programmers agree (although not all). The minute you start mixing C++ and Python, or Fortran and C++, you are suddenly requiring people to understand both languages, and unless they are clearly separated (which they are typically not in these computational codes), you need to debug and develop in both languages. That’s a major problem, even for me. I know all three languages really well. And yet you can notice that I do not mix them in any of my projects.

To fix it, either move all into Fortran or all into C++ or all into Python. Don’t mix. If you have to mix, separate into independent modules or layers.

Anyway, I could write pages about this problem. I’ve worked at LANL for almost a decade, I know the people well, they are all great. I’ve discussed this at length with anybody willing to listen and they do. I have been really trying to discuss this very problem with the J3 committee, including my very first meeting in 2019. I am afraid I was not very successful there. I am not even talking about the solution (see the next paragraph), just acknowledging that there is a problem.

Now the solution: Not all is lost for Fortran. We have to be doing exactly what we are doing, and get new people to use Fortran and use it for projects and work on improving the basic tooling (compilers, fpm, etc.). That’s it. We have to build the community from the ground up, and that will fix Fortran, because it changes the culture and people see active projects, successful compilers, lots of energy in the community and then it’s much easier to justify using Fortran instead of other languages for big projects.

19 Likes