My main fortran project is a model of atmospheric chemistry called PhotochemPy. It relies heavily on f2py. To build I use CMake with skbuild, which I think is a great build system (simple examples if you are interested).
Context: PhotochemPy is my attempt to modernize a Fortran 77 version of the code called Atmos. There are a bunch of annoying things about the Fortran 77 version. For example, all array lengths are set at compile time, so if you add a molecule or reaction, you need to recompile the whole program.
What went well: I like f2py because wrapping is automatic - when I add a new module variable, f2py will automatically create the setter and getter functions so I can access that variable from python. This is essential for projects that are changing quickly. I don’t want to spend a ton of time creating a wrapper, which will be broken next week because of changes I made to the code.
What went wrong (excluding the lack of derived type support):
- It took me so long to discover and to figure out how to use the
skbuild + CMake + f2py build approach. CMake is really nice here because I can compile project dependencies (written in C or C++ or whatever), then link them later when generating the python wrapper. Again, here is a simple example
-
character, allocatable module arrays don’t work with f2py
-
Numba can not call fortran code wrapped with f2py. You must use ctypes instead.
- control-c doesn’t stop fortran called from python
- callback errors are possible but not easy.
What role do wrapper generators have in the future of Fortran?: I think they have a very big role for scientist who model stuff. Graduate students in science usually start with very little experience in coding. Usually they will have some experience with Python or Matlab. But they don’t know what a compiler is, or understand the importance of types (because they started with python), or understand pointers, or objects, etc. This is all understandable because their main job is to know math and physics. I speak from personal experience here.
However, their advisors give them an old Fortran codes to work with. Given their lack of familiarity with Fortran, they will want to interact with this code via python. This is understandable. Scripting in python is so easy and intuitive, and will be hard to beat (even with LFortran). However, most often graduate students use a file-wrapping approach: in python, they write a file with some inputs, then run a Fortran executable which reads those inputs and does stuff, and then makes an output file, which is read by python. This sucks for a bunch of reasons.
It would be great if graduate students (and other researchers) had a wrapping tool like f2py, but just worked all the time with absolutely excellent documentation aimed toward the graduate student who doesn’t know anything.
Side Comment on documentatin: One of the great drawbacks of Julia is that the documentation IS NOT aimed at the graduate student who knows nothing about computer science. They basically assume you come from a C or C++ background. There is where LFortran and fortran-lang can shine. Documentation and user experience should be aimed at computer science dummies like most scientists.