Interfacing Fortran applications

Discussion in 'Python' started by Michael Welle, Jun 9, 2014.

  1. 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,

    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?

    Michael Welle, Jun 9, 2014
    1. Advertisements

  2. 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

    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.
    Chris Angelico, Jun 9, 2014
    1. Advertisements

  3. Hello,

    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

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

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

    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.

    Michael Welle, Jun 9, 2014
  4. If you are to rewrite the Fortran app you can just as well use f2py from

    Sturla Molden, Jun 9, 2014
  5. Hello,

    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.

    Michael Welle, Jun 9, 2014
  6. 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.)

    Chris Angelico, Jun 9, 2014
  7. Hello,

    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 ;).

    Michael Welle, Jun 9, 2014
  8. 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 Molden, Jun 9, 2014
  9. Hello,

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

    Michael Welle, Jun 10, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.