Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Forpy - use Python in Fortran
500 views
Skip to first unread message
Elias Rabel
May 20, 2018, 4:28:23 PM5/20/18
to
Dear group,
I have developed a library for using Python in Fortran.
Link: https://github.com/ylikx/forpy
Now you can use your favourite Python modules in Fortran. Also Python data structures such
as list, tuple and dict can be used to some extent within Fortran.
It works with Python 2 (>= 2.7) and with Python 3 (>= 3.3).
It should work on x86_64 Linux with a recent gfortran or ifort.
Other systems should also work but lack testing.
See the included README.md for code examples and basic usage. Additional documentation can be
generated with the FORD documentation generator.
Aside from calling Python from Fortran it can also be used to develop
Python modules in Fortran.
I have developed a library for using Python in Fortran.
Link: https://github.com/ylikx/forpy
Now you can use your favourite Python modules in Fortran. Also Python data structures such
as list, tuple and dict can be used to some extent within Fortran.
It works with Python 2 (>= 2.7) and with Python 3 (>= 3.3).
It should work on x86_64 Linux with a recent gfortran or ifort.
Other systems should also work but lack testing.
See the included README.md for code examples and basic usage. Additional documentation can be
generated with the FORD documentation generator.
Aside from calling Python from Fortran it can also be used to develop
Python modules in Fortran.
Stefano Zaghi
May 20, 2018, 11:15:41 PM5/20/18
to
Dear Elias,
This sounds very very interesting!
Great work, I'll try it soon.
Thank very much for sharing your work.
My best regards.
This sounds very very interesting!
Great work, I'll try it soon.
Thank very much for sharing your work.
My best regards.
Rudi Gaelzer
May 21, 2018, 8:22:34 AM5/21/18
to
Seems to me something I've been waiting for quite some time...
I need to access the special functions library provided by MPMath in almost all my applications.
What I've been doing so far was to write a C function which acts as a driver to access MPMath via C/Py API and then return the result to Fortran via C interoperability.
Your forpy_mod seems to access python modules directly, without the need of the "middle-man" C function.
I'll be certainly testing Forpy ASAP...
Thanks a lot for the contribution!
I need to access the special functions library provided by MPMath in almost all my applications.
What I've been doing so far was to write a C function which acts as a driver to access MPMath via C/Py API and then return the result to Fortran via C interoperability.
Your forpy_mod seems to access python modules directly, without the need of the "middle-man" C function.
I'll be certainly testing Forpy ASAP...
Thanks a lot for the contribution!
michael siehl
May 25, 2018, 11:02:22 AM5/25/18
to
Just to give another idea about the opportunities of linking Python with Fortran in the near future:
As someone using coarrays (PGAS), where we could develop new classes of parallel algorithms and applications that are merely controlled by (remote) data movement, I currently do focus on minimizing and optimizing of such data movement (using remote atomics) and am rather skeptical that one could do such easily using MPI/C/C++. So, even if we are a tiny coarray community, chances are that we will be able to do novel things on upcoming parallel hardware using Fortran.
What we can already see from the Aurora 2021 (http://aurora.alcf.anl.gov/ -no information there, one can only enjoy the colors yet-), it could bring a new class of (kind of) multiple-purpose multi/many core processor, that will combine capabilities of machine learning with such for data-intensive computing, to only mention these both.
If it comes as I do currently believe, Python and Fortran will share upcoming novel hardware for quite different purposes but with the possibility to combine the both.
Best Regards
Elias Rabel
May 25, 2018, 12:05:20 PM5/25/18
to
Thanks, it's nice to read about possible use cases!
andri.r...@gmail.com
Apr 3, 2020, 5:37:05 PM4/3/20
to
Hello,
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)?
Is `forpy` the way forward? Is this an active project that will be well maintained into the future?
Thanks,
Andri
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)?
Is `forpy` the way forward? Is this an active project that will be well maintained into the future?
Thanks,
Andri
David Duffy
Apr 4, 2020, 5:26:36 AM4/4/20
to
andri.r...@gmail.com wrote:
>
> Our current code base is largely Fortran (400K LOC, most F90/some F77/maybe
> some newer versions)
>
>
> Our current code base is largely Fortran (400K LOC, most F90/some F77/maybe
> some newer versions)
>
> 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.
>
> From discussions online - and my intuition, whatever that???s worth
> and writing it in a faster-to-develop language (Python), and wrapping
> and extending bottlenecks in Fortran.
>
> ??? it seems unadvised to embed Python like this, and instead do the
> reverse: extend Python with Fortran (for bottlenecks, as needed).
>
FWIW, this is the commonest pattern I am familiar with, with a top-level
>
glue language, such as R, calling Fortran. You have not really told
us what Python is offering you. If you are talking numeric codes,
then prototyping in one language and rewriting from scratch in Fortran
might actually be efficient, as it is one approach to testing algorithm
correctness and hopefully getting speed. I would think that you can
implement any high-level data structures like Python dictionaries in
modern Fortran. Wanting to interface Python libraries, for say graphical
input or output options, is a different question. or do you want
something fancy, like symbolic algebra?
Forpy looks really fun, btw (I was not familiar with it).
Just 2c, David Duffy.
Thomas Koenig
Apr 4, 2020, 5:48:23 AM4/4/20
to
andri.r...@gmail.com <andri.r...@gmail.com> schrieb:
> 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.
Not sure that this is best practice, Python is notoriusly unstable.
You might want to read
https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
beforehand.
> 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.
You might want to read
https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
beforehand.
0 new messages