60
$\begingroup$

I've been using Ruby to write scripts for research, but I want to get into some heavier stuff that Ruby is just too slow for. I noticed there are a few things written in C and C++, but there is an oddly large proportion of software used in computational chemistry that is written in FORTRAN (in which I have zero experience.)

Why is FORTRAN used in computational chemistry? From what I understand, FORTRAN is kind of on the ancient side (“punchcard” old.) I was a bit shocked to find fairly recently written tutorials for FORTRAN.

Is it a sort of, "this is how we've always done it," thing or is there an efficiency aspect to FORTRAN I'm overlooking?

Note: I may have FORTRAN confused with later programming languages with similar names.

Improve this question
$\endgroup$
11
  • 7
    $\begingroup$ Because people started writing code a long time ago, and Fortran was (and still is) heavily optimized for formula translation (e.g. Calculations). $\endgroup$
    – Jon Custer
    Feb 6, 2015 at 2:36
  • 21
    $\begingroup$ Keep in mind that modern Fortran (95, 2003, 2008) is very different from FORTRAN 66 or 77. $\endgroup$
    – Geoff Hutchison
    Feb 6, 2015 at 2:48
  • 5
    $\begingroup$ Yes, you overlook something. 1) Fortran has slighly different semantics. It does not have true pointers, so compiler can be a bit more liberal in optimizations. 2) there is a lot of legacy fortran code 3) fortran is hell lot simpler, than C and especially 'object-oriented' languages. $\endgroup$
    – permeakra
    Feb 6, 2015 at 12:30
  • 7
    $\begingroup$ Let's not forget that many scientific programmers are actually terrible programmers, and it is much easier to write something reasonable in Fortran than in C++. $\endgroup$
    – Greg
    Feb 7, 2015 at 8:58
  • 10
    $\begingroup$ LOL - Wrote my first program in 1971 in FORTRAN using punch cards. Wonder how many folks know how to setup the control card for a keypunch. Another lost sign of being a nerd was knowing how to wind a paper tape for a teletype punch reader. $\endgroup$
    – MaxW
    Feb 5, 2016 at 5:48

6 Answers 6

Reset to default
45
$\begingroup$

I don't think that's really true anymore.

Some Fortran use is historical (i.e., early codes were developed in FORTRAN because that was the best programming language for number crunching in the 70s and 80s). Heck, the name stands for "formula translation."

Some Fortran use is because of performance. The language was designed to be:

especially suited to numeric computation and scientific computing.

Many times, I find chemistry coders sticking to Fortran because they know it and have existing highly optimized numeric code-bases.

I think the performance side isn't necessarily true anymore when using modern, highly optimizing C and C++ compilers.

I write a lot of code in C and C++ for performance and glue a lot of things with Python. I know some quantum programs are written exclusively or primarily in C++. Here are a few open source examples:

  • Psi4 - Written in C++ and Python
  • MPQC - Written in C++
  • LibInt - Written in C++ for efficient quantum integrals.
  • LibXC - Written in C with Fortran "bindings" for DFT exchange-correlation functionals

This is my opinion, but my recommendation for faster performance in chemistry would be Python with some C or C++ mixed in.

I find I'm more efficient coding in Python, partly because of the language, partly because of the many packages, partly since I don't have to compile, and that's all important.

Also, you can run Python scripts and functions in parallel, on the GPU, and even compile them, e.g. with Numba. As I said, if I think performance is crucial, I'll write pieces in C or usually C++ and link to Python as needed.

Improve this answer
$\endgroup$
14
  • 8
    $\begingroup$ Based on sheer usage, I highly recommend Python for scientific programming right now. Some pieces for a recent project were already available as efficient NumPy or SciPy functions. :-) $\endgroup$
    – Geoff Hutchison
    Feb 6, 2015 at 2:36
  • 2
    $\begingroup$ I'm seriously sold on Python. I haven't written much in Python, but I have found a lot of really helpful scripts written in it. When it comes to C or C++, which do you recommend? I've only ever really used Ruby and Perl (and a tiny bit of Python) and I really didn't care for Perl. $\endgroup$
    – Melanie Shebel
    Feb 6, 2015 at 2:40
  • 1
    $\begingroup$ My suggestion for learning languages is to have a project where you need it. I taught myself Python recently simply to use NumPy image processing. I'd suggest using Python for a while, then if there's a performance-critical portion, try rewriting in C or C++. Many "learn language X" guides exist online and in book form. $\endgroup$
    – Geoff Hutchison
    Feb 6, 2015 at 2:44
  • 2
    $\begingroup$ @Wildcat There are advantages in terms of faster prototyping if you do not need to re-invent the wheel. $\endgroup$
    – Geoff Hutchison
    Feb 6, 2015 at 12:39
  • 1
    $\begingroup$ @permeakra I believe that's largely due to history. Gaussian was started by Pople in the 70s. GAMESS was similarly started well before C gained much acceptance. More modern projects are largely mixed or C++. $\endgroup$
    – Geoff Hutchison
    Feb 6, 2015 at 12:41
32
$\begingroup$

I think it does make sense to provide a somewhat alternative view and to clarify the matter.

FORTRAN vs. Fortran

First off, one has to distinguish the old FORTRAN from the new Fortran, where, by convention, the name of the old language is written usually in all caps. The old FORTRAN (all the way up to FORTRAN 77) is indeed still used because of tons of legacy code, but the new Fortran (starting from Fortran 90) is used mainly because it is a very elegant and simple yet powerful and efficiently implemented language for number crunching.

DSL vs. GPL in general

Note specifically, that even modern Fortran, in my opinion, is domain-specific language (DSL) and herein lies its relative weakness comparing to some general-purpose languages (GPL) like the mentioned C++: Fortran is specialised for a particular task (number crunching) and might be not so suitable for some related tasks (say, automated analysis of the final results, their graphical representation, etc.)

General-purpose languages, such as C++, give you more flexibility (in language features, in 3rd party libraries, etc.) so that you can solve not just the primary task (number crunching) but also the related task using the same language. If, however, you choose Fortran for number crunching, you often have to use one more language (e.g. Python) for these related tasks. Think about it as of using two different DSLs: one for the primary task, another one for related tasks. Of course, you could also use Python together with C++, but an experienced C++ developer (which you are supposed to be if you choose to do some number crunching in it) would not necessarily take advantage of using another language instead of his C++ beast.

Fortran vs. C++ specifically

All this is somewhat subjective, but anyway, here are my 5 cents. Overall, Fortran is simpler than C++, but (and because) C++ is more feature-rich. Basically, it because Fortran is DSL, while C++ is GPL. And as I said, this is subjective to some degree, and besides, the complexity is one of the most complex things in the universe, so we could start a debate about it, but hey, just one word: templates and the discussion is in principle over. Templates make C++ the beast, but everything comes for its price.

Note that I didn't say that C++ is more powerful, since, in my opinion, "more feature-rich" does not always mean "more powerful". It depends first of all on do you actually need these additional features in the first place or not? Seriously, do you need the level of generosity (and metaprogramming) C++ templates provides for number crunching? Not necessarily. And if so, C++ would not be more powerful than Fortran, although, it will still be more feature-rich.

Templates are not the only feature of C++ that Fortran does not have. Exceptions and Standard Library - are two other noticeable features that Fortran does not have. Again, it is not so likely that you will greatly benefit from these features for number crunching. But some other tasks they might be very helpful, so C++ as GPL includes them while Fortran as DSL for number crunching does not. Think about Fortran as of a "suitcase language" just for number crunching and about C++ as of a "trunk language" for everything.

There is also one great feature of the Fortran language which C++ still could not catch up with: modules. I mean, real modules, and not ancient preprocessor machinery which irritates me more than everything else.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ C++ has real modules; if you don't like the implementation details, then just use #pragma once. $\endgroup$
    – Alice
    Feb 7, 2015 at 5:26
17
$\begingroup$

FORTRAN used to have an edge when it came to speed due to having much better optimizing compilers, in part due to its relative simplicity. Now that C and C++ compilers are nearly on par (and occasionally better), other factors such as programmability come into play. However, there is a lot of legacy code out there as well.

I work in quantum chemistry, and many of the programs that I work with have a mix but are starting to incorporate more C++. The PSI4 package even mixes Python and C++ to gain the benefits of speed and usability of each.

Here is a list of various programs and the language(s) they use.

  • ORCA - C++
  • MPQC - C++
  • PSI4 - C++, Python
  • PySCF - Python
  • Q-Chem - FORTRAN, C++
  • CFour/ACES - FORTRAN, recently some C++
  • NWChem - FORTRAN, C
  • GAMESS(US) and GAMESS(UK) - FORTRAN
  • Gaussian - FORTRAN
  • Molpro - FORTRAN
  • Dalton - FORTRAN, some C
  • MRCC - FORTRAN
  • MOLCAS/OpenMOLCAS - FORTRAN
  • DIRAC - FORTRAN
  • ADF - FORTRAN
  • CASINO - FORTRAN
  • COLUMBUS - FORTRAN
  • CP2K - FORTRAN
  • TURBOMOL - FORTRAN

Quantum chemistry packages

Improve this answer
$\endgroup$
6
  • 3
    $\begingroup$ C/C++ code in Computer Language Benchmarks Game is written in a very "hacky" way. Nobody will do so "in production" since such code is almost unmaintainable. Maintainable C/C++ would not beat the Fortran one. $\endgroup$
    – Wildcat
    Feb 6, 2015 at 10:01
  • $\begingroup$ Sadly that is sometimes true. However, since C and C++ optimizing compilers have been catching up, there are other considerations such as usability. $\endgroup$
    – Jonathon
    Feb 6, 2015 at 12:36
  • $\begingroup$ @Wildcat I disagree; libraries such as Blitz++ using expression templates are neither hacky nor unmaintainable; they are very easy to use and maintain, and regularly beat FORTRAN in linear algebra. $\endgroup$
    – Alice
    Feb 7, 2015 at 5:24
  • 1
    $\begingroup$ @Alice, first, I did not say any word on complexity of C++ libraries. And secondly, they are indeed very complex. If you have 10 years of C++ development, then you possibly could understand expression templates, but look where you are: it is chemistry site out there. $\endgroup$
    – Wildcat
    Feb 9, 2015 at 15:36
  • $\begingroup$ @Alice: I have never heard of Blitz++. Maybe it's good, but large user base is also important. $\endgroup$
    – user1271772
    May 4, 2019 at 23:04
14
$\begingroup$

FORTRAN is a less expressive language than C++, and that allowed older compilers to optimize much more efficiently. In modern compilers, there is little to no difference in performance. There are just a few places where FORTRAN's weaker safety guarantees allow more extreme optimizations. You likely won't notice the difference unless you spend 6-10 years developing FORTRAN.

Generally speaking, it is easier to do development in the newer languages because they better take advantage of modern computing capabilities. FORTRAN is very strict in its format because it had to be compiled by computers of the mid-1970's. You tell the computer exactly what to do in its language, rather than telling it what you want to do in a more human readable language.

FORTRAN is still used for two major reasons that I can uncover:

  • Some problems are simple enough where the expressiveness of C++ is wasted, and you can actually make a clearer program with the simpler FORTRAN.
  • Many programs are made by the previous generation. FORTRAN was, in the past, simply better for computational work.
Improve this answer
$\endgroup$
3
  • 5
    $\begingroup$ As a matter of pure opinion, as a developer who has developed in perhaps a dozen languages, there is no reason I would recommend FORTRAN for any developer for any task unless there is a legacy FORTRAN codebase to interface with. People are simply not learning the language anymore, meaning you will have to maintain any code you write forever. It will be hard to hand off to anybody. $\endgroup$
    – Cort Ammon
    Feb 6, 2015 at 5:32
  • 4
    $\begingroup$ @CortAmmon This is so far from true that it is intellectually dishonest. Modern FORTRAN is in use in CERN on the LHC for gods sakes, and not new code using a legacy base either; many things have been extensively rewritten or written from scratch. FORTRAN is not even close to less expressive than C++, as shown by the myriad of libraries and tasks it has been put to use on. Furthermore, tons of people are still learning it; it's a required programming language in some environments (mostly scientific). $\endgroup$
    – Alice
    Feb 7, 2015 at 5:23
  • 2
    $\begingroup$ This got an upvote, which drew my attention back to it. I felt it would be useful to post a link to the StackExchange programmer survey from 2019. To Alice's credit, there may be small close-knit populations which develop FORTRAN, and in those populations, it can be a maintainable language. But in the larger developer population, it's so unpopular that it didn't even make the list of languages people develop with (the lowest on the list was WebAssembly, at 1.1%) $\endgroup$
    – Cort Ammon
    Jun 5, 2020 at 18:06
12
$\begingroup$

I stumbled on an article in J. Appl. Cryst. that partially is related to the original question. Comparing Fortran to other programming languages in the context of crystallographic algorithms in a reusable software framework yields this condensed diagram:

enter image description here

(doi 10.1107/S0021889801017824)

It should be added that the article relates to software packages written in the old Fortran 77 dialect.

Improve this answer
$\endgroup$
2
  • 4
    $\begingroup$ While languages like Python are not especially fast (it's basically interpreted not compiled) this is misleading. Python makes it easy to access highly optimised compiled libraries for specific computational tasks. So you can combine the ease of programming and still achieve high speed number crunching. That is one reason for its growing popularity. $\endgroup$
    – matt_black
    Feb 9, 2018 at 10:33
  • $\begingroup$ Is this saying that C has better runtime performance and programming efficiency? $\endgroup$
    – user1271772
    Aug 17, 2022 at 21:45
8
$\begingroup$

I believe there are two main reasons for the wide use of Fortran in the computational chemistry community. The first was because of its efficiency: FORTRAN means Formula Translator and the scientific/numeric calculation was the main reason for developing this code.

Nowadays, Fortran is still very efficient, however, some other languages (C++ for example) are as efficient as Fortran. But so why do we still code in Fortran?? Basically, the majority of Electronic structure software is written in Fortran and no one is so crazy to translate millions of lines. Therefore we keep it writing in Fortran when adding blocks of code! On the other hand, if a new software had to be written, there would be no practical reasons to choose the Fortran language. For example, the recent software MIDAS (Aarhus University) for obtaining nuclear wavefunctions has been completely written in C++. Personally, I use Fortran90 as language and it is not as rigid as the old FORTRAN77... and I like it! :) I actually asked myself the same question you posted when I started my Ph.D.

Improve this answer
$\endgroup$
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.