Compatibility issue regarding the file I/O

[zhoutianyin]

Hello. I got a very strange I/O problem. I had two version of programs compiled from the same source code by PGI and Intel Fortran compiler respectively. The PGI version works well. The Intel version failed immediately and returned the error message: "input statement requires too much data".

I checked the source code and find the related codes:

"open(18,file=phiinam(:phiilen),status='old',
1err=900,form='unformatted')
read(18)toblbl
read(18)label,title
"

Since the PGI version program can read it, I assume the input file is fine.


My knowledge in Fortran is very limited. Does anyone have idea what's going wrong here? I have seen this error mesage several times while trying to complie g77 source codes by ifort.

Thanks a lot!

[Dave_Allured]

The exact file structure for sequential unformatted is not part of fortran standards. It can change with compiler, version, and computer hardware.

I just wrote a note about debugging this in another forum. This may be of some help:

comp.lang.fortran, Jan. 27 thread, message #14.

--Dave

[Hirchert__Kurt_W]

In one sense, what's wrong here is your expectation that this should work. The layout of unformatted files is affected by both the hardware and the software that created it. Historically, any mismatch in hardware or software between the writing and reading systems was likely to cause failure. More recently, the widespread use of IEEE floating-point arithmetic, 2's complement integer arithmetic, and ASCII characters, combined with many vendors copying the conventions of the original Unix f77 compiler, has reduced the likelihood of incompatibility. However, there are still issues of endianness, how to handle records longer than 2GB, and whether to write 32-bit or 64-bit record lengths on 64-bit machines. I assume at least one of these conventions is different between the machine that created your file and ifort.

Since you didn't tell us how the file was created, I can't be more specific about the nature of the mismatch. There is probably some way for you to work around the mismatch, whatever it is. For example, you might be able to read the file as an access='stream' file by adding explicit reads of the internal record lengths.

-Kurt

[zhoutianyin]

Thank Dave and Kurt.

I guess that the problem might be attributed to the difficulties in reading an unformatted file in 64-bit machine. Any further suggestion?


--Tianyin

[Dave_Allured]

"Any further suggestion?"

Yes! The article that I reference above describes the format in detail, then goes on to a debugging strategy that you can use. It was written for the same situation where there is an incompatibility in sequential unformatted between Intel and another compiler. You will need to do some of your own debugging. Please read carefully and try my suggestions. In short:

* Examine the file with a binary viewing tool. Learn and understand the low level binary file format; it is not complicated.
* Write a test file on the opposite machine and understand its format too.
* Determine what the differences are.
* Learn about compiler and program options related to sequential unformatted.
* Change either the writing program or the reading program to use format control options that are compatible with the other.

Please do feel free to ask again if you can show more relevant debugging information, in particular the first few dozen bytes of the binary file. I like hex dumps via "od -Ad -t x1 -N100 filename", but use any binary viewer available.

--Dave