openscm
Calling the FORTRAN directly
We're a long way off this but I thought I'd start the conversation so we at least have somewhere we can record our thoughts.
Is your feature request related to a problem? Please describe.
At the moment pymagicc runs the binary then reads the output files. This is obviously slow and it would be much better to just compile the FORTRAN into modules that can be called from Python.
Describe the solution you'd like
A way to call the different MAGICC modules (once we modulise it), as written in FORTRAN, from Python and run the whole thing in memory rather than using all this input/output code.
Describe alternatives you've considered
Stick with the current way forever. I don't think this is a very good alternative.
Additional context
I have no idea how we pull this off. This resource from numpy (https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-as-glue.html) seems like a good starting point but others probably know more (@rgieseke @lewisjared @swillner). It obviously also depends on the FORTRAN becoming modularised. As I said, this issue is intended more as a sandbox for resources/planning than putting anything into production right now.
Some pointers for future reference ...
F2PY
https://docs.scipy.org/doc/numpy/f2py/
- to call Fortran 77/90/95 external subroutines and Fortran 90/95 module subroutines as well as C functions;
- to access Fortran 77 COMMON blocks and Fortran 90/95 module data, including allocatable arrays
f90wrap
https://github.com/jameskermode/f90wrap
f90wrap is a tool to automatically generate Python extension modules which interface to Fortran code that makes use of derived types. It builds on the capabilities of the popular f2py utility by generating a simpler Fortran 90 interface to the original Fortran code which is then suitable for wrapping with f2py, together with a higher-level Pythonic wrapper that makes the existance of an additional layer transparent to the final user.
F2x
https://github.com/DLR-SC/F2x
F2x differs from other FORTRAN wrappers quite a bit. The basic flow is as follows: It uses a full FORTRAN 2008 grammar (adapted from the OpenFortranProject). This is fed to PlyPlus for transforming the source code into an AST. The AST is then queried by the template to generate the code.
Would be great! The actual wrapping would probably be easy, but the current state of the MAGICC source code is far from being modularized...
I spent quite some time back in the days to make magicc be understood by f2py and f90wrap. failed. A main problem is the all-over use of global variables. The MOD_DATASTORE module exemplifies this. It is loaded in most of the subroutines, exposing almost all variables as global within each subroutine.
