Re: Problem reading a binary file in fortran



I use digital fortran 90, and xlf95 compilers. The binary file does not
have any header or any other details, it is purely data.

I tried the following options, but none worked. I had problem with
recl=?? The numbers are integer with value between 0-255 so i tried
recl=8, recl=200*8 with access='direct' but no result.

with access='sequential' the program just hangs

open(unit=1, file='mid.bin', form='unformatted')
Error: End of file reached

open(unit=1, file='mid.bin', form='binary')
Error: End of file reached

open(unit=1, file='mid.bin', form='unformatted', access='direct')
Error: Inconsistent record length

open(unit=1, file='mid.bin', form='unformatted', access='stream')
It Could not compile
Error: Not a valid value for the char-expr in this connect-spec.
['stream']





Richard E Maine wrote:
mecej4 <mecej4@xxxxxxxxxxxxx> wrote:

Read your compiler documentation: the sections pertaining to binary
files. Fortran UNFORMATTED records are usually implemented with header
(and, sometimes, trailer) bytes containing the record size and signatures.

To read a binary stream, you should OPEN the file with FORMAT='BINARY'
rather than FORMAT='UNFORMATTED' -- not every Fortran compiler may
support this value for the FORMAT keyword.

I guess my senility is catching up with me. I'm 100% sure I just wrote
something on this in another thread only about an hour ago, but now I
can't find it. Perhaps my post somehow didn't make it out. Anyway, in
short summary...

It isn't unformatted in general that has this problem. It is specificaly
sequential unformatted.

There are 2 ways to deal with files like this.

1. Unformatted stream. This is standardized in f2003. F77/f90/f95
compilers often have variants of this same capability under various
spellings. The format='binary' that Mecej4 alludes to above is just one
of those spellings. (It is a spelling that I personally regard as
strange and confusing, but that's besides the point). If your compiler
doesn't support that, it probably does support one of the other
spellings of the equivalent functionality, possibly even including the
f2003 standardized spelling of form='unformatted',access='stream'.

2. Unformatted direct accces. This one is a bit of a hack and has a
bunch of caveats, but can often be made to work. Its spelling is far
more consistent across compilers, being mostly standardized, other than
the units for recl. The main challenge is in choosing an appropriate
record size. The file size needs to be divisible by the record size;
otherwise, there are portability issues in reading the last partial
record. For completely arbitrary file sizes that are not known before
opening the file, this can be a problem. You can read in 1 byte records
and piece it all together, but that is both a mess and possibly
inefficient. If you know the file size ahead of time, you can often
define the record size to equal the file size. Or for your 200x200x200
array, you could make the record size something like
200*array_element_size, which might be convenient and avoid awkwardly
long records, though I think most compilers will handle 8 million
elements in a record without choking.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

.



Relevant Pages

  • Re: Problem reading a binary file in fortran
    ... They are hiden from the normal Fortran programer. ... Fortran UNFORMATTED records are usually implemented with header ... of those spellings. ... more consistent across compilers, being mostly standardized, other than ...
    (comp.lang.fortran)
  • Re: Problem reading a binary file in fortran
    ... Fortran UNFORMATTED records are usually implemented with header ... To read a binary stream, you should OPEN the file with FORMAT='BINARY' ... of those spellings. ... more consistent across compilers, being mostly standardized, other than ...
    (comp.lang.fortran)
  • Re: Posix fortran and the gnu toolchain
    ... So I tried to go in and verify what Richard says, and I'm a little disappointed that I couldn't get the text + x numbers to show. ... know anything about Fortran. ... worry about the possibility of such conflicts; ... Be aware that the details can and do vary among compilers. ...
    (comp.lang.fortran)
  • Re: Is it time to legitimise REAL*8 etc?
    ... Some vendors phased out their F77 compilers over 10 ... No need to support a seperate F77 compiler as, ... experience with F77) that the F95 programming is safer than the F77 ... Authors are not chosing more recent Fortran ...
    (comp.lang.fortran)
  • Re: Is it time to legitimise REAL*8 etc?
    ... Some vendors phased out their F77 compilers over 10 ... No need to support a seperate F77 compiler as, ... experience with F77) that the F95 programming is safer than the F77 ... COMMONs remain available with any FORTRAN version. ...
    (comp.lang.fortran)