SoylentNews is people
SoylentNews
from the it's-called-FORmula-TRANslator-for-a-reason dept.
While it may not be widely appreciated, the Fortran programming language is still a thing. Last year, NASA ended up being overwhelmed by the sheer number of responses to their contest to optimize a Navier-Stokes equations solver used to model aerodynamics, to be evaluated on the Pleiades supercomputer. Fastest implmentation would have won the first prize, however there were far too many to evaluate. Fortran is quite old but neither outdated nor complex and nothing beats it for number crunching. So in many cases it is still the right tool for the job.
Many thought that the competition will never start due to the lack of applicants. In fact, it was cancelled for the exact opposite reason.
Quoting NASA's Press Release: «The extremely high number of applicants, more than 1,800, coupled with the difficulty in satisfying the extensive vetting requirements to control the public distribution of the software made it unlikely we would achieve the challenge's original objectives in a timely manner.»
Next up, MUMPS?
(Score: 2, Informative) by Anonymous Coward on Wednesday November 28 2018, @10:46PM
There are different jobs, and FORTRAN is good in one, while modern languages are in another. Messing with them ends with bad results and difficult code.
Most FEA packages use internally some FORTRAN in their solvers and C/++ in their "user" (pre/post) and I/O modules. Code in FORTRAN just well reflects the method used there and how it is figured out. Some time ago I tried with FEA library in C (as I had a small pre/post processor made in C), and it was hard to understand the method as the algorithm was not directly visible in code. FORTRAN is just a description of purely mathematical algorithm. FORTRAN naming convention, inherited from serial compilers in old mainframes, forces some organization. For example, if a function has a PC at its beginning I know that it'll be a preconditioner. "PCILU" is quite self-explanatory for maths-oriented people.
FORTRAN library has to be well documented. Look at the PETSC docs, that's how a good documentation looks like. This way, we can (developing our code) slowly call things up to do parts of method for us.
If we have to do more system-related things, that's when FORTRAN stops to be useful. I just cannot imagine developing a GUI pre/post processor in FORTRAN. I know that such attempts have been made, but in this field C/++ with proper toolkit is just better.
P.S. Meanwhile in a quite expensive CFD package's solver code in C:
"void call_when_interpolation_is_the_way_to_go_but_for_data_it_isnt()" called on globals.
(taken from incidentally unstripped debug info)