6
$\begingroup$

I thought Python was a reasonably popular language among matter modelers.

However, I saw a comment in one of my posted questions (in which I posted a Python code) that the commenter was unfamiliar with Python.

What programming languages do matter modelers generally use? Is it FORTRAN?

$\endgroup$
12
  • 1
    $\begingroup$ The answer would be different programming languages for different purposes. "Matter modeling" is a rather broad term. What application are you actually interested in? $\endgroup$ Jun 18 at 12:39
  • 2
    $\begingroup$ Possible duplicate from the early days of the site: mattermodeling.stackexchange.com/questions/365/…. Admittedly the question there is a little more prospective; there is a lot of enthusiasm about Julia and it might be useful to learn in the long run, a lot more current code is being written in C++/Python and you will definitely come across a mix of legacy and modern Fortran. $\endgroup$
    – Tyberius
    Jun 18 at 13:28
  • 1
    $\begingroup$ @user366312 These three are still very broad (and also very divergent) topics. $\endgroup$
    – Greg
    Jun 18 at 17:17
  • 5
    $\begingroup$ Your spelling "FORTRAN" suggests that your knowledge about this language might be very outdated. Please note that the language is spelled "Fortran" since 1990 and the old spelling "FORTRAN" is now reserved mostly when referring to the extremely obsolete versions from the 66 or 77 standards or even older IBM versions. $\endgroup$ Jun 19 at 12:48
  • 2
    $\begingroup$ @user366312 I did not mean the knowledge of the language but just a general knowledge (trivia) about it. $\endgroup$ Jun 19 at 14:36

3 Answers 3

10
$\begingroup$

I think, I saw similar questions on this stack exchange before, so you may also want to have a look at what others wrote about this topic. Let me answer this from the perspective of research software engineering and also based on my opinion (the answer to your question is, of course, subjective).

You can see research software engineering as a general term for software engineering in an academic environment. This comes with several constraints: You have small and rapidly changing development teams (often consisting only of a single person with limited software development experience doing a PhD thesis), software projects with unclear duration and scope, a multitude of rather special hardware architectures and software environments that may change over the duration of a project, specific (software development) expertise in a research group, and so on.

Such an environment narrows the number of reasonable options for the choice of programming languages. This may even be research-group or developer specific. From the perspective of hardware architectures and software environments, developers have more choices if they know beforehand that the program only has to run on their workstation or a similar computer.

If the program has to run on multiple compute nodes of a high-performance computing machine there are - in connection to the available software environments - mostly 3 viable options for programming languages: Fortran, C, and C++. All of these languages have specific advantages and disadvantages. C++, for example, comes with a large standard library of data structures and algorithms and also with many language features. This makes for a very powerful tool, but also a tool that demands a lot of expertise from the developer to not mess up things. Fortran, on the other hand, is much simpler to learn and comes with a language structure that is simple to understand for developers and also for compilers. A student with limited programming experience working on a thesis has it easier to write good and fast code in Fortran. The choice here would thus depend a little bit on the skills of the developer and the skills that are available in the research group. Of course, the demands from the project also play a role here.

When it comes to the development of toys, i.e., small test programs or prototypes, the automatization of workflows, or the preprocessing, postprocessing, and plotting of data, Python is a much more viable option, though the choice of programming language here also depends on the skills of the programmer. These applications are more likely to only run on a well-defined set of workstations and software-environments and the projects are typically smaller and have a more limited lifetime. Here, Python code may be more compact in comparison to many other languages and there are also many software libraries available that make the developer much more productive in such a setting. These many available software libraries, however, are both, an advantage and also a disadvantage. I saw several small, but very nice software projects die, because the associated "Python dependency hell" was not resolvable anymore after some time on another computer and for a different developer. Of course, there are measures to take care of this (for example docker containers) and also of problems arising from the dynamic interpretation of Python programs that may give the inexperienced programmer a syntax error after the program was running for hours or days. But a beginner programmer starts to address such problems only after they appear and then it may already be a little late.

Of course, there are also many more programming languages that may be good choices, depending on the respective context. I think the most important part is that the developer makes a well-founded choice what language to use, based on all relevant circumstances. In my answer I wanted to sketch a little bit some of the special circumstances that may play a role here.

$\endgroup$
10
  • 2
    $\begingroup$ "A student with limited programming experience working on a thesis has it easier to write good and fast code in Fortran." Um. Fast, perhaps yes. Good, very doubtful. Students with limited programming experience generally write bad code regardless of the programming language, but in Fortran (and Matlab) I've seen the worst atrocities in terms of code that is utterly unreadable and unmaintainable. Python or Java make these aspects a lot easier, and C and C++ at least bite you early so you learn to discipline yourself... $\endgroup$ Jun 19 at 9:42
  • 1
    $\begingroup$ As for Python dependency hell, I can confirm that. But this is not really to blame on the prevalent use of libraries per se, but rather on the way these libraries and the ecosystem generally are maintained, versioning handled, etc.. It's a mystery to me why the Python community is so haphazard with that. E.g. Java, Haskell and Rust are much better in this regard (as well as faster). $\endgroup$ Jun 19 at 9:49
  • 2
    $\begingroup$ Fortran is the most horrible language to use if you don't know what you're doing very well. I had a student that only had experience in Fortran write some molecular dynamics code for a seminar project (it wasn't doing anything new) and it was utterly unusable and I had to spend about twice as long to fix it as he did to write it. Fortran had its place in the past but to be honest there isn't really an actual benefit these days to it. $\endgroup$
    – Blackclaws
    Jun 19 at 11:51
  • 6
    $\begingroup$ @Blackclaws This anecdotal evidence is pretty worthless and it is easy to find students similarly confused from working with C and C++. Please note that there are huge differences between the old FORTRAN from the 1960s-1980s and modern Fortran. Unfortunately, some old professors old very bad old habits. The language is perfectly capable of a molecular dynamics software written in a clean way and I saw some pretty bad code written in C, C++ or Python. $\endgroup$ Jun 19 at 12:52
  • 2
    $\begingroup$ @Blackclaws And many students simply lack of any previous programming experience and good programming takes much more than the syntax and semantics of a language. Often they just receive on or in a good situation two semesters of progamming in which often time must be devoted to some basic usage of computers - like what directories are, what a command line is, difference between an editor a compiler and an IDE (True story! These are very inteligent students, but the CS oriented ones went to CS or CE majors.). These students need seriously more before they can develop good software. $\endgroup$ Jun 19 at 12:57
5
$\begingroup$

For an old-school modeler Python is a must. This language is not difficult to learn if you master another language. Having hundreds modules, you can solve almost all scientific problems, the possibilities are infinite from a scientific code to visualisation including processing of data.

The only drawback of Python is the speed, reason why it should be associated with the knowledge of a low level programming language either Fortran or C++. Fortran is the easiest one for a scientist but is limited by the number of librairies and a lack of interfaces. C++ is a tough one, however, after the basic principles are known you can almost do everything, including interfaces.

$\endgroup$
3
  • 4
    $\begingroup$ The speed issue is actually very relative when you look into libraries like JAX or Numba. Similarly with the recent development of superset language like Mojo we will probably have one day a language that has the versatility of Python and the speed of a low level language (Julia is also a good concurrent). +1 Python is a must $\endgroup$
    – Okano
    Jun 18 at 20:50
  • 1
    $\begingroup$ The speed issue is overlooked by many deferring to: "But there are bindings to low level libraries! Etc." However the speed issue crops up in the most unexpected places. Iterating over results using for? -> Speed issue After writing code to process raw data from a simulation in python because I thought it would be "easier" was one of the worst mistakes in my PhD. Even using numpy and other custom low level code still meant that mundane things like parallel processing that had to happen on the result level were stuck in python which is horrible for that. Only use python for orchestration. $\endgroup$
    – Blackclaws
    Jun 19 at 11:52
  • $\begingroup$ @Okano JAX and Numba are both far from general-purpose. Well, Numba is kind of general-purpose but only when writing in an extremely low-level style, in which case it would be better to write in C and link that to Python. Sure enough, lots of applications can be handled fine with these tools (to some extent a self-fulfilling truth, because Python is so popular anything that can be done efficiently with it will receive lots of attention). But many things can be much better done in a language that's designed upfront to compile to fast CPU instructions. $\endgroup$ Jun 19 at 12:39
-2
$\begingroup$

Another possible answer for "What programming languages do matter modelers generally use?" is none (or at most shell).

Many standard workflows for preparing, performing, and analysing molecular dynamics simulations have been fully coded into popular packages like GROMACS and LAMMPS. You just write scripts (or parameter packs) for these packages, feed in initial coordinates, and let 'em rip! All you need is shell to launch the simulations, and whatever visualiser you'd like to use to produce snapshots and graphs.

Note: I make no judgements as to whether this is a better or worse state of affairs in the world.

$\endgroup$
6
  • 1
    $\begingroup$ I think OP was looking for pointers to languages that were (are) used for writing these software and (or) to analyze the results. Bash is definitely a language that people must know, but other languages are also equally important. $\endgroup$ Jun 19 at 11:00
  • 2
    $\begingroup$ It is somewhat unlikely that one will be able to make it through a whole PhD, let alone a career in the field, using just the readily available tools with zero coding on top. Sooner or later you're bound to run into something that nobody has implemented yet. It might be a ten-line change to an existing software package to print some extra numbers, or a short Python script to analyze a hundred simulations, but it will likely be something not easily done in a shell script (or by hand). $\endgroup$
    – TooTea
    Jun 19 at 17:12
  • $\begingroup$ Plenty of senior academics, still employed and productive, will do all the analysis they can in Excel, and all the analysis they can't in Postdoc++. Again, not making any judgements about whether this is good or bad, but this is (for now) the current state of affairs. $\endgroup$ Jun 19 at 22:49
  • $\begingroup$ @ShernRenTee I don't believe any PhD-level modeller can make it through without knowing any programming language. I have only seen master students doing stuff that you mentioned (running existing softwares, Excel analysis, etc), but maybe it's a different scene in your country. $\endgroup$
    – Shaun Han
    Jul 11 at 9:25
  • $\begingroup$ My PhD was a very long time ago but I don't remember any Python in it. Plots in Gnuplot, math in Mathematica. I handled MD trajectories in (hideously uncompressed) plaintext, and at one point wrote a progressive rot+trans fitting script in awk. At one point I wrote a lattice diffusion population solver in Excel for someone whose main language, as far as I can tell, was Maple, and I didn't know either Maple or GraphPad (which was how they communicated with everyone else). $\endgroup$ Jul 11 at 10:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .