|
|
|
|
|
|
by morvita
1248 days ago
|
|
|
I did a PhD and Post-doc in computational chemistry (focusing on quantum chemical simulations) in the late 2000s/early 2010s and nearly all the software I used was written partially or wholly in Fortran including Gaussian, Q-Chem, Quantum Espresso, and NWChem. Most of the professors I worked with only knew Fortran and had no interest in learning C/C++. The one exception was a professor who was in the process of porting her group's in-house molecular mechanics software from Fortran to C/C++ (don't remember which) so they could get it running on GPUs easily. I think one of the driving factors in this is that, as other people in this thread have discussed, most of the people writing this software are not software developers and have no interest in being software developers. The scientists trained in the 60s/70s/80s learned Fortran, who then founded their own research groups and taught their students Fortran, who are now running their own groups using Fortran because it's what they know. Some folks use Python for data analysis after their simulations run, but even that was rare 10 years ago. |
|
|
I'll add another factor to your consideration. Quantum chemistry is mathematically and numerically more challenging than molecular dynamics, and requires a more advanced understanding of chemistry than MD does of chemistry or physics.
I suspect this makes MD codes easier to implement, and more open to multi-disciplinary development, than QC codes.
This thought comes from my experience. My PI at Illinois was Klaus Schulten, who was a postdoc in Karplus's lab at Harvard. Karplus's group developed CHARMM, written in Fortan.
Our lab also used Axel Brunger's X-PLOR, another Fortran code. I know we had a source license to X-PLOR.
If the factor you described were the dominate one, we should have been a Fortran shop.
Yet in the late 1980s/early 1990s (before my time) there were grad students in the group writing their own MD codes, one in C and another in Occam. (Occam was developed for writing parallel algorithms on a transputer. The transputer was seen as the future of parallel computing. The grad students before me built their own hardware around the transputer.)
My generation then developed NAMD using C++. The primary author, Mark Nelson, who had been maintaining one of the older codes, and was annoyed with it. He was grad student from CS (or EE?), with software industry experience before going to grad school. Two other grad students - Bill Humphrey and I - were in physics but had undergrad CS training. Plus, the group itself was multidisciplinary, with Laxmikant Kale's group in the CS department, who developed the Charm++ language. (Also, we collaborated with John Board's group from the EE department at Duke, to use their multipole package for long-distance electrostatics; that was in C or C++.)
Which means in our group alone there were at least three locally-developed MD codes. Each one targeted a different way of handling parallelism.
This was possible because the core MD engine is pretty simple. Adding different integration types, and parameterizing the force field, and developing faster approximate methods to handle hydrogen dynamics, and other aspects of MD are not so simple, but the core is still something many undergrads could write.
While QM codes require a more specialized knowledge that I certainly never learned, and which isn't easy to pick up by non-chemists, leading to a more isolated development culture passed on in the way you describe.