Hacker News Reader

Julia is taking some inroads in climate modelling: "when the coder-climatologists of the Climate Modeling Alliance (CliMA) — a coalition of US-based scientists, engineers and mathematicians — set out to build a model from the ground up, they opted for a language that could handle their needs. They opted for Julia."

https://www.nature.com/articles/d41586-019-02310-3

https://clima.caltech.edu/

That's awesome, and not at all a surprise! It makes a lot of sense when building from the ground up to choose a great tool, and Julia has had some serious adoption in academia.

I think long term it has enormous potential to take over as _the_ language for modelling.

The reason is that for every hyper optimized climate model there are a thousand small or medium models. For these Julia offers sufficient performance and excellent developer experience.

It probably helps that Julia and Fortran are both column major.

When interfacing with C languages, that can be a big penalty (depending on the complexity of the algorithm).

It will probably take two generations of developers to make this happen, but well worth it. When I was studying atmospheric science I tried to understand OpenWRF (weather research forecasting) and the barrier was too high... And I had programming experience, imagine those with none!

An open source project is only as useful as it is accessible to it's average developer base.

Although Fortran compilers may produce fast code (they have to - there's no chance to play with SIMD intrinsics or templates unless you want to use C++), I don't find them very good. I've personally hit several bugs in gfortran. The code I maintain now has some extremely ugly hacks to work around unfixed compiler bugs. I recently tried compiling it with Intel Fortran and got a compiler crash on one input file. Maybe they work well with Fortran 77 level code, but the Fortran 2003 level support seemed rather buggy. I suppose this is the problem with a minority language.

I won't recommend Fortran unless the code has to be written by scientists who know nothing else. It has horrible string support, no data structure or algorithm library (like STL), no templates, few non-numeric libraries (e.g. http, json...) and (as above) buggy compilers. Furthermore, C++ gives you much more control over numerical speed when you need it.

"It has horrible string support", this is untrue. Learn Fortran 2003, 2008, 2018.

What? Where is this good string support in Fortran 2003, 2008 and 2018? I must have missed it in the manual. Now you can allocate a string of a non fixed size - simply amazing technology! Actually, one of my compiler crashes was trying to use this revolutionary feature.

> Now you can allocate a string of a non fixed size - simply amazing technology!

That’s more than what C gives you out of the box ;)

Many languages forbid mutable strings. They aren't really a very good idea, imo. Even less of a good idea are extensible strings. More complex data structures are required for efficient extensible strings, and this complexity shouldn't be hidden in a simple interface. Better to have a Buffer type or something that is distinct from the String type so programmers are made aware of the performance/allocation characteristics.

Though, this is kind of ridiculous to even talk about, since the CPU and compiler itself are responsible for the greatest sins of hiding something unimaginably complex behind a simple interface.

Ah, the joys of the 6502 and the Commodore 64!

Delphi had mutable xor aliased strings. That is really great. Each function can change the string as fast as a mutable string, but once it shared with other functions, they can be certain that it will not be changed randomly

Or just bite the bullet and learn how format statements really work. ;)

We could never use gfortran, and other open source compilers were not really great for us either. We used Intel's fortran compiler, and it stood out as a pure gem. At the time it was free for educational/research purposes, which is why we used it, but if we had to pay (I think the license was like $1k/yr) we would have done it in a heartbeat.

Our code was entirely FORTRAN 66 and 77, so that may explain why it worked so well for us.

Have you tried Flang? It’s LLVM's fortan compiler and was written from the ground up to support FORTRAN-2018

Nope, I left the field in 2012 so haven’t kept up to date at all, sounds cool though!

I wonder if when global warming starts eating coastal cities will the government have to seek out centenarian fortran programmers to analyze the climate models?

(like the new jersey unemployment system in cobol)

:)

I'll do the same thing they did and ask for a shit ton more money :)

Though the beauty of fortran to me is really how easy it is to learn and make working code. That said - it's not elegant at all, probably a feature.

Ditto this, I've run into some strange compiler bugs I've had to work around. Intel Fortran 2019 actually fails to compile a code at work that's worked for ~40 years, Intel Fortran 2018 compiles it but produces numerical errors when the code runs. Intel Fortran 2016 actually works perfectly, as do several earlier versions.

With gfortran I run into issues primarily when using the "newer" features of Fortran 2003/2018.

> we had a huge ordeal converting our 32-bit space weather model to 64-bit because the change in precision changed our results, so we couldn't publish (in good conscious) without making sure the results weren't within a good margin of error

This is a really interesting dimension to the transition that I've never considered before. An actual change in correctness, not just compatibility. I would have thought for floats it would just add more decimal points

FWIW, I didn't bother getting too deep into an analysis (I was an undergrad and not really savvy enough to deep dive, but maybe I could now if I went back :) )

Our model was a space weather model of the solar wind speed and density - it was very iterative, and I think that iterative nature is what contributed to quirks in the transition - think of the issues when summing say, 0.1 ten times in Python (or other languages) - ultimately, we didn't need to do any real work to show that our converged model was within a margin of error and still presented the same results in terms of predicting solar flares - but it was still a lingering curiosity that the numbers weren't exactly the same (as you say!) - most of the work was done in finding the right compiler parameters to not break existing code, while taking advantage of the larger memory space.

Ah that makes sense

One of our numerical analysis(NA) professors had worked at NASA, at IBM and had enormous real-world experience in NA. Several weeks into the class he challenged us to write a correct square root routine in FORTRAN. Over the next two weeks submissions were presented in class, where our professsor showed how each had multiple critically fatal errors. He let it stew awhile: two weeks before semester's end he presented and explicated to us a correct implementation of the square root, which turned out to be far more lengthy and involved than we had imagined. He said there was always the possibility of more bugs being present. That was really an eye-opening class.

Post the code here, and educate us.

musl sqrt is here, about hundred lines of code with nice explanation on top. Considering that it has 1993 copyright stamp, I'd imagine it is fairly canonical implementation

https://git.musl-libc.org/cgit/musl/tree/src/math/sqrt.c

I saw that done years ago in assembler for UNIVAC mainframes. Tear apart the exponent and mantissa. Shift mantissa if exponent is odd. Shift exponent right one bit to get square root of exponent. Look up starting guess from table using a few high bits of mantissa. Run two iterations of Newton's method. Reassemble mantissa and exponent. Normalize. Done.

Is it possible to keep ulp precision in all cases after doing all that separation, normalization, and recombination?

I came here to ask whether your typical Fortran program would carry the coding security risks that Rust is designed to mitigate; I couldn't think of any. Your comment seems to confirm my doubts.

It probably wouldn't have affected my work at all. We were running our code as a monolith - it was the only thing that ran on any given machine, and its output was stored on a large filesystem on NFS.

That's not to say there isn't someone out there with this concern :)

https://www.fortran.io/

For example.

More seriously, I could imagine a security flaw in numpy wreaking all sorts of havok. But it's also somewhat difficult for me to imagine that there are any security vulnerabilities left in BLAS. But then I remember Heartbleed.

I think „coding security risks“ referred to language properties that increase the likelihood of introducing bugs in a general sense, not in terms of cyber security/hacking.

Memory errors also affect correctness.

Forgetting to initialize that last entry or initializing one too many entries by accident can cause random, very hard to track down, issues.

Security? Perhaps if your code is pulling chunks of data from a cloud source?

You are right, I forgot to mention correctness.

> we had a huge ordeal converting our 32-bit space weather model to 64-bit because the change in precision changed our results, so we couldn't publish (in good conscious) without making sure the results weren't within a good margin of error.

Had you done some kind of external validation of the original results? If not, surely the new results are just as valid to publish as the original ones - any bugs are as much or more likely to be in the 32-bit than the 64-bit version.

Yep. Our model was run by other organizations and incorporated into amalgamated models that had further downstream error bars that they needed.

Not that our model contributed much but we were one tiny part of the early warning system for solar flares for satellites and astronauts.

We admittedly weren’t super formal about the transition but wanted to make sure the differences wouldn’t be meaningful or propagate into other models we contributed to.

Also fwiw, we had no control or say over how others ran our model so they could have easily done their own 64 bit build of our code but I think it’s unlikely.

> There's a ton relating to precision - we had a huge ordeal converting our 32-bit space weather model to 64-bit because the change in precision changed our results, so we couldn't publish (in good conscious) without making sure the results weren't within a good margin of error.

That sounds like a question of numerical stability of the algorithm, rather than anything to do with the programming language, no?

Yep. Fair point. The folks I worked with were very pragmatic so didn’t get into the internals and just treated the code as the instructions. Many of them came from an earlier era where the code was a lot more specific and the concept of an R8 is not quite as specific on x86_84 as it was on a VAX because the modern CPU does a lot of tricks under your nose.

"in good conscience"

Nice catch, thanks!