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

Why physicists still use Fortran (2015)

moreisdifferent.com

Post reply on HN
Print view View original

91–100 of 300 posts

Re: Why physicists still use Fortran (2015)

#91

Post by jabl »

sseagull wrote: post #16
quadruplebond wrote: post #11

As someone working on an Exascale project for electronic structure calculations, I have a theory about the longevity of Fortran. It's the fact that many of these codes were started years ago and the people who have the credentials and ability to get funding for super computing projects learned on Fortran and stayed with Fortan because they were scientist first and programmers second. Modern Fortran has many nice feat…

Yes, the electronic structure community is rapidly moving away from Fortran. In my opinion, Fortran will fall behind as newer hardware, libraries, etc, will drop Fortran support. Also, newer grad students are all much more interested in C/C++/Python. I think this is in part because the newer languages are widely used outside of science and therefore there is much more documentation and tutorials/guides. Not to mentio…

> Yes, the electronic structure community is rapidly moving away from Fortran.

Really? Seems to me that with very few exceptions (e.g. GPAW which is python/C and nwchemEx which I've never heard about until the parent poster mentioned it), electronic structure is pretty much a Fortran bastion.

(Source: I did a Phd doing mostly electronic structure calculations, graduated ~5 years ago)

Re: Why physicists still use Fortran (2015)

#92

Post by yjftsjthsd-h »

ChuckMcM wrote: post #62
thicknavyrain wrote: post #24

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

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 would also really want to see a comparison of bugs and error rate, although that's probably a nightmare to try and work out.

Re: Why physicists still use Fortran (2015)

#93

Post by jabl »

openasocket wrote: post #90
jxcole wrote: post #89

So the article basically says: 1) Some stuff is already written in Fortran so they don't want to rewrite that. I dig it. 2) It's fast (except C sometimes) but easier to write than c. Like 100x faster than python. I'm not sure about number two. With the gpu processing revolution wouldn't a python/TensorFlow stack be faster than Fortran? Am I missing something? I remember talking to someone who had worked heavily on at…

TensorFlow is for machine learning, not general purpose computations. And no, you will not get better results from a neural network than state of the art computational fluid dynamics. As for general purpose GPU programming, some parts physics are GPU friendly put not all of them.

IIRC there was some project doing more or less real-time weather forecasts for small areas (think airports and such) that used deep learning instead of traditional CFD style simulations. They were able to do it with several orders of magnitude less CPU usage than the CFD calculations.

Re: Why physicists still use Fortran (2015)

#94

Post by adrianN »

sampo wrote: post #88
ChuckMcM wrote: post #62

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.

Well, that Fortran codebase probably also was written in large parts by PhD students, not export Fortran programmers.

Re: Why physicists still use Fortran (2015)

#95

Post by fiftyacorn »

rcarmo wrote: post #10

A slight gap in knowledge in the piece: Most Python libraries for numerical computation are written in C/C++ or... Fortran. Last time I had to compile scipy from scratch I had to install gfortran.

Yeah i remember that too - there is a answer in the scipy FAQ -

https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fas...

"Actually, the time-critical loops are usually implemented in C or Fortran. "

Re: Why physicists still use Fortran (2015)

#96

Post by nejenendn »

pjmlp wrote: post #81
nejenendn wrote: post #25

Earlier quoted context omitted.

Fortran is easier to optimize compared to c/++ if you don’t use restrict for the c end. If you do use restrict (iirc) the compilers are competitive.

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.

Re: Why physicists still use Fortran (2015)

#97

Post by ISL »

ryl00 wrote: post #21
cratermoon wrote: post #17

Earlier quoted context omitted.

Is MS Fortran still a supported product? I'm not sure I'd call software that depends on unsupported and unmaintained other software properly maintained.

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

Interesting -- I'll look into it. Is it open-source (in the spirit of future-proofing)?

Answering my own question: It doesn't appear to be.

Re: Why physicists still use Fortran (2015)

#98

Post by ISL »

craftyguy wrote: post #13
ISL wrote: post #2

Our physics group has a core library, first written in 1987, that is in Fortran (a Microsoft dialect, to be specific). Why haven't we moved to something else? It works, it is time-tested, and the original author continues to maintain it. (P.S. I'd like to compile it with the gfortran tools, in order to preserve the library for the future. Is there any documentation for simple conversions from Microsoft's implementati…

> and the original author continues to maintain it. What's the plan when they retire?

My hope is to release it in a form that can be compiled by open-source tools.

Re: Why physicists still use Fortran (2015)

#99

Post by sampo »

gravypod wrote: post #28

A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy in C++. You could easily have someone define a MathArray class and turn this messy fortran code: real, dimension(:,:), allocatable :: name_of_array allocate(name_of_array(xdim, ydim)) Into something that looks like auto *my_matrix = new MathArray (); The code t…

    > auto *my_matrix = new MathArray();
In Fortran, one can choose the matrix size at runtime, though.

But otherwise, great. Now if you just add slicing so that if we, say

    allocate(name_of_array(-1:5, 1:3))
and then say fill in the matrix by

     1  2  3  4  5  6  7
     8  9 10 11 12 13 14
    15 16 17 18 19 20 21
then

    name_or_array(0:4:2,2:3)
should return

     9 11 13
    16 18 20
and then we're talking. (Slicing should of course also work in higher dimensions than 2.)

Re: Why physicists still use Fortran (2015)

#100

Post by foob »

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 couldn't tell you exactly when the library was first released, but my best guess would be the early 80s. It can't possibly be later than 1986 when PAW was initally released [2]. The field has since transitioned from the Fortran based PAW to the C++ based ROOT since then, but many high energy collaborations still rely on CERNLIB for their own analysis frameworks (keep in mind that many of these experiments had been in planning and development stages for over a decade before they actually turned on).

The thing about this that I find interesting is that compiling CERNLIB has become a lost art and that this fact has had far reaching consequences. The last available binaries were compiled with GCC 4.3 in 2006 and packages are only available for Scientific Linux 4 [3]. This crucial dependency has led to collaborations using extremely outdated Linux distributions and GCC versions in their computing facilities. The majority of analysis code is written in C++, but not even C++11 additions can be used because everything is frozen on GCC 4.3. Nobody can even run the analysis environment on their local machines without resorting to the use of virtual machines running SL4. It was really a nightmare to deal with.

[1] - https://en.wikipedia.org/wiki/CERN_Program_Library

[2] - https://en.wikipedia.org/wiki/Physics_Analysis_Workstation

[3] - http://cernlib.web.cern.ch/cernlib/version.html

Post reply on HN