# Python vs FORTRAN

Which one is better: FORTRAN or Python? And I guess that in both cases you need Gnuplot, am I right?

I'm working on a Windows machine at the moment.

I'd like to use it to get numerical solutions for physics-problems, including Monte-Carlo simulations, numerical integration and differentiation, molecular dynamics, etc.

I saw a course on computational physics which introduces both FORTRAN (77 I believe) and Python. I'm planning to start with one and then learn the other, but I don't know which transition might be the easiest.

Also which compilers would you recommend?

The basic question for me comes down to: which one is the easiest to learn, which one is the fastest, which one is most user-friendly and above all which one is most used (so a comparison of these 4)? And next to that, what are the most common (free or paid) compilers in use? I'm currently considering converting an old laptop (early Intel dual core) to Linux; hopefully that's fast enough.

Thanks a lot for the answers so far! The answers which are in line with what I'm looking for are those of LKlevin and SAAD.

I know the basics of C++, Maple and I master MATLAB and Mathematica9 almost completely if that's any help.

• You really need to be more specific; this is like asking "which is better: a hammer or a screwdriver?". Take a look at scicomp.stackexchange.com/questions/11006 (it's about C++ instead of Fortran, but most points should apply equally). – Christian Clason May 2 '14 at 10:27
• @ChristianClason, fair point :p – Nick May 2 '14 at 10:33
• Thanks for your edit, although this doesn't really narrow things down. I'm not sure what more can be said than is already given as answers to the question linked above. – Christian Clason May 2 '14 at 11:03
• Also, the question about compilers is a separate issue and should be a separate question. (Otherwise people familiar with Fortran but not interested in Python will not see it.) Some recommendations are already given in scicomp.stackexchange.com/questions/8617. – Christian Clason May 2 '14 at 11:04
• If you know matlab, you can learn most numerical algorithms by implementing them there, although your performance will almost always be worse than the built in matlab routines. From there you can decide what your performance needs are and move to a more efficient library/language. – Godric Seer May 2 '14 at 11:06

# Ease of learning

Python and Fortran are both relatively easy-to-learn languages. It's probably easier to find good Python learning materials than good Fortran learning materials because Python is used more widely, and Fortran is currently considered a "specialty" language for numerical computing.

I believe the transition from Python to Fortran would be easier. Python is an interpreted language, so the number of steps it takes to get your first program running is smaller (open the interpreter, type print("Hello, world!") at the prompt) than it is for Fortran (write a "Hello world" program, compile, run). I also think that there are better materials to teach object-oriented style in Python than in Fortran, and there's more Python code available on GitHub than Fortran code.

# Getting up and running on Windows

Installing Python should be less painful; there are Windows distributions available. I recommend using a scientific distribution like Anaconda or Enthought Canopy. There's not really a compiler, per se; the interpreter takes that role. You'll want to use a CPython-based interpreter, because there are more numerical libraries available and it interoperates nicely with C, C++, and Fortran. Other interpreter implementations include Jython and PyPy.

On a Windows machine, installing a Fortran compiler is going to be annoying. Typical command-line compilers are programs like gfortran, ifort (from Intel; free for personal use, otherwise costs money), and pgfortran (from PGI; free trial versions, otherwise costs money). To install these compilers, you might need to install some sort of UNIX/POSIX-type compatibility layer, like Cygwin or MinGW. I found it a pain to work with, but some people like that workflow. You could also install a compiler with a GUI, like Visual Fortran (again, you'd have to pay for a license). Windows Subsystem for Linux (WSL) could also be used to install gfortran compiler in Windows.

On Linux, it will be easier to install Python and compilers; I would still install Anaconda or Enthought Canopy as a Python distribution.

# Speed: a productivity vs. performance tradeoff

In using Python (or MATLAB, Mathematica, Maple, or any interpreted language), you give up performance for productivity. Compared to Fortran (or C++, C, or any other compiled language), you will write fewer lines of code to accomplish the same task, which generally means it will take you less time to get a working solution.

The effective performance penalty for using Python varies, and is mitigated by delegating computationally intensive tasks to compiled languages. MATLAB does something similar. When you do a matrix multiplication in MATLAB, it calls BLAS; the performance penalty is virtually zero, and you didn't have to write any Fortran, C, or C++ to get the high performance. A similar situation exists in Python. If you can use libraries (for example, NumPy, SciPy, petsc4py, dolfin from FEniCS, PyClaw), you can write all of your code in Python and get good performance (a penalty of maybe 10-40%) because all of the computationally intensive parts are calls to fast compiled language libraries. However, if you were to write everything in pure Python, the performance penalty would be a factor of 100-1000x. So if you wanted to use Python and had to include a custom, computationally intensive routine, you would be better off writing that part in a compiled language like C, C++, or Fortran, then wrapping it with a Python interface. There are libraries that facilitate this process (like Cython and f2py), and tutorials to help you; it is generally not onerous.

# Scope of use

Python is used more widely overall as a general-purpose language. Fortran is largely limited to numerical and scientific computing, and is mainly competing with C and C++ for users in that domain.

In computational science, Python typically doesn't compete directly with compiled languages due to the performance penalties I mentioned. You would use Python for cases where you want high productivity and performance is a secondary consideration, such as in prototyping numerically intensive algorithms, data processing, and visualization. You would use Fortran (or another compiled language) when you have a good idea of what your algorithm and application design should be, you're willing to spend more time writing and debugging your code, and performance is paramount. (For instance, performance is a limiting step in your simulation process, or it is a key deliverable in your research.) A common strategy is to mix Python and a compiled language (usually C or C++, but Fortran has been used also), and only use the compiled language for the most performance-sensitive parts of the code; the development cost is, of course, that it's harder to write and debug a program in two languages than a program in a single language.

In terms of parallelism, the current MPI standard (MPI-3) has native Fortran and C bindings. The MPI-2 standard had native C++ bindings, but MPI-3 does not, and you would have to use the C bindings. Third-party MPI bindings exist, such as mpi4py. I've used mpi4py; it works well, and is straightforward to use. For large-scale parallelism (tens of thousands of cores), you'd probably want to use a compiled language because things like dynamically loading the Python modules will bite you in the ass at scale if you do it in a naïve way. There are ways to get around that bottleneck, as demonstrated by the PyClaw developers, but it's simpler to avoid it.

# Personal opinions

I have roughly a decade of experience in Fortran 90/95, and I've also programmed in Fortran 2003. I have roughly five years of experience programming in Python. I use Python much more than I use Fortran because, frankly, I get more done in Python. The majority of the work I need to do does not require major supercomputing resources and is generally not worth re-developing in another language, so Python is just fine for solving ODEs and PDEs. If I need to use a compiled language, I will use C, C++, or Fortran, in that order.

Most of the Fortran code I've seen has been ugly, mainly because most of the computational science community seems unaware of or averse to any best practices discovered by software engineers in the last 30 years. To wit: there is no good unit testing framework in Fortran. (The best I came across is FUnit, by NASA, and that's not maintained anymore.) There are a few good Python unit testing frameworks, good Python documentation generators, and generally many better examples of good programming practices.

• Very nice and complete answer :). I've installed Linux yesterday where the python-compiler was already present. Now I was wondering if there is an easy way to share files between my Linux and Windows machine? I noticed that whenever I use a stick to transfer data both the Windows and Linux machine ignore certain parts on de stich (which is formatted in the NFTS-format). – Nick May 3 '14 at 14:40
• and my last issue is solved bij using the FAT32-format (So far at least). – Nick May 3 '14 at 14:57
• NB: FAT32 has a limited maximum file size. – meawoppl May 16 '14 at 23:25
• @Meawoppl, is there a more convienient way to swap files between Linux and Windows? Maybe dropbox then? Is there also a hardware-based solution ? – Nick Aug 7 '14 at 9:05
• Keep your files under 4GB :P Really, I don't know of a good solution. There is also some derpyness in file-name conventions. I recall breaking some windows support once by naming a file <3.txt which made M\$ pretty sad face. NTFS support in linux is pretty good now, but is notably a total no-go in OSX. I really thought we would have solved this problem by now. – meawoppl Aug 8 '14 at 23:08

Python is a very slow, high level language. For fast number crunching you'll have to write the main compute kernels in low level languages like C/C++ which means that now you have to learn not one but at least two languages. You'll also have to deal with additional headache associated with debugging/installation/maintenance etc. Most people use Python as a syntactic sugar to hide short comings of C/C++.

Modern Fortran (90 and later) is both fast and high level with almost MATLAB like syntax. So you can do things like:

k=k+matmul(transpose(B),matmul(D,B))*weight(i)*detj


or

indx(:)=indxmap(indx(:),2)


or even simpler

indx=indxmap(indx,2)


etc.

On Linux there are a number of free Fortran compilers. I use

1. GCC
2. Solaris Studio
3. Open64
4. Intel (non-commercial use only)

I dont use Macs/OSX but there is free PGI.

And please dont use FORTRAN 77. No one uses it to write new code.

Disclaimer: I personally looked at Python for writing my own small unstructured FE code (built top of PETSc) but the amount of work/coding involved was more than just writing it plain Fortran 95.

• To this I would add that you can do pretty serious object-oriented programming in Fortran 2003; see for example this guide. I've been using it a lot in my own code and it's been very effective for what I want to do. A lot of people will tell you to avoid it -- I say keep an open mind, you might like it a lot. I certainly do. – Daniel Shapero May 2 '14 at 16:48

I would stay away from Fortan, or if you must, use a reasonably new version (2003 rather than 77). A lot of physics software (Monte Carlo simulations in particular) is written in Fortran, simply because the projects were originally started in the 80s.

That being said, python and Fortran are two very different language, and what they should be used for is quite different. Python is high level and in general not that fast (compared with Fortran & C++). The reason it's being used so much is that it's fast enough for most things and has excellent (Fortran powered) libraries for many (but not all) of the things you would like to do. It also has the excellent Matplotlib for plotting (so no need for GNUplot) and you can get quite decent performance by using stuff like Cython for writing the expensive bits. It will not be as fast as Fortran or C++ however, and parallelisation is pretty terrible, making it inadequate for high performance numerical computing. If what you want can be handled by calling Fortran or C libraries however, python makes an excellent language for gluing things together and analysing your data.

Fortran is a somewhat lower level language. For numerics the library support is surprisingly good, but is still very low level giving you a hoard of bugs you could otherwise avoid, such as accidentally passing the wrong array size to a method. These bugs are hard to find and you might not notice them at all. Trust me, I spent quite a while writing Fortran 77.

C++ is (in my humble opinion) a happy medium. With libraries like Armadillo or Eigen, you can get away with a fairly high level style of coding while getting a low level style of performance.

Speaking of performance, the only real choice for numeric python right now is CPython. If you download something like WinPython you will also get the majority of the libraries you need.

For Fortran on windows, things are a little harder. I would recommend switching to linux and using either gfortran or Intels ifort compiler. Ifort tends to be faster for numeric code in my experience, but is only free for non-commerical, non-academic use.

To sum up: Unless you want to run really heavy simulations, python is by far the easier choice and much more enjoyable to work with. It should also be fast enough for most student level projects. If you need better performance, start by looking at the wast amounts of libraries already written and let that decide your language. If you have to write things from scratch, use C++.

Also a warning: most code written by physicists is quite terrible, presumably because physicists have the tendency to assume programming is easy and doesn't require the same rigour that they might use in mathematics. Consider taking a class or buying a book that teaches programming.

Disclaimer: I'm a physicist who has spent quite some time with Fortran 77 based Monte Carlo codes and currently does all his data processing in Python.

• Regarding the parallelization, researchers have used Python in parallel successfully on tens of thousands of cores with good parallel efficiency. (For instance, PyClaw has been run on all of Shaheen, which is 65,000+ cores.) – Geoff Oxberry May 2 '14 at 18:40
• Well it is possible, but to my knowledge only by making sure that the parallel part happens outside CPython which is a considerable effort. The parallel part of PyClaw (PETSc) is written in C for instance. Another alternative is running multiple instances of CPython, but it's not exactly trivial. – LKlevin May 2 '14 at 20:08
• Most parallel applications are nontrivial. You wrote "[Python] parallelisation is pretty terrible, making it inadequate for high performance numerical computing." No one writes any high performance code in pure Python. The reasoning for this decision has nothing to do with parallelism, and does not invalidate the use of Python as an interface language in high performance computing, as long as it is used appropriately. Your quote is a straw man that conflates the issues of parallelism, high performance, and interpreted languages; no one competent would design an application like that. – Geoff Oxberry May 2 '14 at 21:58
• I agree that Python is an excellent interface language for almost any purpose, but that's moving away from the question. Most applications are nontrivial, the problem here is that all cases of parallelization, including the trivial ones, are non-trivial in python. This can be a nuisance if your problem is otherwise well described in terms of Numpy or Cython operations. No, you wouldn't use this on a 65000 core cluster, but you might accept the 2x performance hit on a 100 core. – LKlevin May 3 '14 at 8:03
• W.r.t. parallelism, the nice thing about Fortran is that besides MPI/OpenMP there is also Co-arrays that is now part of the standard. E.g., see this jolts.stanford.edu/72/… – stali May 7 '14 at 20:01

Python is very practical for full simulation analysis with well-documented versatile packages: grid generation, array computation and data structure handling (numpy and pandas) as well as data visualization with matplotlib. For complex simulations with big result files, it's even better to work with the VTK package which allows exporting data to be read by advanced open-source applications (like Paraview or Visit)

Fortran has been for some time the preferred language for different domains in simulations. It's easily readable (less readable than Python code though). Array handling is one the language's strong points, quite easy to define and use in use all kinds of array operations. It comes handy when debugging also.

The comparison gets down to performance: I've only done big scale computations using compiled languages (C++ and Fortran 90) but never with Python. Another thread gives more performance information about interpreted and compiled languages: What language should I use when teaching an undergraduate course in computer programming?

Personally, I like working with Python in general, especially for post-processing. Python programming is fun !

• Performance is almost always important. Lack of attention to performance is why people need 8 cores with 16Gb of RAM to check email and surf the web. – stali May 2 '14 at 23:15
• I have had the misfortune of having to read others' python code. I would not categorize py code as easy to read. – Biswajit Banerjee May 3 '14 at 1:01
• @stali : I totally agree – SAAD May 3 '14 at 9:11
• @BiswajitBanerjee: it's not impossible to write complicated code with any language, but at least I can easily identify inputs and outputs of any function, here's where Fortran becomes horrible ! :) – SAAD May 3 '14 at 9:14

With Python you don't need Gnuplot, you can use, for example, matplotlib and/or use the IPython shell. IPython is an interactive Python shell that, in %pylab mode, provides pretty much the same plotting commands you have available in MATLAB.

It is quite likely that scientific computation will to a great extend shift from MATLAB to Python in the next 5+ years.

• One advantage of Gnuplot is that it is almost always installed on Linux machines (cluster/servers etc.) and very useful for quick/dirty viz. It is like vi for viz. – stali May 2 '14 at 23:00

I would keep using MATLAB, it calls fast math libraries, and you will not see much difference in performance by switching to FORTRAN on Windows. At the same time you'll have a better infrastructure in MATLAB for reporting of results and running your code. The downside of MATLAB is its cost. FORTRAN is basically free, and there's a bunch of free libraries out there.

FORTRAN is very easy to learn and start programming in. It basically does what the name suggests: translates your formulas into code, which is easy to read and understand. That's why physicists used it a lot in old days. As long as most of your code is about solving physics problems (not building GUIs or doing other cool stuff), FORTRAN code will be easy to maintain.

I would recommend Python only if you enjoy programming. Think of this: when you code a solution to physics problem do you enjoy programming part of the solution? If you do, then Python is an option, because the language is much better than MATLAB's.

• Your statement about the performance differences in switching from MATLAB to Fortran isn't true in general. Fortran is great if you're writing code for which arrays are a naturally good data structure, if you can live with how it handles I/O, and if it has the libraries you need. Numerical libraries in Python overlap heavily in functionality with MATLAB, and I find it easier to write Python interfaces to C code than MATLAB interfaces to C code. – Geoff Oxberry May 2 '14 at 18:34
• Sometimes you do see much difference. I recently rewrote a physics simulation program from Matlab (using the package bvp6c internally) to Fortran 2008 (using the package bvp_solver internally), and the execution time went down to just 1.4% after the switch, even though I didn't change the algorithms or overall structure of the program. For a simulation that used to require ~3.5 days per datapoint to converge, this was a very noticeable improvement. – jabirali Aug 13 '15 at 19:51