Fortran Standard Library

NAG Numerical Algorithms group has been around for decades

We are building a curated list of all open source Fortran libraries here: https://fortran-lang.org/packages/

> If Fortran has been around for this long without a standard library, then what do people use now?

The actual language, for example most of the functionality that in C is considered to be in the standard library (like I/O operations, mathematical functions) is implemented in the language in Fortran's case.

If the language is not enough for your particular case, you can use third party library like BLAS, LAPACK ...

> then what do people use now?

Language has basic string type (character array, really) and basic file access. People would use NetCDF or HDF libraries for reading and writing big numeric datasets. Algorithms, people would write their own when needed. For linear algebra, BLAS, LAPACK and (sometimes Intel MKL) is de facto standard, it's just not called a standard library.

Much is built in to the language spec, which then becomes a definition debate about what constitutes a standard library, not a useful debate in this context.

There are many popular "standard" libraries that people use like BLAS and LAPACK and domain specific code for say, mesh generation.

Also, most Fortran code is used for numerical calculation, most of what you need for that is already there.

As for compilers, there are still regularly released Fortran standards. The first proposal for what became Fortran was in 1953! The first compilers came a few years later. This was still on punch cards, and details of the syntax still remain from that era. Most of the standards are real standards and come with a date, Fortran 66, Fortran 90, etc. There have also been many branded releases tied to compilers. There are definitely differences in compilers on the edges, and the results you get can differ from one to another. But mostly they are the same with some compilers adding features specific to themselves.

Is there a need for this? Well there is some very commonly done linear algebra which you either have to write yourself or pick out a library, so it does make some sense to have these things standardized and included which would ease some burden.

Here's a reference to built in functions for a specific compiler:

http://docs.nscl.msu.edu/ifc/intelfor_lib.pdf

Fortran has some aspects of a standard library already, though compared to other languages the shelves are rather bare, let's say. It wasn't until Fortran 2003 that there was a standard way to get command line arguments. Before then different compilers had different ways to do that.

Most users of Fortran are only looking to crunch numbers. That's their application, and for that application Fortran already comes with everything you need, including a large standard library of mathematical functions and operations. I would argue that many users do not have much of a need for anything beyond multidimensional arrays, to be honest. I only know two people who have implemented linked lists in Fortran, for example. That said, it would be nice if Fortran had a good standard library. I would appreciate if Fortran had assertions, for example.

In my experience as a researcher in computational numerics, the “standard library” is going to be defined by the in-house code that I use. That code is going to use other scientific libraries like for example PETSc, Atlas/blas/mkl, MPI in the background, but the typically researcher isn’t going to be exposed to that because their focus is on setting up the equation Ax = b and writing the algorithm to solve it for x.

I wonder about the same thing. When I graduated in 1985 Fortran was already described more or less like you just did. However, when I recently dug down through the NumPy/SciPy stack to understand some details I saw a lot of Fortran code. Some popular algorithms seem to exist only as Fortran with various language interfaces on top.

So I don't think there are very many new projects being started but the presence of so much critical code in Fortran will extend its lifetime some more.

The vast majority of time on research supercomputers is used in running Fortran codes. (Click on 'languages' https://www.archer.ac.uk/status/codes/ , this is the UK national facility.)

And yes, as you've noticed almost all linear algebra is written in Fortran (BLAS, LAPACK, ScaLAPACK), so no matter what language you've written something to do some useful computation in, it's likely that most of the cycles are spent in Fortran!

I'm writing new Fortran right now, actually. I know a lot of people who still write Fortran, though all of them work in scientific or engineering fields.

I view Fortran as only good for number crunching, but for that purpose it is difficult to beat in many respects. Fortran is very common in supercomputing applications, though C and C++ are also very common. I know a lot of people who view Fortran as antiquated, and I understand their criticisms. I prefer other programming languages in general, but all programming languages are just tools and Fortran is a good tool in some circumstances.

The niche is numerical calculations. The strict semantics of the language allows for extremely good optimization of the generated machine code.

I have not kept up with recent developments, but Fortran has historically been noticeably faster than even C/C++ for numerical computations. This difference used to be quite stark due to limitations in C itself: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html (see " b) The design of FORTRAN allows maximal speed of execution:") I think things have gotten better in C, e.g. with C99's "restrict" keyword, along with general improvements in C compilers, but for a long while Fortran had a clear upper hand when it came to allocating and manipulating large arrays of floats. Outside of the language specification, I would wager that many supercomputers have better-optimized Fortran compilers than C compilers for this reason. And even if in principle C and Fortran can execute equally performant numeric code, Fortran's historic superiority has created a great deal of high-quality legacy Fortran code that nobody feels an urgent need to port into C (which would be tedious, expensive, and risky work).

In the modern day: R uses a standard Fortran BLAS implementation, as do many other libraries and platforms (NumPy, Numerics.NET, etc). LAPACK is also widely used for low-level numerical linear algebra: https://github.com/Reference-LAPACK/lapack Intel also maintains a BLAS implementation. So there's still a healthy need for a (small) community of Fortran programmers, it's not all about maintaining 70s legacy code. Very different than the situation with COBOL.

Good replies already. Also note that modern Fortran is an array language like Julia or Numpy, with parallel processing built in.

See for example MESA http://mesa.sourceforge.net/index.html an open source set of modules for software experiments in stellar astrophysics, which is still actively developed.

It's used quite widely in bioinformatics, at least in Australia. Over the last ten years I've written numerous web apps for scientists to provide user-friendly interfaces to their fortran command-line programs.

People in meteorological community still pretty much use fortran for everything, from input data processing, the atmospheric models themselves, to visualization. They already did distributed computing with fortran decades before kubernetes is a thing. Same with air pollution modeling (which is a subset of meteorology but handled by environmental engineers). I used to dabble with those models when I was studying environmental engineering.

When I did a PhD in theoretical/numerical physics, I wrote most of my code in Fortran. That was started ~5 years ago.

Basically, I was starting to port some some Matlab code I had written to C/C++ to speed it up, but the most convenient solver for the differential equations I was dealing with outside of Matlab turned out to be a Fortran library. So I started learning basic Fortran in order to write a small C++ wrapper around that library, but ended up liking Fortran much better than C++, so I kept using it throughout my PhD.

Note that modern Fortran (2008+) is not at all like the infamous Fortran 77. There's no reason to write GOTO spaghetti; you have object-orientation, built-in support for complex numbers and matrices, array slicing, pointers, polymorphism, pure functions, vectorized ("elementary") functions and subroutines, and other modern features. There are even some unique features like the "associate" keyword that I sorely miss when doing mathematical programming in any other language (mostly Python these days). Because e.g. the built-in arrays "know how big they are", error messages are typically more helpful than debugging numerical C++ too.

We're writing it for the ground processing for data from a new space telescope. Personally, I wish I was writing C++ or Python, but it does allow scientists to start writing code much more easily than C/C++ does, though Python is now more familiar to younger scientists than Fortran. Python has the downside of a lack of stability, however.

Fortan is pretty painful to write in. The lack of an STL means writing algorithms yourself. There is no good set of libraries, so you have to write more stuff yourself.

The string support is horrendous. Most of the language is based around clumsy fixed size strings. I wish they would add a new flexible string type.

The compiler quality is not up to C++ standards. My code currently has some nasty workarounds for problems in gfortran. It's not good to keep discovering compiler bugs.

I also find it's much vaulted numerical capabilities overstated. Vectorization only works in simple cases. You can't drop down to using SIMD wrappers to fix this. It's nice to be able to pass arrays around more easily than C, however. A good C++ array library would be better, but that would require everyone to agree on one.

I am one of the authors. We will pre-generate the files into a tarball, so that end users do not have to worry about generating it or have Python installed. Also we'll probably rewrite the preprocessing tool to C++ for robustness and speed. The reason we use it is that we need some easy way to generate the subroutines to work with any array dimension. There are not many other good options.