Why are Climate models written in programming languages from 1950?

Bill Long is quoted. The author presents a comparison of generating Fibonacci numbers in Python and Fortran, and I don’t see why the latter is much less readable. Explicit typing adds verbosity but also clarity. The Python code with type annotation (recently added to the language) would resemble the Fortran code.

Why are Climate models written in programming languages from 1950?
By Sam Partee
February 21, 2021
discussed at Hacker News

Recently, a friend sent me a Wired article entitled “The Power and Paradox of Bad Software”. The short piece, written by Paul Ford, discusses the idea that the software industry might be too obsessed with creating better and better tools for itself while neglecting mundane software such as resource scheduling systems or online library catalogs. The author claims that the winners of the bad software lottery are the computational scientists that develop our climate models. Since climate change might be one of the biggest problems for the next generation, some might find it a bit worrying if one of our best tools for examining climate change was written with “bad software”.

In this post, I discuss the question of wether climate scientists lost the “bad software sweepstakes”. I’ll cover the basics of climate models, what software is commonly used in climate modeling and why, and what alternative software exists.

3 Likes

Because Fortran is hot!.

1 Like

Why are some people still talking the same language as Shakespeare four centuries ago? OK, the syntax and vocabulary evolved, but it’s the same.

More seriously, why so many people are still running UNIX-like OS, that old early 70’s stuff? 50 years old! In fact, UNIX-like OS have invaded nearly all computers for 25 years (except on the desktop!). Something like 1 billion smartphones are running that kind of old stuff. The reason is clear: UNIX authors were geniuses and the principles they put into UNIX were so pure and deep that they are still valid 50 years later.

Backus was also some kind of genius, inventing Fortran to enhance the productivity of programmers who were struggling with machine language.

Python is probably far better than Fortran to compute 40! or 80! because it will adapt the number of bytes of the integer to the needed size. So short and easy to write. I am sure that Backus would like it because programmers can spend less time programming (read its 1953-54 papers, it was its main goal). But if you want to compute 10000! it’s another problem…

Explicit and strong typing is better (absolutely needed?) for numerical computation. When every digit matters, the programmer needs to know how its numbers are stored and crunched. He knows not only about the butterfly effect but also catastrophic cancellation and many other numerical problems.

Fortran must be considered when every digit and every second matter.

1 Like

Fortran really suffers from the punched card malediction!
We could play a game:

  • counting how many Fortran wikipedia pages in the world are showing punched cards!
  • And how many are showing nowadays supercomputers? Or a modern scientific visualization of a big simulation?

See also my recent Wikipedia post:

Even the English Wikipedia page seems not so exciting for Fortran newcomers… Pictures are only about IBM 704, punched cards, Fortran 77 listing…

1 Like

as one that had the chance to see some of the codes they use i climate models I can point the following.

  1. they are not written in FORTRAN but mainly Fortran level of finesse varies but I did not see anything pre 80s.
  2. I have seen some C code written for climate modelling and while the syntax was c the semantics was f77…

fortran is still an evolutionary language even if not at the speed of python… and I will say not being at the speed of python is a good thing although being at the speed of fortran is not great either.

4 Likes

Indeed, the comparison between the Fortran and Python procedures would have been even closer if the Fortran function had been named “fib”, the unnecessary module wrapper removed, and the redundant “recursive” declaration for the function removed.

1 Like

This article, mentioned in comp.lang.fortran, is more informed about the use of Fortran in climate models: The authors complains about MPI and OpenMP, but coarrays are not mentioned.

What makes software engineering for climate models different?

by Steve Easterbrook
24. March 2010

  • The programming language of choice is Fortran , and is unlikely to change for very good reasons. The reasons are simple: there is a huge body of legacy Fortran code, everyone in the community knows and understands Fortran (and for many of them, only Fortran), and Fortran is ideal for much of the work of coding up the mathematical formulae that represent the physics. Oh, and performance matters enough that the overhead of object oriented languages makes them unattractive. Several climate scientists have pointed out to me that it probably doesn’t matter what language they use, the bulk of the code would look pretty much the same – long chunks of sequential code implementing a series of equations. Which means there’s really no push to discard Fortran.
  • Existence and use of shared infrastructure and frameworks . An example used by pretty much every climate model is MPI. However, unlike Fortran, which is generally liked (if not loved), everyone universally hates MPI. If there was something better they would use it. [OpenMP doesn’t seem to have any bigger fanclub].

@alin ,

Can you please elaborate on what you mean by, “being at the speed of fortran is not great”? Thanks,

@billlong ,

You’re quoted in that blogpost and the author appears to be familiar to you (a colleague?). Have you tried to (or are you able to) feedback your comment above directly to the author?

As mentioned also at comp.lang.fortran thread, the lack of mention of coarrays in connection with the climate models is disheartening.

Inadequate compiler support toward coarrays may have a lot to do with it.

Whilst taking a quick break at work, noticed a thread at another forum that was shocking to say the least: users shouldn’t running into problems like that with coarrays now for these are among the issues that hinder adoption: Running 2021.1 coarray programs - Intel Community

speed of change of the language. Fortran is not the fastest changing language and when one compares it with python looks like standing.
do not worry we still have the speed.
I have a nice joke about python… gives you numbers where even fortran fails.

1 Like

:joy:

Re: “speed of change of the language,” that is a severe concern we have with Fortran but unfortunately our concerns are shared by very few, or one can say almost no one.

Our experience is as follows.

Code base after code base migrates away from Fortran after remaining in maintenance-only mode for ages on account of having legacy FORTRAN-style constructs all over the code - like those in this recent comp.lang.fortran thread - that few young engineers want to touch.

But then when we try to comprehensively modernize the code or write new code particularly toward large or multi-team application developments using modern Fortran, our computational technology senior leads and managers find that so many of the well-established and proven good coding practices starting with

  • Explicit typing (sorry, requiring implicit none in every scope does NOT count as Fortran providing explicit typing),
  • proper Enums,
  • Generics,
  • Exception Handling for situations that truly are exceptions,
  • OO conveniences, etc.

are all either missing in Fortran or that the Fortran standard offers half-baked or token facilities for which the compiler support is so poor the first dozen or so attempts to write small test cases to explore the facility in the standard results in having to file bug reports with the compiler team(s) and wait 6 months to 2+ years or forever for fixes.

The ground reality is many of us are polyglots: we can write highly performant and cross-platform code libraries in modern C++ (C++14,17, and now 20 revisions and with Microsoft under Herb Sutter taking renewed interest in ISO standard support in their C++ compiler making a big difference) and/or C also making use of other powerful and more importantly, fast advancing libraries to achieve quite a few HPC tasks as needed. We can then have any number of bindings to UI-driven programs, cloud computing and/or mobile apps, interpreted environments, spreadsheets, other compute platforms to facilitate convenient consumption. Fortran can be entirely superfluous under the circumstances.

At the present rate, we reckon it will take at least 15 to 20 more years for modern Fortran to catch up to where we would truly prefer Fortran to be today i.e., in year 2021. This is simply based on 10+ years of successful use of certain good coding practices with other languages starting with Ada that had most of what we seek by 1990s to early 2000s. And this is assuming Fortran 202Y even adopts such feature sets - it’s highly unlikely given extreme resistances. The estimate of 15-20 years is based on the facts that it will be about 7 to 10 years or so until Fortran 202Y is published and about 8 to 10 years until two or more compiler provide robust (relatively bug-free) support for the facilities. In the meantime, outside of a few limited domains like the numerically heavy portion of climate simulations, so much else of scientific and technical coding will have no need for Fortran for sure.

The situation is really dire for Fortran in many scientific and technical computing domains: the only hope for it is the great efforts by @certik , @milancurcic , @everythingfunctional , and everyone working toward Fortran stdlib, etc. The pace needs to really pick up to turn things around for Fortran.

5 Likes

To be fair to the author, the article was published about 6 months prior to F2008 being approved, where coarrays first appear in a standard capacity. I don’t think I had heard about Cray or F-- coarrays in 2010, and neither had most of my colleagues (weather, ocean, and climate modeling).

1 Like

I really hate the picture of this “punched card” thing (and also the mysterious leading one space when I use “print *” statement also…). I don’t think putting such picture (of punched cards) in Fortran pages would give any appeal to newcomers.

(When I was a student, I had a real sample of physical punched cards in our group,
but never had a chance to use it for programming…)

1 Like

Experience with features invented by the standard committee without prior implementation shows that your time estimates are actually pretty optimistic. F’2003 gave the world parameterized data types (still not implemented completely in nagfor, or correctly in most other compilers); F’2008 introduced DO CONCURRENT as a serial construct(!) and pointer-valued functions as variables (still buggy or unimplemented in most compilers). Generic programming capabilities – like those in any of ML, Ada, C++, Haskell, or now Go (all different, pick one), not the basic overloading of Fortran’s generic interfaces – won’t be in the standard until 202Y at the earliest and won’t be in implementations until years afterwards, and any design issues discovered by the first implementations won’t be correctable because the problems will have been already baked into the document. If you want a templatized or otherwise generic standard linked list facility in Fortran without resorting to a source preprocessing facility (still not standard!), maybe you’ll be able to use one sometime in the 2030’s, a whole half century after ML & Ada figured them out. It’s frustrating.

4 Likes

I don’t have any knowledge of computer science - how compilers are made and so on… But I have a question - sorry if it is trivial.
Many times the issues are raised that compilers that support latest standards of Fortran catch up late. Then in what sense that standard say “This a feature implemented in Fortran”. There should be some compiler that standard committee must have implemented. For example - Fortran OO features have been implemented in 2003 standard. That means by 2003, the standard committee must have demonstrated all the proposed OO features in some compiler.
Similarly Fortran 2018 features must have been implemented in some compiler, for them to say Fortran 2018 supports these features . What is that compiler ? I don’t understand this delay in compiler support.

The Fortran Standard specifies (inter alia) what is a valid Fortran program and what the user can expect a valid Fortran program to compute. You don’t need a compiler to write these words. But you do need to think like a compiler, that is, mechanically.

Probably sometimes the standard will incorporate extensions already existing in some compiler.
But most of the time I think the standard committee defines new features, and the compiler editors follow. It’s like in a house: for example a new standard or a law says that electricity or thermal insulation must follow some new rules, and people building houses adapt themself to the new standard…
Of course, in the committee members there are people working on compilers: J3 Fortran - Current Members and other experts.

Thanks @vmagnin .
If I understand properly - it’s like architectural engineers and structural engineers. Architects (committee members) - plan and structural engineers (compiler vendors) - build.

Yes, but note that compiler vendors often send representatives to serve on the committee.