Ported a C code to Fortran, etiquette around it?

Hi all, over the weekend with the help of Claude I took a the libcint library for quantum chemistry whose main code is generated via a lisp script to produce Fortran instead of C. I did this mostly as an experiment to see the difference in performance between the C code and the Fortran code for my application. Especially since the evaluation of the integrals performed by libcint can scale around O(N^4) so fast integrals are always needed in the QC.

As of now, performance seems to get a 5-8% penalty compared to C and I have narrowed it down to the Fortran compiler generating a couple more instructions than the C compiler. I’ve verified this across gfortran and ifx.

Before I push this code, I realize that this is port might not be at home in the same repository, since not all code is autogenerated. I was thinking on creating a new repository and clearly adverting that this is a Fortran port of the original library (I kept the interface) and cite and acknowledge the original code. For those that have something similar to this, is this the best approach or does anyone have a suggestion?

Another interest for me is producing a large and rather complex codebase for LFortran to try to compile. Plus navigating Fortran deps is easier if I can use the FPM for this. I know that fpm can compile C but dealing with the macros and partial includes was a bit painful in the C.

Cheers

First of all, excellent! Once you are ready, send the code over and let’s fix LFortran to compile it. And then later, once we are in beta, to also optimize it well.

If the original C code was yours, then you can do anything you want. Since the original C code is not yours, then I think you have to treat your Fortran port as derivative work (since you didn’t do a clean room reimplementation), so you have to follow the license, which in this case is Apache-2.0, which I think (check it) allows you to relicense, as long as you satisfy some attribution conditions. I think that’s as far as what you have to do.

Regarding good practice, I would mention at the top of the README that this is a Fortran port of the original library (cite it based on the instructions at https://github.com/sunqm/libcint#how-to-cite) and clarify the license situation, to make it clear.

Regarding if this should be a new repository: if you plan to maintain it in Fortran going forward, then I would keep it in a separate repository. You can also ask the original authors, it looks like @JeffH contributed some openmp stuff to the original code, maybe he has some opinions on this.

Congratulations on such a great job! Do you have any plan for libint2, another commonly-used open source library for computing Gaussian integrals? It is written in C++, and is also a generator + some generated code for common cases. The main difference is that it uses a completely different algorithm.

Depends on my level of masochism if I’d do this. Libint shouldn’t be too hard because it does rely on their compiler so in theory it should just be making sure it emits Fortran instead of C++

The issue is that libint uses boost and my one experience with boost 10 years ago left me scarred. I’m taking 3 weeks off work later this year so I’ll have time to do hobby stuff…so keep your eyes open!

I’ll push the Fortran version in an hour or so