# What is a good programming language to learn for materials modeling?

Since we're all locked down due to coronavirus, now might be a good time to pick up a new programming language. What is a good programming language to learn for materials modeling? Since this is a broad field, I don't expect there to be only one answer.

• That's surely a tricky question to give a single answer, due to Ousterhout's dichotomy. For a great explanation and historic introduction on the problem, I recommend these two blog posts by Graydon Hoare: technicalities: interactive scientific computing #1 of 2, pythonic parts and technicalities: interactive scientific computing #2 of 2, goldilocks languages. – ksousa May 4 at 15:17
• Is this question apt for this community? In just one day, it has accumulated nearly 20 upvotes, yet also three votes to close it. I understand it has an extensive breadth of answers, but if users are closing the question solely due to its manner to attract opinion-based answers, is this not the fault of the answers themselves? This problem can easily be settled with an answer that covers a list of options each with a widespread consensus on its quality, as opposed to answers each regarding a single user's perspective (comments aside). – Mr Pie May 5 at 6:17
• Take this Math.SE question to more or less exemplify. If anything, the question above should be closed for being too broad, IMO. – Mr Pie May 5 at 6:20
• I am aware of that. But it is precisely this reason why your question is receiving requests to be closed, as though to suggest the answers are not entirely factual. – Mr Pie May 5 at 9:48
• This is probably worth discussing on Materials Modeling Meta. Going further, the community should decide how to handle these questions. Currently there is a potential for a close-reopen war. If that is not clarified, any question of that type could lead to that. – Martin - マーチン May 10 at 12:13

# Fortran

A large part of materials modelling involves density functional theory and molecular mechanics. From this compilation of quantum chemistry software, the most widely used programming language seems to be Fortran.

Indeed, the popular packages VASP (commercial), Quantum Espresso and Siesta (both free) all use this language.

• As a non-expert in quantum chemistry, how much do users of those packages need to interact with the code itself to use them? – taciteloquence May 4 at 11:40
• A point worth mentioning in Fortran's favor is that is extremely easy to learn. Because you need so few packages and libraries you can usually get started very quickly. I think fortran90 or 95 would be the best place to start. – taciteloquence May 4 at 11:43
• @taciteloquence I think you can even ask that as a separate question, it's an interesting one (I'm not an expert either). – TheSimpliFire May 5 at 8:59
• This would only make sense if you plan on developing/modifying legacy code. Newer codes use less and less Fortran and there the use is continuously reduced towards a number of old well established libraries. Unless you plan to develop these libraries, Fortran will not be particularly useful. - For the average user of quantum chemistry, Fortran might actually be useless. (There are much better languages if you want to automate/process data.) – DetlevCM May 16 at 10:00

# Julia

The answers above allude to what some call the "two-language problem". In materials science it takes the form of writing your code in Fortran for speed, writes an interface to it in Python for sanity and interactivity. Fortran will not go away any time soon due to the massive amount of legacy code available. For new codes, there is a new option: Julia.

With a little bit of care (follow a few simple rules given in the "performance tips" section of the manual), one can easily mix python-style high-level code and Fortran-style tight inner loops. Julia is easily interoperable with other languages, and reuse existing libraries (the python interface, in particular, being particularly seamless). Coupled with a very good native ecosystem for numerical computing (unlike python which is forced to hack together a core language not designed for numerics and NumPy), this makes it a particularly appealing language to use.

At least that has been our experience developing DFTK (https://github.com//JuliaMolSim/DFTK.jl/), a plane-wave DFT code built from scratch. The code is about one year old, ~4k LOC, and covers the basics of such codes. Had we chosen Fortran for this task, we'd still be writing the input file parser and makefile (I'm only partly joking).

• I must be going blind. I did not see this when I posted below about Julia. Glad to see others have seen the magic. – Charlie Crown May 6 at 2:14

I'll go first. For context: I do mostly Monte Carlo simulations, especially quantum Monte Carlo. My work has focused on spin systems, using techniques like the Metropolis Algorithm and stochastic series expansion QMC.

## For Writing Simulations

In my field there are few software packages available and the algorithms are sufficiently simple that most people write their own code from scratch. Especially for Monte Carlo, serial performance is key, memory is rarely an issue, so most people use fast, compiled languages like C/C++ or Fortran. Interpreted languages like python are often too slow for intense computations, but people do use hybrid solutions where the expensive calculations are written in C and called from python, which can be a good option.

C/C++ are great general purpose languages that you might want to learn for a whole host of reasons, and when properly optimized, they are very fast.

Fortran is less sophisticated than C/C++, but it is designed for writing simulations, so stuff like complex numbers, exponential and power functions are native. It's also very fast. In my experience, it's basically impossible to write slow Fortran code.

## For Data Processing/Plotting

After the simulations are done, you need post-processing programs to perform averages, calculate derived quantities and make figures. Here, speed is not important, so most people use an interpreted language. I personally use MATLAB (and it's GNU clone, Octave) for post-processing and plotting. MATLAB is commercial software, so the documentation is great and it works reliably on all sorts of machines. I can write scripts to fully automate plotting and they work reliably for years. The (literal) price you pay is that you have to buy a license or use one provided by your institution. Matlab can be pretty expensive.

If you're starting from scratch, it's probably a better idea to learn python. Python is a powerful, flexible language and it has a billion packages that make it pretty easy to get started on anything. There are a lot of resources for learning python and, unlike Matlab, it's free.

• My own opinion: for MCMC simulations I prefer R as it is good for statistical analysis. – TheSimpliFire May 4 at 10:31
• I think it depends on the kind of MC simulations you are doing. For physics I don't know anyone that uses R for the simulations themselves. What type of MC are you using? – taciteloquence May 4 at 11:41
• The main ones I've used are Metropolis-Hastings and Gibbs, though I'm more statistician than physicist, hence my own opinion. – TheSimpliFire May 4 at 14:39
• I'm glad to see FORTRAN and MATLAB here. As for Python, does it really have a billion packages? – Nike Dattani May 5 at 5:11
• @NikeDattani, I'm being a bit hyperbolic, but there sure are a lot of python packages out there. – taciteloquence May 5 at 7:12

# Julia

Everyone is saying Fortran or Python, and I love them both, but they both have issues. Fortran is easy for a compiled language to write, but I still have SIGSEGV burned into my retinas. Python is fast to write, but very slow. Learning how to cleverly make python fast (and it is still not all that fast) takes more time and skill than learning Fortran.

I will say, for Quantum Mechanical calculation, there are many Numpy libraries that essentially do the hard parts in C/C++/Fortran, so I will not complain about using python for Quantum Mechanics. However, if you think you as a beginner are going to write fast Python code... forget about it. You need to learn Python, as well as all of the specializations in Numpy and Scipy.

However, for atomistic simulation (molecular mechanics), there is only brute force for loops. Vectorization only gets you so much, and Python drives me crazy here.

Julia however is as easy to write as Python, as pleasant to write as Python, and, so long as you follow some simple rules, such as making sure you do not change a variables type accidently, as fast as Fortran. There are built in standard tools for helping with this such as @code_warntype

The only downside to Julia is that the bandwagon picked Python. However, that is changing. Julia is on the rise.

If you want to write a prototype, which then turns out to be just as fast as a compiled language (because it is) choose Julia.

I think one major question that needs to be asked is "What do you want to do?".

Develop new quantum chemistry codes? Use them more efficiently? Automate data processing? User @taciteloquence Has given a good answer I think. Many legacy codes are written in Fortran - newer codes will be typically written in C or C++. I believe there is also a Python project as well as a toolkit typing "things" together written in Python (The Atomic Simulation Environment). So as little as I personally like Python, it is used in the field.

To process data, you have two main approaches: Deal with the binary files or deal with the text files. I have myself written C++ code to extract and process data from text files.

If you have numerical data, it can be processed well in R. I actually started with a mix of C++ and R for extraction and processing but then gravitated to C++ only as it was faster (and I also ended up improving a lot of the underlying workflow structure). Still, I suspect my code "died" when I finished the PostDoc...

Another code I wrote (which lead to a recently published paper by a PhD student) was a C++ implementation of solvation models that existed in Fortran already. Why? It enabled "us" to optimise a model and the use of RAM for storing data lead to very significant performance increases. Oh, and I wrote the code to work with ORCA output. But in the end, your choice of post-processing language is effectively personal. Use what you like - what your colleagues can use. Be it C++, R, etc. For computation-heavy tasks, compiled languages will typically give better performance that interpreted languages. R? Lovely plot and data post processing, but loops are much slower than in C++ and the data structure is limited compared to structs/classes in C++. So basically, chose based on interest and maybe based on what the people around you use (with some qualifiers - I would argue that Excel should in many cases not be used...).

Something that wasn't touched upon by others: Automation. Learn some Bash (or another shell of your choice). My paper on fitting regression coefficients? I built the xyz geometries by hand, but then just ran the calculations using scripts. I did NOT write the input files with the methods by hand. A good scripting language will allow you to automate many mundane tasks. Once upon a time I used to write job scheduler scripts by hand... Nowadays I create a script to submit the job which I can call. I spend time figuring it out once but afterwards do not wear out my patience with menial tasks. So definitely look into scripting.

Though automation can also use more classical programming languages. If you have a set series of steps you wish to carry out. Let me given a rough example:

• You run a large number of quantum chemistry calculations (optimisations and frequencies).

• You use bash to extract the location of all text files

• You hand the list of file paths to a C++ code that extracts the desired data from the output files into a database. This can include further tasks such as identifying non-converged geometries, transition states, etc. Your limitation for many data-processing tasks is often your own competency. And the best way to get better at it, is to gain experience.

For those interested in the papers I mentioned, I leave you with the DOIs. - In terms of tools, I was using bash, C++ and R.

10.1016/j.fluid.2020.112614

10.1002/jcc.25763

• +1 Great first answer! Welcome to the site and thank you for your contributions !!! – Nike Dattani May 16 at 12:26
• Great point about automation with shell scripting! That's a skill that is often overlooked, and rarely taught formally. I wrote that answer while preparing a workshop on bash scripting and I still forgot to mention it. – taciteloquence May 18 at 4:08
• @taciteloquence Why don't you add it to your answer? - Many people won't scroll over all responses.? :) – DetlevCM May 18 at 19:59
• @DetlevCM, is that okay? I don't know what the SE norms are and I don't want to be seen as plagarizing your answer. – taciteloquence May 20 at 9:57
• Do it the academic way and give credit if you take someone else's idea. That deals with the moral side and it ensures that the person inspiring the comment is credited. There is also longterm value in acknowledging an existing answer with fewer votes and improving a response with more votes which is more likely to be seen. The underlying license for a lot on the Stackexchange network is creative commons - so forward use on Stackexchange is typically possible without constraints. (Some specifics may apply in some cases, e.g. photos which might not be CC.) – DetlevCM May 20 at 12:04

# Python and Julia

It depends on what you want to do. As a couple of others have pointed out, many of the computer programs used in computational chemistry and theoretical solid state physics are written in Fortran. However, that does not imply that you should learn Fortran and it does not mean that Fortran is the best language for materials modelling.

Even if you are concerned with writing serious code for a DFT/MD code. Consider that languages like Python and Julia are very easy to pick up. If you want to get to learn the theory and spend less time thinking about the implementation (as beginners should), it's hard to beat these languages. The other advantage that python has is that it has by far the best ecosystem surrounding modelling programs. The atomic simulation environment (ASE) has very significantly improved my productivity when working with programs like VASP.

That said, it doesn't mean that you cannot use python to contribute to serious DFT codes. the best example would be GPAW:

developing a DFT program takes a lot of time and when competitors had a headstart of decades you need ot catch up. ~80 % of GPAW are written in python and the very performance critcal parts are written in C. This allows them to regularly ship new versions with significant amounts of new features.

Furthermore python can be made very fast via numba, cython or pybind11, but it has some pitfalls. It is not as easy to implement complicated and performant, data structures in Python as it is in C++.

It should be noted that I am not saying you shouldn't learn Fortran. It is a perfectly good choice for a high performance computing language. The big problems Fortran has are that it lacks essential features of modern programming languages, like a package manager and the fact that there are essentially only very large projects. Therefore, it can be difficult to progress after you get the basics down. There are no medium sized projects one could contribute to. There are some recents efforts to make Fortran more popular again, namely https://fortran-lang.org/

At the end of the day, it depends on what you make of these languges as any of them are fine to learn.

# Python

@taciteloquence has already mentioned Python for data analysis and visualization, but let me add one more angle: automation.

Simulation nowadays often means high-throughput, automated simulation. Not only for large scale projects, like Materials Project but also individual projects where large amounts of data generated for screening properties, screeing different geometries, generating data files for machine learning, ABC approaches etc.. For building workflows (eg with automate) or examining the generated databases, Python is good language.

Since all simulations are CPU and memory consuming, I recommend to not use interpreted language like Java, Julia, Python, etc.

Compiled languages are converted directly into machine code that the processor can execute. As a result, they tend to be faster and more efficient to execute than interpreted languages. They also give the developer more control over hardware aspects, like memory management and CPU usage.

• I disagree incredibly strongly on saying not to use Julia. It matches my Fortran molecular dynamics and monte carlo algorithms for speed and took on the order of days to write. Also, writing parallel and GPU code is alot simpler.Final note: Julia is compiled to LLVM. – Charlie Crown May 4 at 22:20
• @CharlieCrown I fully agree: Julia is a Petaflop Club language, fast and scalable, and there is no reason to dismiss it. – Greg May 5 at 4:56

# Python

Python is definitely a good language for scientific calculation.

1. The syntax is very simple. It is not hard to implement some novel method and conduct preliminary tests.

2. The library is abundant. One could almost do everything in python. There are many open source libraries in python that implement a variety of libraries of scientific computing and data analysis.

3. It is not hard to build interface with other languages. One drawback of python is its low efficiency. While there are many ways to build interface to other languages(e.g. to build python-c interface, one could use Cython or cprofile):

• Python definitely can be fast if you optimize it carefully or use clever packages, and its flexibility makes it great for prototyping. But it's easy to write slow python code. In many cases, CPU time is less important than development time, and in those cases, the advantage of fast development time may outweigh the inefficiency of python. – taciteloquence May 5 at 7:15
• Julia is the same ease of writing, and gives you fortran speed out of the box. All you need to do is run @code_warntype to make sure you haven't accidentally changed a variables type (that really slows down the compiler when it does not know for sure what the types are). – Charlie Crown May 5 at 15:37
• @taciteloquence this reminds me of the quantum simulation package called SlowQuant: slowquant.readthedocs.io/en/latest – Nike Dattani May 5 at 16:17