Live data from Hacker News

Why physicists still use Fortran (2015)

moreisdifferent.com

141–150 of 300 posts

Re: Why physicists still use Fortran (2015)

#141
post #121

Earlier quoted context omitted.

Large-scale Atomic/Molecular Massively Parallel Simulator (LAMMPS) is written in C++ and it's over 20 years old. The FORTRAN codebases seem to be centered around the finite elements/difference methods and the fluid dynamics community.

Sorry, I wasn't specific. My comment mostly applies to the quantum mechanics (QM) community, rather than molecular dynamics. In QM, many people still run Gaussian/GAMESS/ADF/MolCAS/MolPro/Dalton, which are all Fortran (or majority Fortran). And most are Fortran 90 or earlier. My background is in QM, so I guess that's my bias showing through :)

Even in Molecular dynamics, there's dl_poly, for instance. Other things that come to mind in Fortran apart from nwchem are cp2k and castep.

Somewhere under http://www.archer.ac.uk, there's a summary of the time used by various codes on that UK "Tier 1" system.

Re: Why physicists still use Fortran (2015)

#142
post #133

Earlier quoted context omitted.

Well, it's moving, not moved yet. New libraries are being written in C/C++, and maybe Python. This includes libraries that should form the foundation of the QM community (matrix/tensor and integral libraries). These are meant to take advantage of newer hardware and libraries which themselves are written in C/C++, and often in a way that is inaccessible from Fortran. The old Fortran code will be around for a long time…

I don't understand why the implementation language of low level libraries should determine a high level language that uses them. In what way are C libraries inaccessible from Fortran, given that it defines interoperability with C? I'm afraid you need a 10-, or preferably 20-, year perspective, not a week.

I have been developing in Fortran for years. I just mentioned that as an aside.

About C compatiblity: Many C libraries use pointers in their interfaces. Interoperability is indeed defined by the Fortran 2003 standard, which I have used several times to wrap existing C libraries. However, much of the existing code is F90 only (some even F77...), and a vast majority of Fortran developers in the field are not familiar with even modules and other F90 features, let alone iso_c_binding in 2003.

Also, newer libraries tend to be C++ as well, which is more difficult (or at least more awkward) to wrap.

Re: Why physicists still use Fortran (2015)

#143
post #80

Earlier quoted context omitted.

That was without a doubt pretty bad for those grad students' careers. That kind of work shouldn't have been done by anyone without tenure.

I don't know. Having "rewrote X kloc of scientific Fortran to modern idiomatic C++" on your CV should get you to the head of the line in many places when looking for a job.

Why would you rewrite something that works well instead of just linking to it?

Re: Why physicists still use Fortran (2015)

#144
post #81

Earlier quoted context omitted.

Kind of, compilers don't enforce correct use of restrict which opens the doors to strange errors, as it is UB if they actually do overlap. Which is the main reason why ANSI C++ members are not keen in having restrict in C++.

Agreed. However, C++ pragmatically does have restrict in both clang and g++, which is still useful in cases where you can deductively prove the lack of aliasing.

There are more compilers out there, although I do agree in the context of HPC, those are probably the most used ones.

Re: Why physicists still use Fortran (2015)

#145

Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why fortran" articles (on both sides) I find are written by people who don't dabble enough on both sides of the fence, and are ignorant of what either side offers. For example, numpy implements a lot of the stuff from fortran the author listed, like broadcasting oper…

C++'s generic-programming feature still has shortcomings - I think functional-programming has more relevance to scientific computing, but C++'s functional features are "okay" but still not as capable or proven as, say, Haskell's or OCaml's - for example for tail-recursion you still depend on the compiler supporting that optimization, you can't force it or necessarily assume it will happen, with fun consequences for your stack if it doesn't.

Re: Why physicists still use Fortran (2015)

#146

I think this just shows how scientists don't understand programming. Pretty much every 'advantage' listed for Fortran over C++ could be added to C++ in an afternoon. C++ is an extensible language, you can define your own types and operators, so all the examples can be easily implemented. For some of the examples it's just sad that they were brought up. For example, 'you have to write a loop to allocate an array' shou…

language built-ins are not fully replaceable with extensions and libraries. Most notably: (1) Compilers have more ways to optimize if given higher level abstractions, (2) built-ins are easier to use for the user because of specific syntax (e.g. highlighting), (3) built-ins have support in debuggers (e.g. you can easily print an array slice in a Fortran debugger).

just a case in point: what do you think is easier to use, standards conformant and is more typesafe:

a) a typedef that gives you "__restrict const * const double"

b) declaring inputs as "real(8), intent(in)"

Re: Why physicists still use Fortran (2015)

#147
post #100

One of the key points of the article is that there is a lot of legacy code written in Fortran. As a former high energy physicist, I have an anecdote here that some people might find interesting. There was a library written in Fortran called CERNLIB which included a broad variety of miscellaneous numerical algorithm implementations ( e.g. minimization, integration, special functions, random number generation) [1]. I c…

Cernlib is available in current Debian (and also in EPEL 6). I don't know why it's not in anything else under the Fedora banner, and wonder what nasty non-standard stuff CERNLIB does. I don't remember ever having to look at more than bits of it.

I've heard an anecdote of HEP analysis code that was written by a team in C++ and wasn't ready for impending data collection on LHC. Someone apparently rescued the situation by turning up with a working Fortran system he'd written on his own. I don't know details other than which university group the report originated from; I'd be interested to know more about it.

Re: Why physicists still use Fortran (2015)

#148
post #48

Earlier quoted context omitted.

>Unless you're passing arrays of pointers That seems to be the context from his example: for(i = 0; i I suppose the counterpoint is that he's doing it wrong. But again, maybe physicists just don't want a tool with that much flexibility.

Fair enough then, I suppose that in C you have to do something like that if you want both that your matrix size is decidable at runtime, and to be able to index it with m[x][y] rather than some function.

You can always use a macro (or inline function, if the array is a rich wrapper type):

  arr(m, x, y)
Not quite as nice, but not too bad.

Re: Why physicists still use Fortran (2015)

#149
What would you use for a HPC application? You need a very fast language that doesn't get in your way in data management. Trust me even in the basic examples we did in our parallel algorithms course minor changes in data layout could save hours of computational time and that was in C, where no crappy garbage collection gets in your way. Not to even mention the masses of good low level performance analysation tools and parallel libraries made for Fortran and C/C++, but not other languages. Why would you use anything else? I think some people misunderstand what makes languages good. It is not generalisable, it depends on the case. Sure to write a script, e.g. to quickly automate a few things, shell or common scripting languages like ruby or python may make sense, because it is relatively easy to get going and write something in them. But that is not an important question for an HPC application. You need to write code that will definitively give the correct result and that will run extremely fast on the cluster of machines that make up the supercomputer. You need the language means to define very detailed how your memory is to be layed out, etc.. The very thing that makes a language annoying to use in a scripting context is a feature here. On the other hand you don't care about the ease of portability, in fact you will want to optimise it for one specific architecture as much as time allows. That the program will have to be recompiled is a minor issue in comparison to memory layout, threading schedules or network communication changes to the algorithm to optimise it for a new system.

No language is truely superior to all others, the question is always context and the conditions and constrictions it puts on the developer.

For physicists Fortran or C are the best choices. Even Go uses a garbage collector which brakes it for large HPC scenarios. VM based languages are completely useless. Their low speed is already a nuisance for simple common tasks, never mind problems that already take days or weeks to execute when they are properly optimised. If you think Java, Ruby or any such language could be used, look at benchmarks. You will find CPU time of 1.5-2.5x and memory at least 5-7x the amount needed by the same problem executed by a program written in C.

Re: Why physicists still use Fortran (2015)

#150

"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…

Yes, C++ does not buy you that much. Sure, it is a more modern language, but when used by scientists (not software engineers) the advantages are hardly earth shattering. Much of complexity is hidden (as it should be) into libraries.

IMO, Python stands a better chance of breaking the Fortran's lock on physics related computing. Give it a few more years and enough numpy-based libraries might make Python a real competitor. My 2c

Post reply on HN