3

Our current code base is largely Fortran (400K LOC, most F90/some F77/maybe some newer versions), dispersed amongst some 10 separate dev teams (organizationally) in (somewhat) standalone modules.

We are exploring the best practice idea of taking one of those modules and writing it in a faster-to-develop language (Python), and wrapping and extending bottlenecks in Fortran.

However, since the module is currently completely in Fortran and interacts with other Fortran modules and a main Fortran loop, we need to keep the appearance or interface of the module to main Fortran loop the same.

So the incremental change approach for this Fortran module – and other similarly architected Fortran modules – is to keep the interfaces the same and change the internals.

In other words, the shell or signature of the Fortran subroutines or functions would be unchanged, but the functionality inside the function would be changed.

This functionality inside the function is what we want to rewrite in Python.

From discussions online - and my intuition, whatever that’s worth – it seems unadvised to embed Python like this, and instead do the reverse: extend Python with Fortran (for bottlenecks, as needed).

However, this embedding Python approach seems the only logical, smallest, atomic step forward to isolate changes to the larger Fortran system.

It appears that there are some options for this embedding Python problem.

The most future-proof and stable way is via ISO_C_BINDING and using the Python C API (in theory…).

There are also stable solutions via Cython and maybe ctypes that are reliable and well maintained.

There are more dependency-heavy approaches like cffi and forpy, that introduce complexity for the benefit of not writing the additional C interface code.

We are also aware of simple system calls of Python scripts from Fortran, but these seem too disk write/read heavy; we would really like to do minimal disk reads/writes and keep the array passing in memory (hopefully just pointer locations passed, not array copies).

Another constraint is that this Fortran-Python interface should be able to handle most common datatypes and structures, including multi-dimensional arrays, or at least have a way to decompose complex custom datatypes to some collection of simpler datatypes like strings and arrays.

Given the above description, do you have any advice on what are the best practice ways that are currently available to call Python (or other similar flexible language) from Fortran (say, using 2003 or 2008 versions; not sure if all 2018 features are implemented in our Intel Fortran compiler)?

6
  • Those voting to close, please advise why. I don't have any feedback to go on. Commented Apr 3, 2020 at 22:38
  • Just guessing here, but they are voting to close because either because this isn't a programming issue per se (i.e. no code shown) or they are voting to close because the answers to your question would have to be "opinion-based". Some things I would need to offer an opinion (which I am not supposed to do) would be what is the OS? For instance, if you are using .NET Fortran, it might be easier to wrap in some .NET Iron Python modules. You are right though, in most cases you start Python and call your compiled language modules from there. Commented Apr 4, 2020 at 3:57
  • 3
    Here is my advice before someone closes this question. If your code is fully functional, but only written in F77, I strongly advise you to rewrite it in modern Fortran 2008 instead of Python or any other language. Modern Fortran is extremely expressive, comparable to Python or MATLAB. Also, translation from F77 to >F90 will be fast and easy. Rewriting your code in Python will only make your code slower by a factor of 100-500 times. That said, ctypes gives you access to all the primitive data type to interoperate with Fortran, including, character, real, integer, callback procedures... Commented Apr 4, 2020 at 20:41
  • If you decide to go with modern Fortran, here is a good reference book (I have no relations with the authors): "Modern Fortran Explained: Incorporating Fortran 2018" books.google.com/… Commented Apr 4, 2020 at 20:45
  • Thanks @King. The reason for Python is because of development speed, tooling like auto testing, and ability to use many external libs and APIs that have native Python support. All the critical performance code will stay in Fortran or will use fast Python (Numpy et al). Commented Apr 6, 2020 at 22:13

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.