Lejaeghere et. al studied reproducibility of DFT codes (softwares) by comparing 15 different codes employing 40 different potentials. The study concluded that most codes agree very well, with pairwise differences that are comparable to those between different high-precision experiments.

Why do we have so many different codes? Are they redundant?

  • 2
    $\begingroup$ I presume you are referring to software packages not functionals $\endgroup$ – Cody Aldaz Apr 29 '20 at 20:41
  • 4
    $\begingroup$ Yes. Like VASP, SIESTA, CASTEP, QE etc. $\endgroup$ – Thomas Apr 29 '20 at 20:44
  • 1
    $\begingroup$ The question is very broad, calling for an extremely long answer,if one aims for quality. Maybe rephrasing and even moving part of the content to an independent question would be more helpful in the long run. $\endgroup$ – agaitaarino Apr 30 '20 at 16:21
  • 1
    $\begingroup$ I have removed the last part of the question. If not what makes each of them unique? $\endgroup$ – Thomas Apr 30 '20 at 16:51

There are many reasons why so many different scientific packages have been developed

  1. These packages were developed by individual researchers who were in competition with each other and also work mostly independently. It was natural that different packages sprung out of different regions (e.g. NWChem stands for NorthWest Chem, because it’s based at Pacific Northwest National Lab (PNNL)) and for different purposes or specialties (e.g. Molpro for excited-states). Also remember that this was before version control or the idea of open-access was a thing, so sharing code was not so easy.

  2. The opportunity to make money with the software was also a huge draw and further enticed people to start there own company, or in contrast distance themselves from the company because of their own personal beliefs. For example, the company Gaussian has a well known history of controversy with some scientists over how the company was ran (perhaps even with the founder of Gaussian itself, John Pople).

  3. Despite the code similarity most scientific software is very poorly managed because the developers work independently and are not computer programmers. So in many cases, people wanted to start something fresh in an attempt to make it better, or easier for them to write their own custom code. Again, open-access and object oriented programming is fairly recent. A great example of a software package that was developed to make reading and improving the code is OpenMM. And because of this, OpenMM now has superior GPU kernels and object oriented design making it one of the best and fastest codes for molecular dynamics today.

  4. There is also a difference in preferred languages. Historically scientific software was written in Fortran. Then people started using C/C++. Nowadays people are even using python!

It is my opinion that all types of codes should be continued to be developed independently but hopefully they follow good coding practices like object-oriented programming. If that is the case then it's easy to mix and match code from different developers.

  • 6
    $\begingroup$ In my opinion, different codes for different programming languages are reasonable, since different languages have their own strength in certain regimes. For example, KSSOLV in Matlab and Pyscf in Python serve as practical productive code and also easier for algorithm development. Also using this two languages make the code easy to run across-system-platform, e.g., ubuntu, windows, macos, etc. However, one troublesome thing is that many codes are actually producing quantitatively different results (this should be somewhat corrected). $\endgroup$ – Yingzhou Li Apr 29 '20 at 22:45
  • 1
    $\begingroup$ You should post this as an answer :) $\endgroup$ – Cody Aldaz Apr 29 '20 at 22:52
  • 1
    $\begingroup$ @YingzhouLi , we need to have an average of 2.5 answers per question to meet the suggested criteria here for getting the site approved: area51.stackexchange.com/proposals/122958/materials-modeling. Also, comments are temporary and often get deleted permanently to increase signal-to-noise ratio, so I suggest you write this as an answer! Seems you could have had 3 upvotes by now! $\endgroup$ – Nike Dattani Apr 30 '20 at 0:06
  • 1
    $\begingroup$ You should add this as an answer. It is relevant $\endgroup$ – Thomas May 1 '20 at 1:19
  • 1
    $\begingroup$ Overall a good answer, but "good coding practices like object-oriented programming". What the heck? You can write atrocious object orientated code. It is NOT inherently superior. Depending on the problem it might be a good choice or it might not be. Clarity of code, from consistent naming convention, clear structure and good commenting/documentation and overall consistency are more important than the method of choice, be it object orientated or functional programming. $\endgroup$ – DetlevCM May 16 '20 at 10:24

There are many reasons why we have so many different density functional theory programs, and it would be nigh on impossible to give a full answer encompassing all of them. A brief, select few:

  • Scientific reasons, because you need something that can handle some very specific physics or chemistry accurately and efficiently. At a simple level it might be that a particular basis set is most appropriate for the task you want, but there are many other considerations. You might want to treat solvation as an integral part of the problem (e.g. JDFTx), or not use the Born-Oppenheimer approximation etc.

  • Technical reasons, for example you really need methods which are efficient on some very particular hardware (e.g. with extreme parallelism, or accelerators, or very long vector machines), or are written in a particular language in order to integrate with some other software or workflow.

  • Philosophical design reasons. Perhaps you want a single program which can do all the kinds of calculations you want, or perhaps you prefer a suite of smaller, more specialised programs. Maybe you want something you can rapidly prototype new methods in and don't care about performance or features.

  • Personal reasons. Perhaps you want some software to your name to enhance your career, or perhaps you fell out with the authors of the "usual" choice (or vice versa). Perhaps your intended use of the software isn't compatible with the licence of the usual programs, e.g. because you're doing research which is commercial or classified.

  • Inertia. Now that we have all of these different programs, what is the incentive for developer communities to merge and settle on one particular software and approach?

  • Pedagogical reasons, for example someone wants to really understand how the theory and algorithms work. Many of my own PhD students write their own density functional theory program for this reason, though these are not used for real applications.

  • It isn't very hard! Writing a very basic, full-potential, all-electron density functional theory program is relatively straightforward. It will not be fast or scalable, nor will it compute very much -- probably just the ground state energy, density and Kohn-Sham states -- but it will work.

Finally, I'd like to note that having several implementations, even when they make the same major design choices (e.g. basis set; wavefunction or Green's function approaches), gives some competition, and this can be healthy. The Science paper referenced in the question demonstrates the benefit of this: the good agreement between the programs has not always been there, indeed it is partly due to the work behind this paper that the programs do agree so well; when we found an outlier in our tests, we worked hard to understand why and fix any issues. Reproducibility is a serious issue in research, and the ability to apply two (or more) completely independent implementations of the theory to a scientific problem is extremely valuable.

Another benefit of competition is that developers don't generally like it when a different program can do something theirs can't, or is faster, or scales better or... so competition can lead to improvements for everyone.

So in summary: there are lots of reasons why people write their own programs. Having a variety of design choices is good, but even having several implementations with similar design choices is healthy. Are there "too many" implementations? Possibly, but the "ideal" number of implementations is more than one or two.

  • $\begingroup$ To elaborate on the basis set question: I am currently working on implementing an advanced correction method into DFT codes. I want the scientific background to be independent of the implementation, so to achieve this, I have to contribute to three different DFT codes. I am using QEspresso for the plane wave basis set, FHI-AIMS for the numerical basis set and Q-Chem for the Gaussian basis sets. The idea behind the codes is the same, however, the practical implementation (and the applicability too) diverges just because of the different choice of basis set $\endgroup$ – Ezze May 15 '20 at 7:34

Another thing not mentioned yet is that there are, broadly speaking, two camps of codes: those that are primarily meant for periodic (often but not exclusively plane-wave) DFT (VASP, Quantum Espresso, etc.), and those that are primarily meant for finite systems like molecules (e.g. Gaussian, ORCA). Also, there are different algorithms in each package, some of which may better suit a given user. There's also a number of packages recently that are meant to be open-source (or at least free) alternatives of paid packages that have dominated the field.


I would like to stress the importance of the choice of the numerical algorithm, which was briefly touched on above. The choice of the representation (plane waves, augmented plane-waves, finite elements, finite differences, multiresolution grids, or atomic orbitals: Slater-type orbitals, Gaussian-type orbitals, or numerical atomic orbitals) determines the algorithms one can use and the properties one can study; in addition with a given numerical representation one may have to choose between different styles of pseudopotentials. No code will cover all possibilities, since traditionally scientific software is not very modular and cleanly structured, and the different approaches may not have a lot of common ground infrastructure wise.

Fortunately, modularization has happened, and e.g. common ground has been established for the evaluation of density functionals which is now typically handled by a common purpose-built library.

  • 1
    $\begingroup$ Good point. One major difference is between compact basis sets (e.g. Gaussians) where a full matrix diagonalisation may be used to solve the Kohn-Sham states, and large basis sets (e.g. plane-waves) where iterative diagonalisation is the practical approach. Similarly, if you have to use a Fast Fourier Transform then you have to work quite hard to get good parallel scaling on large machines. $\endgroup$ – Phil Hasnip May 18 '20 at 11:35

Another reason can be the choice of Hamiltonian, for example relativistic vs. non-relativistic (especially spin-orbit including). In relativistic theories, the orbitals are complex as opposed to real orbitals in non-relativistic codes, so it has to be programmed accordingly. Moreover, relativistic orbitals possess a multi-component spinor structure, meaning that some objects suddenly become vectors or matrices and do not commute any more. This means that many core routines, especially when aiming for an optimized efficient code, will end up different in relativistic and non-relativistic codes.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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