Re: Interfacing Fortran applications
On Mon, 09 Jun 2014 14:24:07 +0200, Michael Welle wrote: Hello, Sturla Molden sturla.mol...@gmail.com writes: Michael Welle mwe012...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Interfacing Fortran applications
On Mon, Jun 9, 2014 at 5:43 PM, Michael Welle mwe012...@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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Interfacing Fortran applications
Michael Welle mwe012...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Interfacing Fortran applications
On Mon, Jun 9, 2014 at 10:24 PM, Michael Welle mwe012...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Interfacing Fortran applications
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 -- https://mail.python.org/mailman/listinfo/python-list
