A modern Fortran scientific programming ecosystem | Hacker News Reader

A modern Fortran scientific programming ecosystem

degenerateconic.com

117 pointsBostonian33 comments

> [Fortran] is great for technical and numerical codes that need to run fast and are intended to be used for decades. The libraries listed above will not stop working in a few years. An extremely complicated Fortran application can be recompiled with just a Fortran compiler. You cannot say the same for anything written in the Python scientific ecosystem, which is a Frankenstein hybrid of a scripting language hacked together with a pile of C/C++/Fortran libraries compiled by somebody else. Good luck trying to run Python you write now 20 years from now (or trying to run something written 20 years ago). Fortran is a simple and stable foundation upon which to build our scientific software, Python is not.

This resonates with me.

A lot of the code I wrote during my PhD was Python 2. It probably wouldn't run today without a lot of work. (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time.) I could have used Python 3, but at the time I didn't pay attention to what version I was using. I also used a lot of third-party packages when I should have minimized my dependencies.

I recently switched for Fortran for new scientific software largely because I expect Fortran code to last longer. I'm pretty paranoid about portability, too. I've used around 10 Fortran compilers now. I compile in standards compliance mode in most compilers. It's been interesting to see first-hand what's portable and what's not. I even got some code I've been working on recently to compile on Microsoft Fortran PowerStation 4.0 from 1995. Hopefully if it compiles on a compiler today and a compiler from 25 years ago, it'll still compile in 25 years?

> (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time.

Hm, a venv with interpreter is good enough and setup from nothing within 30 minutes still.. then if you have the right libs you are ready to go. Still doing that.

Most of my (admitted, simpler) scripts from 10 years ago usually run fine without any fuzz or even with later libs - good if one embraced py3 early and isn't stuck with py2 still after EOL ;) This sure depends on libs chosen and also implementor ( yeah I also know people who claim there code breaks ever few months... I don't know why).

I would claim that Fortran's stability only comes from the fact that ecosystem and libs were not really evolving anymore... you have that also in any compiled or also scripted language if you have these conditions or keep the stuff sround? In the end that's why numpy wraps Fortran libs! :D

> Hm, a venv with interpreter is good enough and setup from nothing within 30 minutes still.. then if you have the right libs you are ready to go. Still doing that.

I'm hoping that you're right as I'd like to eventually improve what I did during my PhD. The good news is that back then I asked someone to run my scripts on their computer as a check, and the main script apparently worked. So that indicates that my dependencies were fairly standard.

I did a program (12 years ago) for a course at University in Fortran. When I encountered few years ago, I manage to compile in Microsoft Fortran PowerStation changing the arrays from '[ ]' (something g95 used) to (/ /) (which I think is the real Fortran90 standard).

My master thesis is in Python 2 and uses several COM libraries. It has like 7 years old. It is impossible to rerun it.

I wrote https://github.com/toddjm/projects/blob/master/science/dqmc.... in 1999, and it compiles and runs just fine with gfortran on my Mac.

So I'd say you're good for at least 23 years :)

Modern Fortran is honestly a joy to work with. A large part of this is due to FPM; I've had a lot of problems in the past with building more complex Fortran projects (with FoBiS mainly) and dependencies have always been a bit of a hassle.

Also the author of the post has worked on some really cool stuff. They work at NASA JSC and their Fortran code is being used for the Artemis I mission (https://twitter.com/DegenerateConic/status/15615313400670617...) which is gnarly.

An interesting aspect about Fortran is, that it is remarkably high level even in its Fortran 77 incarnation and Fortran 2003 makes a fairly modern programming language if you don't touch the 'there be dragons' features.

Of course some old code bases with lot's of gotos cryptic variable names and fixed-form code layout look a bit atrocious, but the core is fairly solid.

I would like to take this opportunity and recommend the Modern Fortran book by Milan Curcic: https://www.manning.com/books/modern-fortran.

Thank you for sharing it!!

Welcome. Thank you for a great catch-the-Fortran-wave book. Pun intended.

Your examples are fun to follow and step out of the regular day-to-day distributed computing comfort zone.

I mentioned your book in my post on Fortran: https://gruchalski.com/posts/2022-08-28-i-enjoyed-modern-for....

> they are relics of the past, a reminder of what might have been if they had continued to be maintained

How do you “maintain” a computational algorithm that was carefully designed and withstood the test of time over decades?

This does read kind of odd. Reads as if the algorithms don't work anymore. Which... is at sharp odds for my understanding of why folks still use the basic linear algebra subprograms.

If anything, my understanding is that too many of the newer languages and runtimes are made with the idea that they must have the full tooling in the language and runtime. As opposed to in the past, where many of these subprograms would be written to be called from whatever software was being written for the machines.

I can think of a few ways:

- Hardware dies, logical or physical storage needs to be reloaded

- Algorithm is challenged as incorrect, needs to be tested

- Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values

- Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...)

and so on

I don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious.

That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed.

Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets.

But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?

Most of the old Fortran code isn't that great. To the extent it's optimized, it's optimized for PDP era hardware where memory was fast, floating point was slow, fma didn't exist, vectorization didn't exist, computers weren't fast enough to do tedious symbolic math to find better routines, and they weren't fast enough to test hundreds of millions of inputs to ensure correctness and accuracy. The datastructures, algorithms and tuning and testing were never great, and are worse on modern computers. For a simple example of how much of a difference this can make, look at https://github.com/JuliaMath/Bessels.jl which is often 10x faster than AMOS (the old reliable Fortran code).

I idly wonder how these compare to the arbitrary-precision implementations I worked on for REDUCE, exactly 30 years ago as it happens (https://github.com/reduce-algebra/reduce-algebra/blob/master...) - in its unusual Lisp-based but largely procedural language.

The citations in the Julia source file are certainly newer - Abramowitz and Stegun was basically all I had.

I think the REDUCE functions were considered quite fast (for higher precision) at the time, but it was certainly true that they weren't tested as thoroughly as would be the norm now.

bessels.jl only does fixed precision (most of the effort has been in Float64 and float32) currently, so it's not fully comparable. if you want to see state of the art arbitrary precision, check out ARB which has quite good implementations (they're what we test against to check accuracy)

"often 10X faster" is just plain exaggeration looking at it positively, and plain falsehood spread by the for-profit JuliaComputing, looking at it realistically. The statement does not even reflect the numbers posted on the project's page, which has, by the way, nothing to do with Fortran directly.

My read was that they are relic of the past in that they are written in Fortran 77 or earlier.

Fortran 90 and later are different enough to modern programming languages but Fortran 77 is an even bigger step back.

Check out the change log of OpenBlas: http://www.openblas.net/Changelog.txt

Some people seem to think these programs are ancient and unchanging. They're updated regularly. Otherwise they'd quickly be superseded by better implementations.

By keeping up with capabilities, features, and compatibility. The algorithm doesn't become wrong, but it and the implementation do get surpassed in utility.

Really great stuff, I would love never having to interact with python ever again and this is a nice to see.

At some point you'll want to do scripting to automate some stuffs so I don't think you could really fully get rid of it.

For someone who is happy that he will replace python with Fortran. I think he can replace python scripting with bash happier :)

You're right, of course. As for bash scripting, I love it and use it as much as possible.

My problem with python are largely with calisthenics regarding getting all the libraries and virtual environments to play nice, and I have a particular hatred for pandas.

N.B. I'm looking at all of this from the standpoint of a scientific computations guy, not as a software engineer or a "data scientist," so Fortran is in my blood.

Have you looked into Julia? It seems pretty promising for scientific computing.

No, if only because none of my employers have been using Julia - I don't tend to do a lot of coding outside of work these days so I kind of play the hand I'm dealt.

Give a go to R.

You don't need any fancy library to play with data.frames. And Rstudio makes very pleasant to work with.

Love R, it was great even 15 years ago as a start for writing an automated trading system (there were issues with memory limits and other factors that ultimately led me to switch to python).

As luck would have it, I'm presently auditioning for a gig that requires a foot in R and another in python. Rstudio is really wonderful!

> no obsolete constructs such as gotos

How do you deal with resource management? Do you create a wrapper type for those that don't have automatic destructor? (I'm surprised that stdlib doesn't provide a wrapper for files)

If you need to clear memory in the local scope, you need to deallocate a variable explicitly. Otherwise, all Fortran variables are cleared automatically when they go out of scope. One exception are Fortran pointers (different from C pointers) which are discouraged unless really necessary. We have a discussion for a high-level wrapper for files here: https://github.com/fortran-lang/stdlib/issues/14. So, it's in scope we just haven't gotten far with the design and implementation.

that's great even for not-so-complicated scientific projects. keep in mind that lots of commercial software in computational engineering are rely on FORTRAN for user defined sections and tweaking. for example ABAQUS in FE analysis.

Good to see that the third most important scientific computing language is getting some TLC

Reply on news.ycombinator.com