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

Groups > comp.lang.python > #73011 > unrolled thread

Interfacing Fortran applications

Back to article view | Back to comp.lang.python

Contents

  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

#73011 — Interfacing Fortran applications

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

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html

[toc] | [next] | [standalone]

#73017

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.

[toc] | [prev] | [next] | [standalone]

#73019

Hello,

Chris Angelico <rosuav@gmail.com> writes:

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

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html

[toc] | [prev] | [next] | [standalone]

#73020

Michael Welle <mwe012008@gmx.net> wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#73023

Hello,

Sturla Molden <sturla.molden@gmail.com> writes:

> Michael Welle <mwe012008@gmx.net> wrote:
>
>> 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.
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

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html

[toc] | [prev] | [next] | [standalone]

#73033

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

[toc] | [prev] | [next] | [standalone]

#73037

Hello,

Chris Angelico <rosuav@gmail.com> writes:

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

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html

[toc] | [prev] | [next] | [standalone]

#73061

On 09/06/14 14:24, Michael Welle wrote:
 >> 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.

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

[toc] | [prev] | [next] | [standalone]

#73077

Hello,

Sturla Molden <sturla.molden@gmail.com> writes:

> On 09/06/14 14:24, Michael Welle wrote:
>>> 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.
>
> 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

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html

[toc] | [prev] | [next] | [standalone]

#73082

On Mon, 09 Jun 2014 14:24:07 +0200, Michael Welle wrote:

> Hello,
> 
> Sturla Molden <sturla.molden@gmail.com> writes:
> 
>> Michael Welle <mwe012008@gmx.net> wrote:
>>
>>> 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.
> 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

If you have no tests & the Fortran App  is business critical I am 
inclined to leave it totally alone.
i would there for look for ways of calling the Fotran application as it 
is for now (os.subprocess)





-- 
filesystem not big enough for Jumbo Kernel Patch

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web