Communication between two Fortran Programs

[jz001]

Hello,

is there anyone who can explain to me the communication between two Fortran programs, for example IPC or Pipes.

Are there source code examples?

Thank in advance

jz001

[TimP]

You could begin with Wikipedia articles. These aren't specific to Fortran, beyond what you might do with OPEN.

[jz001]

@Tim18

I have two different programs. One of them is a commercial software (32bit). It is possible to extend this program by fortran user subroutines. My program could be included as a subroutine, but the problem is that my program needs more than 2 GB memory in some cases. My aim is to compile my program with 64bit and to couple both programs via IPC.

I have already looked for Wikipedia articles but most references are on C/C++ libraries. I know mixed language is possible, but I would like to keep the whole program in the same language.

Thanks in advance
jz001

[jimdempseyatthecove]

Is your commercial software a library/DLL or executable?
Is your commercial software in source or binaries.

If source you should be able to do anything you want.

If library or DLL, I assume it is 32-bit only, things are a little bit harder as you would write a control app that communicates with other processes by way of memory mapped file, pipe, or shared files or IPC. You still have a working data set problem on 2GB on the 32-bit side.

If the commercial software is executable only then you will have the highest restrictions butyou can drive the app by way of scripting and files. (assuming it is command line oriented executable).

Describe your commercial software.

Jim

[jz001]

The commercial program is a binary which allows including fortran subroutines. These subroutines are linked as a library inside the program. This program allows including all fortran commands and allows also including additional libraries.

The commercial program calculates something and sends some data (less than 1 MB) to my program. Then my program calculates in dependence of the data of the commercial program something and sends the reaction data (less than 1 MB) back to the commercial program. For the calculation of the reaction my program needs more than 2 GB in some cases.

I'm looking for source codes which allows both programms to use a shared place in memory.

Thanks
jz001

[jimdempseyatthecove]

jz,

I am not a Linux programmer, but I imagin there is similar functionality as to what is supported under Windows.

In a Windows environment you have what we would call a 32-bit library (either static as .lib or dynamic as .dll). This library has an interface in which the customer's 32-bit app passes in <1MB and receives back <1MB of data. You have a data requirement of >2GB and would like to call this library using <1MB of data at a time. And you would like to do this as efficiently as possible.

In Windows, and potentially in Linux, there is a mechanism to do this which has a funny name of WoW64. This is typically used to provide for running 32-bit applications on 64-bit operating system, but effectively is a means for writing an application that has 32-bit and 64-bit run-time contexts. Where one context is an open context for the application (i.e. 32-bit .exe or 64-bit .exe)in general and the other context is restricted within a DLL. And DLL's can call other DLL's of either bittiness. On the older Windows (16-bit vs 32-bit) this used to be called "Thunk" but now a similar functionality is called WoW (Windows on Windows).

The WoW technique is one way of accomplishing what you want to do. On Linux systems you may have similar functionality, although the Linux programmers have a distain for admitting they do anything similar to Windows that I think this type of functionality will be named with an obtuse name.

The second approach to use is to run your applicationas two processes. In Windows there is a messaging system called a pipe that can be used to pass data between two processes (applications). These applications need not be of the same bittiness nor need not be on the same system. Pipe programming is typically a throw packet in and continue, and wait for packet and resume, type of programming.

On Windows there is a variation of pipe-like programming called Remote Proceedure Call that is a throw and wait for response/return information. The RPC effectively becomes a function call in your program similar to the app toDLL to DLL calls.

A third technique is to run two applications (one 32-bit the other 64-bit) in which each has a portion of its virtual memory mapped to the others address space (these need not be at the same virtual address in their respective address spaces). In this setup, and for your program, you might have a 4MB buffer in each application that maps to a 4MB buffer in the other application. You sill have a communication issue. The bulk of the data is transported independent of the messaging system. And the messaging system is simplified such as an inter-processevent mechanism.

Jim Dempsey

[mriedman]

On UNIX/Linux the simplest way of doing IPC is by using named pipes that can be treated justlike a file.
1.: You create a pseudo file with the mkfifo command
2.: The sender process opens the pipe for writing
3.: The receiver opens the same pipe for reading
If you need togo both directions you can just use a second named pipe for that. This approach is so simple, you can even use itin scripts. It may not be a high performance approach though.

Anything else will require hardcore C-programming. Have a look at shm_open(). Sorry I have no code snippets to paste here.

Michael