I thought I was going to have this ready by FortranCon but alas, life got in the way.
After moving jobs and beginning to use Fortran more in earnest for my job (weather related) but still having an invited talk at a chemistry conference in December I had to quickly think about what could I do?
One of my passion projects is the modernization of legacy Fortran applications and sometimes the best way to modernize them is to introduce small, gradual replacements to certain technologies that are just too difficult to solve. This lead to me starting to write a library which I called pic which implements some routines I found myself coding up multiple times across the years and some compiler portable implementations of certain stdlib routines, such as “string” and “sort”, which fail to compile with nvfortran in stdlib and because I hate my life I set myself out to support every compiler I could get access to. The Cray compilers have been my nightmare. Luckily, I have no access to IBM compilers, although I did try…
I wanted to write an MPI wrapper, since I’d like to replace one in an app I help maintain - and I wanted to do it using the Fortran native modules. This lead me to find that some vendors have not instrumented the mpi_f08 module so if you profile anything with it, you’ll get blanks. Using vapaa circumvents this issue but it didn’t have all the functions I needed (I’ll be adding these later), so I had to resort to writing a “seamless” module that can transition between use mpi and use mpi_f08, this resulted in pic-mpi which is a wrapper for the MPI routines I needed to write this code for my talk in December.
Now, after this backstory…I’d like to introduce Met’al q’uicha, inspired by the Huastec word for “sunflower”. pic is not “particle in cell” but the Huastec word for “dog” which is kinda synonymous in the region to “water dog” or “otter”, that’s why there’s an otter in the logo. If anyone knows an artist, please let me know, I AI generated these logos and it bothers me.
Metalquicha aims to use the frameworks I’ve developed (mostly as a curiosity endeavor) to implement a very simple quantum chemistry application focused on fragmentation.
Fragmentation means taking a big molecules and chopping it into N fragments, which are then recombined using a many body expansion (MBE) to approximate the energy (or properties) of the unfragmented system. This is hierarchical, i.e. you get your monomers, you pair them to form dimers, then trimers, until the approximation is exact. It is usually truncated at the third or fourth order. Currently, I use the excellent tblite project as my chemistry engine. I have also created a series of safer interfaces to the most common used routine in quantum chemistry: integral evaluation here in the hope that it will accelerate development for people trying to use the library.
To my knowledge, this would be the first fragmented (albeit simple) implementation of gfn1 and gfn2 methods that is written entirely in Fortran and can run over many nodes without having to spawn many binaries. So this is neat.
The super nice thing about this methodology is that it is naively parallel, each fragment can be calculated independently, so yay for distributed parallelism! There are two main ways in which quantum chemistry can access large scale distributed parallelism and they both rely on having a solid MPI framework at the bottom. Metalquicha is just a demonstration of how you can orchestrate the diverse libraries I’ve tried to code up and how easy it is to use them.
This project is still in its infancy and I’ve done barely enough to give my talk in two weeks. It is also mostly done in my free time.
Throughout this project, I’ve tried to leverage as much as I can from the Fortran open source community. Among many things, I made sure that the code can be entirely built with the Fortran Package Manager, I use the CI tools provided by the language and by the conda action, I use test-drive for my unit testing, and I have an experimental branch that will try to use coarrays for the distributed parallelism. This experience has lead to me find bugs in lfortran, the fpm, and test-drive itself which most of them have been fixed by now! Also got to add some functionality to the FPM, supporting the new amdflang compiler.
The main goal for this project is to have a framework to access massively parallel resources with ease - I’ll be shifting my focus towards GPUs and making sure that I can enable memory transfers and management with ease through it. I am also using the framework as a baseline to implement new learning opportunities, such as a shallow water solver which I’d like to make it into a full flood simulator and a small scale ocean model (these are two projects).
Throughout this project I feel that I now fully identify as a “Pragmatist” category of Fortran programmers. See here for the list and description of each.
Thanks to @ivanpribec whose been the subject of my “I hate X compiler”, or “I hate MPI” rants and for his code review comments.