Porting research software to fpm

[awvwgk]

Finally, I'm able to port my first actual Fortran research project to fpm! 🎉

The program is called dftd4 and implements the model with the same name, DFT-D4, a dispersion correction for density functional theory. It has been published two year ago in J. Chem. Phys. (DOI: 10.1063/1.5090222) and is integrated in several large quantum chemistry packages (Turbomole, Orca, Vasp, AMS, Molpro, ...). Now it is also easily usable with fpm.

The overall arc of porting dftd4 to fpm lead to a number of associated projects, splitting the monolithic code base into smaller chunks, with this project there are now also several other pieces available:

• mctc-lib: backend to handle molecular and periodic geometries, computational chemistry input and output
• multicharge: the atomic charge model developed to make the difference between DFT-D3 and DFT-D4
• mstore: molecular structures store to easily setup tests on known compounds
• dftd3: original DFT-D3 dispersion correction, predecessor of the DFT-D4 model

I'm not yet relying completely on fpm, all projects support the meson build system as well, which is also handling the library interdependencies between those Fortran projects. It is a quite powerful build-system and in my opinion a good inspiration of what fpm should be able to do at some point.

So what about your scientific software? Can it be used today with fpm? What is holding you back? Where should fpm improve?

[urbanjost]

Wondered about your feedback on your own transition. Did this help you modularize your package or make it easier to build, to test, ...? Anything particularly good or bad to report?

[awvwgk]

The main goal to refactor the projects in the first place was to create simpler and more robust API which provides similar functionality in Fortran, C and Python. Frankly, none of this new functionality is really available with the fpm version.

Yet, fpm did help me a lot with this transition, not only fpm itself but the work on fpm was quite insightful. I spend some time studying build systems (mainly meson) to learn about package and dependency management, which came in handy for the more modular setup in meson.

I actually used fpm to prototype each of the packages and quickly setup a testing framework to add the wanted functionality in a test-driven strategy (the unit testing framework I used is a revised version of the one I wrote for fpm itself). Once the package was functional enough, I switched to meson for the better compiler support, coverage analysis and cross platform support to finish the implementation and smooth out the public API.

Also, dropping a lost attempt on a package turned out to be less resource consuming since the early stage was just fpm based, which really made this effort only possible.

[milancurcic]

https://umwm.org/ is my main candidate for fpm, but I've been resistant to port it before a significant refactor and clean up. Most of the code I wrote early in my Fortran journey in 2010-11 and I cringe looking at most of it, despite the project being relatively successful and used in various applications outside of my circles. But that's just my personal resistance and not a rational argument. UMWM requires NetCDF and optionally MPI, and I think it's possible to require those in fpm already, at least as a hack perhaps.

[awvwgk]

I know the feeling, dftd4 is my first Fortran project as well, it's now in version 3, so this is actually the second time I refactored it (first refactor was an actual methodical change in the model itself). I was quite hesitant for a while to touch the version 2 codebase because I anticipated it to be a lot of work to resolve the underlying awkward design. Turned out it was indeed a lot of work to do the refactoring, but worth every minute given simplicity to interface with Fortran, C and Python using basically the same API.

[ivan-pi]

One of my research topics are meshless methods for PDEs. Ever since fpm has been in the making I have been trying to adopt a very modular approach so I could release some parts of the code separately (ticked box means fpm is already supported):

• Interfaces to k-D tree libraries:
  • fortran-flann
  • kdtree2
  • nanoflann (still under a private branch)
• Graph partitioning
  • fortran-metis
  • Fortran-KaHIP-Interface
• Point cloud generators (still working on these)
• Approximations using radial basis functions or weighted least squares (requires LAPACK interface)
• Assembly of PDE operators into sparse matrices

The last three bullet points are only a few months old and I haven't quite reached a stable API yet. At some point I also stopped using fpm during development because I couldn't afford the time figuring out integration with Intel MKL (see #330) which I use for my sparse matrix vector multiplication.

I still need to develop tests for most of these packages.