Python and fortran Interface suggestion

[Dave Angel]

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