Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73017

Re: Interfacing Fortran applications

Show all headers | View raw

On Mon, Jun 9, 2014 at 5:43 PM, Michael Welle <mwe012008@gmx.net> wrote:
> 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.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Interfacing Fortran applications Michael Welle <mwe012008@gmx.net> - 2014-06-09 09:43 +0200
  Re: Interfacing Fortran applications Chris Angelico <rosuav@gmail.com> - 2014-06-09 19:36 +1000
    Re: Interfacing Fortran applications Michael Welle <mwe012008@gmx.net> - 2014-06-09 12:30 +0200
  Re: Interfacing Fortran applications Sturla Molden <sturla.molden@gmail.com> - 2014-06-09 11:48 +0000
    Re: Interfacing Fortran applications Michael Welle <mwe012008@gmx.net> - 2014-06-09 14:24 +0200
      Re: Interfacing Fortran applications Chris Angelico <rosuav@gmail.com> - 2014-06-10 00:50 +1000
        Re: Interfacing Fortran applications Michael Welle <mwe012008@gmx.net> - 2014-06-09 17:14 +0200
      Re: Interfacing Fortran applications Sturla Molden <sturla.molden@gmail.com> - 2014-06-09 22:57 +0200
        Re: Interfacing Fortran applications Michael Welle <mwe012008@gmx.net> - 2014-06-10 10:55 +0200
      Re: Interfacing Fortran applications alister <alister.nospam.ware@ntlworld.com> - 2014-06-10 10:36 +0000

csiph-web