Fortran Python

Notes on fortran-python integration 13 Jan 2005

On reflection, it seems a bad idea to have modules that both export data to python and are also used for sharing data between fortran routines.

The problem is that f2py does not understand all of more recent fortran syntax very well. Hence, any fortran modules that need to be exposed to python have to be "dumbed-down" somewhat. These modules (call them f2py modules) can use other fortran modules with more adventurous syntax (call them private fortran modules). These are then merely linked to when running f2py. E.g.,

f2py  --fcompiler=Intel -c -m fmod4py f2py_modules.f90 private_fortran.o

The problem is if the private fortran modules want to use an f2py module. This is impossible without creating circular compile-time dependencies.

Hence, we must have

python ==import==> f2py_modules ==use==> private_f95_modules

application to geuler.py

At the moment (13 Jan 2005), we have a hopeless mess.

geuler.py imports evars.t, evars.dt

esolution.py imports

variables

evars.dx, evars.dt

functions

esetup.init_xgrid, esetup.init_pgrid, esolvers.solver

but the private fortran modules also use evars extensively

proposed solution

• Python API to fortran routines will be entirely via functions (no shared module variables).
• Vars such as t, dt, etc will be passed as arguments.
• evars will become a private fortran module.

did it work?

Yes! We now have in the Makefile

## dependencies among private fortran modules
PRIVATE_FMODULES=esolvers_private.o evars_private.o janemodules.o
esolvers_private.o: janemodules.o evars_private.o
janemodules.o: evars_private.o

## modules exported to python
esetup.so: esetup.f90 $(PRIVATE_FMODULES)
	f2py  --fcompiler=Intel -c -m esetup esetup.f90 $(PRIVATE_FMODULES)
esolvers.so: esolvers.f90 $(PRIVATE_FMODULES)
	f2py  --fcompiler=Intel -c -m esolvers esolvers.f90 $(PRIVATE_FMODULES)