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
--
https://mail.python.org/mailman/listinfo/python-list
