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

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

Python and fortran Interface suggestion

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

Contents

  Python and fortran Interface suggestion pauld11718 <pauld11718@gmail.com> - 2015-04-19 07:48 -0700
    Re: Python and fortran Interface suggestion Chris Angelico <rosuav@gmail.com> - 2015-04-20 01:23 +1000
      Re: Python and fortran Interface suggestion pauld11718 <pauld11718@gmail.com> - 2015-04-19 08:56 -0700
        Re: Python and fortran Interface suggestion Dave Angel <davea@davea.name> - 2015-04-19 16:26 -0400
          Re: Python and fortran Interface suggestion edmondo.giovannozzi@gmail.com - 2015-04-22 02:31 -0700

#89155 — Python and fortran Interface suggestion

I am developing a code under Ubuntu(64bit) with python using various libraries. Once done, I need to generate an executable which shall be interfaced with fortran program on account of further collaboration. The python executable shall be used with windows(32bit).

So, I guess everytime my python executable is called by the fortran code on each time step, all those
from **** import *'s
will be executed and are time consuming (which is not at all required). Moreover, creating executable for windows, using linux is that possible by any means?

What is a better methodology for addresing such interfacing?

[toc] | [next] | [standalone]

#89159

On Mon, Apr 20, 2015 at 12:48 AM, pauld11718 <pauld11718@gmail.com> wrote:
> I am developing a code under Ubuntu(64bit) with python using various libraries. Once done, I need to generate an executable which shall be interfaced with fortran program on account of further collaboration. The python executable shall be used with windows(32bit).
>
> So, I guess everytime my python executable is called by the fortran code on each time step, all those
> from **** import *'s
> will be executed and are time consuming (which is not at all required). Moreover, creating executable for windows, using linux is that possible by any means?
>
> What is a better methodology for addresing such interfacing?

Hmm. Let's divide that into several parts.

1) You need to have a Python program that interfaces with Fortran.

Does it need to call functions from a Fortran library, or is it simply
invoked by the Fortran program and that's it? If the latter, it's not
hard. But if you're concerned about startup time, you may want to
consider having your Python program keep running indefinitely, and
have some alternative means of communicating between them. For
instance, Python might create a socket or pipe, which the Fortran
program opens and writes to, and then reads a response. (If you can't
edit the Fortran code at all, it's pretty easy to write a slim stub
executable that does the socket/pipe handling.) Or alternatively,
install Python onto a RAM disk, to improve startup time that way.

2) You need to run the whole kit and caboodle on Windows. The best way
to do this is simply to write clean Python code, and then install a
Windows Python, and everything will work just fine. However, Windows
does tend to have far worse disk cache management than Linux has,
which will exacerbate your startup delays.

3) Above all, you need to know exactly how long things are taking.
Before you start trying to speed things up, first figure out where
it's actually slow. You never know, it might already be fast enough!

Check out some details, see how things go. On the face of it, I'd
guess that what you want to do will be quite doable.

ChrisA

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

#89160

I shall provide with further details....

Its about Mathematical modelling of a system. Fortran does one part and python does the other part (which I am suppose to provide).
For a time interval tn --> t_n+1, fortran code generates some values, for which my python code accepts it as an input. It integrates some data for the same time step tn --> tn+1 and fortran computes based on this for the next time step t_n+1 --> t_n+2......and this is how loop continues.

Its the fortran code calling my Python executable at all the time interval.

So,
1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows? 

2. As interfacing between fortran/python is via .dat file, so on every time-step python executable is called it shall open()/close() .dat file. This along with all those 
from **** import *'s
are unnecessary.

3. I dont have access to fortran code. I shall provide the python executable only, which will take input from .dat file and write to another .dat file. So, what is your suggestion regarding socket/pipe and python installation on RAM? I have no idea with those.

Isn't there a better way to handle such issues?

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

#89171

On 04/19/2015 11:56 AM, pauld11718 wrote:
> I shall provide with further details....
>
> Its about Mathematical modelling of a system. Fortran does one part and python does the other part (which I am suppose to provide).
> For a time interval tn --> t_n+1, fortran code generates some values, for which my python code accepts it as an input. It integrates some data for the same time step tn --> tn+1 and fortran computes based on this for the next time step t_n+1 --> t_n+2......and this is how loop continues.
>
> Its the fortran code calling my Python executable at all the time interval.

Then you'd better find out how it's calling your executable.  Calling it 
is very different than starting it.  The whole import x, y,z is done 
only upon initial startup of the python code.  You can then call the 
Python code as many times as you like without incurring that overhead again.

Naturally, if the guy who designed the Fortran code didn't think the 
same way, and is unavailable for further tweaking, you've got a problem.

>
> So,
> 1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows?

Don't worry about how you get installed until after you figure out how 
you're going to get those calls and data back and forth between the 
Fortran code and your own.

>
> 2. As interfacing between fortran/python is via .dat file, so on every time-step python executable is called it shall open()/close() .dat file. This along with all those
> from **** import *'s
> are unnecessary.

Have you got specs on the whole dat file thing?  How will you know it's 
time to examine the file again?  As long as you get notified through 
some other mechanism, there's no problem in both programs having an open 
handle on the shared file.

For that matter, the notification can be implicit in the file as well.

But is there a designer behind this, or is the program intending to deal 
with something else and you're just trying to sneak in the back door?


>
> 3. I dont have access to fortran code. I shall provide the python executable only, which will take input from .dat file and write to another .dat file. So, what is your suggestion regarding socket/pipe and python installation on RAM? I have no idea with those.
>

Not much point in opening a pipe if the other end isn't going to be 
opened by the Fortran code.

> Isn't there a better way to handle such issues?
>

Sure, there are lots of ways.  But if the Fortran code is a closed book, 
you'll have to find out how it was designed, and do all the adapting at 
your end.

If it becomes open again, then you have the choice between having one of 
your languages call functions in the other (ie. single process), having 
some mechanism (like queues, or sockets) between two separately started 
processes, and having one program launch the other repeatedly.  That 
last is probably the least performant choice.

If you google "python Fortran" you'll get lots of hits.  You could start 
reading to see what your choices are.  But if the Fortran designer has 
left the room, you'll be stuck with whatever he put together.

And chances are very high that you'll need to develop, and certainly 
test, some parts of the project on the Windows machine, and particularly 
with the Windows C/Fortran compilers.


-- 
DaveA

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

#89289

Il giorno domenica 19 aprile 2015 22:26:58 UTC+2, Dave Angel ha scritto:
> On 04/19/2015 11:56 AM, pauld11718 wrote:
> > I shall provide with further details....
> >
> > Its about Mathematical modelling of a system. Fortran does one part and python does the other part (which I am suppose to provide).
> > For a time interval tn --> t_n+1, fortran code generates some values, for which my python code accepts it as an input. It integrates some data for the same time step tn --> tn+1 and fortran computes based on this for the next time step t_n+1 --> t_n+2......and this is how loop continues.
> >
> > Its the fortran code calling my Python executable at all the time interval.
> 
> Then you'd better find out how it's calling your executable.  Calling it 
> is very different than starting it.  The whole import x, y,z is done 
> only upon initial startup of the python code.  You can then call the 
> Python code as many times as you like without incurring that overhead again.
> 
> Naturally, if the guy who designed the Fortran code didn't think the 
> same way, and is unavailable for further tweaking, you've got a problem.
> 
> >
> > So,
> > 1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows?
> 
> Don't worry about how you get installed until after you figure out how 
> you're going to get those calls and data back and forth between the 
> Fortran code and your own.
> 
> >
> > 2. As interfacing between fortran/python is via .dat file, so on every time-step python executable is called it shall open()/close() .dat file. This along with all those
> > from **** import *'s
> > are unnecessary.
> 
> Have you got specs on the whole dat file thing?  How will you know it's 
> time to examine the file again?  As long as you get notified through 
> some other mechanism, there's no problem in both programs having an open 
> handle on the shared file.
> 
> For that matter, the notification can be implicit in the file as well.
> 
> But is there a designer behind this, or is the program intending to deal 
> with something else and you're just trying to sneak in the back door?
> 
> 
> >
> > 3. I dont have access to fortran code. I shall provide the python executable only, which will take input from .dat file and write to another .dat file. So, what is your suggestion regarding socket/pipe and python installation on RAM? I have no idea with those.
> >
> 
> Not much point in opening a pipe if the other end isn't going to be 
> opened by the Fortran code.
> 
> > Isn't there a better way to handle such issues?
> >
> 
> Sure, there are lots of ways.  But if the Fortran code is a closed book, 
> you'll have to find out how it was designed, and do all the adapting at 
> your end.
> 
> If it becomes open again, then you have the choice between having one of 
> your languages call functions in the other (ie. single process), having 
> some mechanism (like queues, or sockets) between two separately started 
> processes, and having one program launch the other repeatedly.  That 
> last is probably the least performant choice.
> 
> If you google "python Fortran" you'll get lots of hits.  You could start 
> reading to see what your choices are.  But if the Fortran designer has 
> left the room, you'll be stuck with whatever he put together.
> 
> And chances are very high that you'll need to develop, and certainly 
> test, some parts of the project on the Windows machine, and particularly 
> with the Windows C/Fortran compilers.
> 
> 
> -- 
> DaveA

Generally I have used f2py to link Fortran subroutines to Python, then python will call this Fortran subroutines. Who is calculating what is not really important, except that Python is the driver. You can of course also call a python function from Fortran (well look at the documentation of f2py).


When you are saying that you don't have access to the Fortran program what that does mean?
Somebody else is developing it or it is an already written full Fortran program?
If the latter I will always use Python as a driver that prepare files for the Fortran program then read back the data make some elaboration and prepare the data for the following step.

But if somebody else is writing the Fortran part or have access to the source tell him to give you some some subroutines that you will call from Python.
  
 

[toc] | [prev] | [standalone]

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

csiph-web