Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are most climate models in Fortran?

partee.io

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Why are most climate models in Fortran?

#81

Post by leephillips »

yodelshady wrote: post #56
cbkeller wrote: post #14

High performance scientific computing is very much still a FORTRAN, C, and C++ game. And of those, FORTRAN has some compelling advantages in terms of first-class built-in support for multidimensional arrays, and quite excellent compilers. And, as others have noted, until the `restrict` keyword in C99, there were optimizations in FORTRAN that were not even possible in C. I mostly used C for my (small-scale) HPC work i…

Open question: why are multi-dimensional arrays, and matrices specifically, so neglected in almost every other language? They map well to practically freakin' everything , for what seems like.. not that much effort on the language design side, but an enormous amount of tedious, duplicated effort on the user side.

That’s one reason why APL and its descendants are so powerful in the hands of people who have become fluent in viewing computation through the lens of arrays.

Re: Why are most climate models in Fortran?

#82

Post by tzs »

hilbert42 wrote: post #3

1. There are thousands of scientific subroutines written in Fortran that are stable and well tested - in fact, there are well established formal libraries of them that go back over 60 years. The researchers know and trust them. 2. Despite the sneers and derision that Fortran has been subjected to from non-Fortran programmers over recent decades, Fortran is an excellent language to do intensive scientific and mathemat…

> From the outset, it could handle complex numbers, double precision, etc., etc. natively without having to resort to calling libraries/special routines as other languages had to do back then.

At least until sometime in the '80s another advantage of Fortran over C was that it could handle single precision floating point. C always promoted float to double when you did arithmetic with it.

Arithmetic was faster on floats than doubles, and that could make quite a difference in a big simulation that was going to take a long time to run.

The high energy physics group at Caltech back then had a locally modified version of the C compiler that would use single precision when the code tries to do arithmetic on floats. Some of the physicists used that for programs that otherwise would have been in Fortran.

Re: Why are most climate models in Fortran?

#83

Post by bodhiandpysics1 »

TazeTSchnitzel wrote: post #63
pjmlp wrote: post #18

Earlier quoted context omitted.

And like in everything C, unlike Fortran, there is no way for the compiler to validate if restrict is being used properly. Use it wrong, break the compiler assumptions and the bug hunting fun starts.

How does Fortran enforce this, actually? Does it just not let you pass the same array to a function via multiple parameters?

Fortran didn't originally have pointers, and pointer based code is relatively rare in fortran, so making requirements about pointer aliasing doesn't have same potential to completely break your code that it does in c. The reason c can't actually restrict the restrict keywoard, is that the standard would break code!

Re: Why are most climate models in Fortran?

#84

Post by readflaggedcomm »

readflaggedcomm wrote: post #6
hilbert42 wrote: post #3

1. There are thousands of scientific subroutines written in Fortran that are stable and well tested - in fact, there are well established formal libraries of them that go back over 60 years. The researchers know and trust them. 2. Despite the sneers and derision that Fortran has been subjected to from non-Fortran programmers over recent decades, Fortran is an excellent language to do intensive scientific and mathemat…

Tested in the sense of test suites and formal proofs? That would be valuable to other disciplines using other tools. But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me. I applaud anyone using a tool that works for them, but if it's good, then its users have accomplis…

Remind me not to compliment Fortran in the future, HN hates it.

Re: Why are most climate models in Fortran?

#85

Post by mixedCase »

lambda_obrien wrote: post #76
cbkeller wrote: post #70

Earlier quoted context omitted.

That is a great question, and while I don’t know for sure, I think a relevant anecdotal observation that stands out to me is that many languages which do have first-class multidimensional arrays also have one-based indexing. And I would speculate this in turn is because most people who wanted matrices badly enough to make them a language feature wanted to do linear algebra with them, where you generally also want one…

I don't get why a language can't have both 0 and 1 based indexing, just set it as a compiler flag or something. They are a homomorphism, it's not hard to add or subtract one.

That sounds like it belongs in the top 10% of the worst (programming-related) things I could wish upon another programmer: Having to maintain projects where you have to read the build system's configuration and keep it in mental context just to figure out if an array access is mathematically correct or not.

I would imagine this support to be stomachable if it was active at all times but using a visually different syntax for 0-based and 1-based indexing, maybe using something like the guillemet for the latter (like this: «1») that is wild enough to draw the user's attention when reading the code, and not common/prominent enough across keyboard layouts to make most users think twice before using it when writing code unless it makes sense for the domain.

Re: Why are most climate models in Fortran?

#86

Post by cbkeller »

chris_va wrote: post #79

(disclaimer: I work in a Climate&Energy R&D Lab) I don't entirely agree with the overall assertion of this article. The author has some valid points, but I think it misses the forest for the trees. TLDR: I think Fortran tooling and HPC clusters are a self-reinforcing local maximum. They are heavily optimized for each other, but at the cost of innovation and extensibility. For example, we'll never get a fully differen…

Well Fortran was, notably, one of the first languages to have proper source-to-source autodiff (TAPENADE) [1-3], so it’s probably not impossible, though my choice for a fully differentiable climate model would personally be Julia, like the CliMA folks at Caltech [4].

[1] https://doi.org/10.1145/2450153.2450158

[2] http://www-tapenade.inria.fr:8080/tapenade/index.jsp

[3] http://www-sop.inria.fr/ecuador/tapenade/distrib/README.html

[4] https://clima.caltech.edu/

Re: Why are most climate models in Fortran?

#88

Post by tianlong »

These considerations are valid also in another fields such as in computational quantum physics/chemistry. Major software are written in Fortan and in C++. I work in the ML community now, after many years of quantum chemistry and when I say that I know Fortran people usually laugh :).

Re: Why are most climate models in Fortran?

#89

Post by pron »

IshKebab wrote: post #87
pron wrote: post #30

Earlier quoted context omitted.

Neither do languages, especially formal ones.

FORTRAN isn't a formal language though.

Of course it is, just like all programming languages. If it weren't formal, a computer couldn't interpret it precisely. Formal means mechanical; a language whose calculus can be carried out by a machine.

Re: Why are most climate models in Fortran?

#90

Post by IshKebab »

dgellow wrote: post #27

I'm not familiar at all with the world of high performance scientific computing. Are C++, Rust, Nim, Zig, & co. even remotely considered as potential candidates in the future, or is it really only C and Fortran with no expectation to see much changes? Just curious.

I haven't read the article but in my experience FORTRAN is used because a lot of really complex numerical routines were written years ago by really smart people in FORTRAN and nobody really wants to rewrite them. There are exceptions - the basic LAPACK stuff has modern alternatives (e.g. Eigen for C++, nalgebra for Rust).

But there are a ton of more specialist libraries, e.g. ARPACK that people probably aren't going to rewrite.

That said, there's a FORTRAN to C transpiler that works pretty well. I used it when I needed ARPACK and didn't want to deal with FORTRAN.

Post reply on HN