Live data from Hacker News

Why physicists still use Fortran (2015)

moreisdifferent.com

281–290 of 300 posts

Re: Why physicists still use Fortran (2015)

#281
I don't think the choice to continue using Fortran is as well thought out as the author. I work in computational physics and have written a lot of Fortran, C++ and Python.

The predominant issue is that physics codes are typically written by PhD candidates, often with little to no programming experience. The projects can span 3-5 years and continue existing in the physics ecosystem for decades. Good programming practices are seldom employed, and the codes become these massive patchwork ships, leaking everywhere with holes plugged by spaghetti code.

The issue is not that the students aren't smart enough to learn good programming practices, it's that the advisers are not patient enough to wait for documentation, unit tests and so forth. They view good practices as wasted time, after all it's "physics not computer science".

Unfortunately, the path of least resistance is actually to adopt unit tests, write code documentation and generally employ industry programming practices, it's just that this path has a barrier to entry and the benefits are not immediately apparent to older academics who have fallen out of the loop.

The end result is quite sad; students with advanced programming skills are chronically under appreciated in the field. Professors will happily bring them on board as post docs to develop their simulations, but they balk at giving them jobs based on their computational skill set. It is thus no surprise why the computational talent leaves physics and takes careers in the private sector where the union of math skills and programming is in high demand.

Re: Why physicists still use Fortran (2015)

#282
I remember when I was a junior engineer working on aerospace simulation software (defense contracting). I was primarily writing C++, but we had a large collection of physics algorithms written in Ye Olde FORTRAN that we had to link in.

I brought up a possible rewrite, and one of the greybeards told me that they had looked at that in the past, but the govt V&V process on any rewritten algorithms would have been so onerous that they eventually dropped the idea.

The last guy who actually understood that old code retired about a year after I started there and then things started to get... interesting.

As an aside, for 'new' code, I'm actually ok with the science folks dumping a pile of matlab script on me so I can rewrite it in Python, Java, etc. (rather than letting scientists write production code, which I'll have to rewrite later anyway).

Re: Why physicists still use Fortran (2015)

#283

I dont have much to add to this conversation but it surprises me that Rust hasn't come up in the comments. Would/could rust be appropriate for these kinds of use cases today/in the future?

In theory, yes. In practice, we need to get SIMD working on stable, which is underway but not done yet. We also need to get RFC 2000, const integers, implemented. And I'm sure other things too.

Basically, Rust could be excellent at this in the future, but right now, is merely okay.

Re: Why physicists still use Fortran (2015)

#284
post #78

Earlier quoted context omitted.

When I was working for LROC, most of the planetary geologists used IDL (Fortran-ish in many ways) but there was still plenty of actual FORTRAN floating around. Oh, look, in the last couple of years this legend of photometry worked up this new method and here's the associated Fortran code. That kind of thing. I did actually rewrite both IDL and Fortran, but it was always smallish, single-purpose programs or functions.…

Just before I left JPL, the SPICE team had announced a plan for a complete rewrite in C++. The SPICE team is exceptionally small (especially considereing how widely used and impactful the software has been). IIRC since the team’s inception, to the time I left, it has been about 4-5 people. Their primary goal has always been stability and correctness over speed. Recalling a conversation with Boris, they have something…

> Recalling a conversation with Boris

Good to know Boris is still there! Was Chuck still heading up the team when you left?

> a plan for a complete rewrite in C++

Oh, no! That's a real shame. I'd be all for a rewrite, especially considering their insane test coverage, but that decision worries me.

> That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change.

As someone who worked mostly with CSPICE in C but also with some other non-Fortran toolkits, I agree.

Re: Why physicists still use Fortran (2015)

#285
post #88

Earlier quoted context omitted.

Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. I would guess that a C++ codebase written by PhD students, not by seasoned C++ experts, is more complicated and much slower to debug, than a corresponding Fortran codebase.

The very fact that the article itself, with a completely straight face, has all that malloc nonsense in there as "the way you have to do it in C++" is very telling of how easy it is to get the wrong end of the stick with C++ unless you are au fait with the history of the language and its evolution to better more modern idioms

Re: Why physicists still use Fortran (2015)

#286
post #54
post #21

Earlier quoted context omitted.

I may be mistaken but I believe the Intel Fortran compiler supports the MS Fortran extensions

There are some caveats AFAIK. Intel changed some default behaviors. I believe you can change them with a command line switch though. Of note is the SAVE property on all local variables being the default on MS. Now that’s an insane default if there ever was any!

Sounds like it's "legacy" or "heritage" supported, which is not a good place to be. Yeah, it still manages to work, and it's available for use because it costs Intel effectively nothing to leave an installer up on the web for download, but there's no real "support".

That's not a piece of software I'd want to tie my code to.

Re: Why physicists still use Fortran (2015)

#288

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their students time, and also takes uncertainty out of the debugging process." This is so true. I'm a PhD student in physics using Fortran for pretty much that reason. At the start of my PhD, in response to my supervisor telling me I should learn Fortran to modify our cu…

"...and it took three phd students working full time for a year to rewrite their code from fortran to C++"

There's a salient lesson here. Clearly, this was a stupid decision for two reasons:

(1) there are many thousands of scientific routines that have had 40-60 years of fine honing and careful debugging and they just work! (For instance, we send voyagers—Voyager, Cassini, etc.—to the end of the solar system and they invariably get there; the Fortran routines that get them there do exactly what they're supposed to do (unlike much of today's poorly written C code)!

(2) Rewriting that already-reliable fully-debugged Fortran code into any other language will almost certainly make it far less reliable, thus it's a no-brainer to stick with the original .F source.

Yes, Fortran is simpler than C [consider it BASIC on steriods] and years ago it had long since evolved well past John Backus's 1954 incarnation of the language into solid workhorse that both physicists and engineers use regularly.

Just because something is old and out of fashion doesn't mean that it's broken or doesn't work well. (Longevity ensures that there's been sufficient time for many hands to make it reliable.)

(Oh, BTW, I'm reminded that decades ago when I was just beginning to learn Fortran using punch cards on an IBM360 mainframe with the WATFOR FORTRAN-IV compiler, that I made four errors in only six lines of code. After dutifully printing ERROR against each offending line, the compiler finished with the message: "YOU NEED TO SEEK ANOTHER CAREER " or words to that effect [yes, it was in uppercase]. Eventually, I got considerably better.)

Re: Why physicists still use Fortran (2015)

#289
post #153

Earlier quoted context omitted.

> I think functional-programming has more relevance to scientific computing What do you base this on?

Functional languages force you to be more correct, more often. Eliminates a bunch of classes of bugs which are anathema to scientific computing, and are generally so high level that compilers can optimize extremely aggressively. Also, scientific programming is usually much more about data flow and transformation, which is FP’s wheelhouse.

Do you have examples where it is the case that FP code yielded a superior scientific result?

Re: Why physicists still use Fortran (2015)

#290

Earlier quoted context omitted.

Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting? I don't know of any studies like this. But there are two aspects to consider. One i…

That is a good point, if the majority of the code is living in Fortran then there is definitely some value in understanding large legacy Fortran code bases.
Post reply on HN