Compiler Specific Binary Files

[faizhoda]

One problem we've faced is writing a program using one compiler to read binary files created with a program compiled on another compiler. Specifically:

A reservoir simulator program compiled using Compaq Visual Fortran creates a binary file. We are developing a post processor that needs to read that file (whose format is known). Compiling our program on CVF works fine while copiling the same program on Salford FTN95 is a problem.

Any (Standard Fotran) solution to this problem? Thanks.

[Steven_L_Intel1]

I'm unclear as to what the problem is. I think that unformatted files written by CVF are compatible with Salford FTN95, but I am not all that familiar with it.

What is the issue with your program?

Steve

[Jugoslav_Dujic]

Maybe usage of CVF non-standard FORM="BINARY"? One alternate spelling I know of in other compilers is ACCESS="TRANSPARENT", but I don't recall in which one.

Jugoslav

[faizhoda]

The issue is that the binary file reading program, when compiled using Salford FTN95, genrates an error when reading the file. The same program works fine when compiled using CVF.

Also if I generate the binary file using Salford FTN95, I get the reverse problem. The program compiled on Salford FTN95 work as expected, but when compiled on CVF generates an error.

Command I use to open the file is (aa, bb etc. are variables):
open(unit=aa,file=bb,status='OLD',action='READ', form=UNFORMATTED,iostat=cc)

[cathyprasad]

I use CVF's compatibility option "Big Endian". We never had any problems reading binary files (sequential or direct access)created from UNIX (HP-UX) or vice-versa. I hope this may give some clue.

My question to Steve Lionel is whether this compatibility option will be supported by Intel Fortran.

[james1]

Different compilers use different record delimiters, so if you are doing cross compilation you will probably need to have slightly different open statements per compiler. For example with the OPEN statement you provided you are going to get length/control information embedded in each record you write with CVF. The other compiler won't understand this so won't read the file. Likewise, the other compiler probably uses a different method of delimiting records, maybe a cr/lf, I don't use that compiler so cannot say. So either you can find out what the Salford compiler does and see if CVF has an equivalent RECORDTYPE setting, or use no delimiters (probably as Jugoslav mentioned and for CVF something like RECORDTYPE='STREAM') which will make them compatible (with different OPEN statements) or go to formatted files.

James

[Steven_L_Intel1]

CVF uses, by default (unless you use the /fpscomp:ioformat option) a layout for UNFORMATTED files that is widely supported by other Windows and UNIX/Linux compilers. But some compilers (LF90 is one, but not LF95) have their own unique format.

Steve

[Intel_C_Intel]

The Compaq format for a sequential unformatted record
is:

4 byte record length|data|4 byte record length

Someone dumped some FTN77 manuals in my office.
Polyhedron says FTN95 record format is compatible, so
I'll assume it hasn't changed. Here is the Salford
record format:

For the 1st record, or any subsequent record of more
that 240 bytes in length:

FF|4 byte record size|data|4 byte record size|FF

For other records:

1 byte record size|record data|1 byte record size

With appropriate (but,alas, different) options on the
open statement you can get either compiler to create
files that don't have any record length information
at all, which would probably make it easier to
share files between them.

[faizhoda]

Currently we have taken the "formatted files" route. But I was investigating how to avoid this. Thanks for all the input to this problem.

If we do not have control on the creator of the files (which compiler they use or which specifiers/options they used with the OPEN statement), is there any (FTN standard) way of querying the binary file itself for sufficient information to alter the reading program's OPEN statement such that the data is read correctly.

Since we have control on the reading program's OPEN statement, we could use the correct options for the compiler we are using.

Am I hoping too much here? :-(

Faiz

[Steven_L_Intel1]

There is no way within the Fortran standard to do this. A technique that works on many platforms is to open the file for unformatted direct access, with a RECL long enough to "sniff" the first n bytes (4 probably will do) using a direct-access read of the first "record", and then try to figure out what you have.

CVF unformatted files consist of a four-byte length, the data, and another four-byte length. The length is a little-endian integer. Most implementations that have their own format have some sort of "magic number" in the first few bytes, and you can look to see what is there.

Keep in mind that CVF, by default, uses 4-byte units for the RECL of UNFORMATTED files.

Steve