Interfacing Fortran applications

[Michael Welle]

Hello,

I want to build a Python based user interface for an existing Fortran
application (as everyone wants to do ). Lets assume the application is
parametrised via cmdline parameters and it calculates tons of numbers
that have to find their way into the Python UI. There are several ways
to achieve this: using stdin/stdout to exchange data, using files,
converting the application to a library and load that from Python,
etc.

I thought about equipping the Fortran application with sockets, so that
I can send input data and commands (which is now done via cmd line) and
reading output data back. Any opinions on this? Best pratices?

Regards
hmw

 

[Chris Angelico]

I want to build a Python based user interface for an existing Fortran
application (as everyone wants to do ). Lets assume the application is
parametrised via cmdline parameters and it calculates tons of numbers
that have to find their way into the Python UI. There are several ways
to achieve this: using stdin/stdout to exchange data, using files,
converting the application to a library and load that from Python,
etc.

I thought about equipping the Fortran application with sockets, so that
I can send input data and commands (which is now done via cmd line) and
reading output data back. Any opinions on this? Best pratices?

Is the application a complete black box? Sounds to me like you have
the power to edit it, so I'm guessing you have the source code and
some knowledge of how it works. If you can, as you suggest, convert it
into a library that can be called from a C program, you can use Cython
to call on it from Python. That'd be my first recommendation.

(One-and-a-halfth recommendation: If the actual application is very
simple, and most of its work is done in library functions, access the
library via Cython, and port the main application logic entirely into
Python. No need to wrap the application into a library, that way.)

Second option would be some kind of coroutine system, interfacing via
a socket. That's quite a good option; all you have to do is settle,
between the two, a set of protocol rules. Some examples:
* Everything is encoded in ASCII. (That gives you the option of
expanding to UTF-8 later, if you need full Unicode, but keeps it
really easy for now.)
* Commands and responses are terminated with end-of-line, 0x0A.
* Commands follow the basic shell style of command, then a space
(0x20), then parameters.
* If you don't need to overlay responses: One command's responses end
with a dot (0x2E) on a blank line. (See SMTP for an example of this.)
* If you do need to have multiple commands in flight simultaneously:
Every command is prefixed with an arbitrary token, followed by a
space, and every line of response is prefixed with the same token.
(See IMAP for an example of this.)

Nut out your protocol first, before you write a single line of code.
Keep your protocol document up-to-date if you change anything. Then,
if you want to write a different program for one end or the other, you
can guarantee that they'll be able to communicate. And if you want to
change from Unix sockets to TCP/IP sockets, or to stdin/stdout, or to
any other system, the translation will be easier for having that
document.

Third option: Keep the application as it is, and use Python's
subprocess module to send it parameters and maybe stdin, and retrieve
its stdout.

 

[Michael Welle]

Hello,

Is the application a complete black box? Sounds to me like you have
the power to edit it, so I'm guessing you have the source code and
some knowledge of how it works. If you can, as you suggest, convert it
into a library that can be called from a C program, you can use Cython
to call on it from Python. That'd be my first recommendation.

yes, I can change the application. I want to change it as little as
necessary, but I'm willing to do more code changes to get the job done
right.

(One-and-a-halfth recommendation: If the actual application is very
simple, and most of its work is done in library functions, access the
library via Cython, and port the main application logic entirely into
Python. No need to wrap the application into a library, that way.)

I would say it's a typical Fortran application. That tells something
about the simplicity .

Second option would be some kind of coroutine system, interfacing via
a socket. That's quite a good option; all you have to do is settle,
between the two, a set of protocol rules. Some examples:

[...]
Jepp, I've designed Java APIs before, that talk to ODBMS. That works
very similar.

Third option: Keep the application as it is, and use Python's
subprocess module to send it parameters and maybe stdin, and retrieve
its stdout.

That is the simplest approach I think.

I have to think over it a little bit more. It's esp. interesting what
happens with the (possible huge) data sets, how often do they need to be
copied while transfering them between the two sides etc.

I have to say that I'm new to Python. So maybe I should squeeze out some
time and implement all three approaches just to exercise my Python skills.


Regards
hmw

 

[Sturla Molden]

I thought about equipping the Fortran application with sockets, so that
I can send input data and commands (which is now done via cmd line) and
reading output data back. Any opinions on this? Best pratices?

If you are to rewrite the Fortran app you can just as well use f2py from
NumPy.

Sturla

 

[Michael Welle]

Hello,

If you are to rewrite the Fortran app you can just as well use f2py from
NumPy.

a rewrite of the application isn't possible. That would require
knowledge about what the used algorithms are, why they are implemented
as they are, that would require extensive testing with test cases that
don't exist. I can change as much as I want, as long as the core of
the application isn't touched. I can change everything until after the
initialisation of the application and the output of the results. That,
hopefully, will not break something.

Regards
hmw

 

[Chris Angelico]

I can change everything until after the
initialisation of the application and the output of the results. That,
hopefully, will not break something.

Okay. So you should be able to go for the socket approach, fairly
easily. Or possibly you could turn the whole thing into a C-callable
library, although I've no idea how easy it is to do that. (My
experience with FORTRAN - yes, not Fortran, the code was that old -
goes as far as eyeballing some of IBM's DB2 examples and translating
them into REXX. I've never actually used a Fortran compiler.)

ChrisA

 

[Michael Welle]

Hello,

Okay. So you should be able to go for the socket approach, fairly
easily. Or possibly you could turn the whole thing into a C-callable
library, although I've no idea how easy it is to do that. (My
experience with FORTRAN - yes, not Fortran, the code was that old -
goes as far as eyeballing some of IBM's DB2 examples and translating
them into REXX. I've never actually used a Fortran compiler.)

in the simplest case you can convert the 'main function' to some other
function that you call from the Python script. Then you have to
implement a mechanism for getting data in and out of the application.
The rest depends on the application, implementing a demo is easy .

Regards
hmw

 

[Sturla Molden]

a rewrite of the application isn't possible. That would require
knowledge about what the used algorithms are, why they are implemented
as they are, that would require extensive testing with test cases that
don't exist.

You are ok with adding sockets and IPC to a Fortran app, but using f2py
is off limits because it requires a rewrite? Sorry, this doesn't make
any sense. But it's your problem, I don't care what you decide to do.


Sturla

 

[Michael Welle]

Hello,

You are ok with adding sockets and IPC to a Fortran app, but using
f2py is off limits because it requires a rewrite? Sorry, this doesn't
make any sense. But it's your problem, I don't care what you decide to
do.

at least there is still enough freedom in the world to let one make his
own choices in some areas.

Regards
hmw