Re: Double Posts ... (Reading Binary data re-up)

(Ah. This is the posting I just alluded to elsewhere as not being able to
find. Finally found that I had accidentally emailed instead of posted my
reply. Sorry about that; it wasn't my intention. Still experimenting with
this newsreader client. Anyway, I've just copied it here and reposted, this
time to the newsgroup).

On Wed, 17 Jan 2007 07:24:19 -0800, David Koch wrote
(in article <eolf35$k2q$1@xxxxxxxxxxxxxxxxxx>):

Here is how the file is generated in Matlab:

file_id = fopen('test.bin', 'wb');
fwrite(file_id, magic(5))

Fortran program:
open(17, file='test.bin', status='old', form='unformatted')
How can I get this to work? I need binary format, writing text from
Matlab takes ages.

Ah. The bit about how you created the file is important information that you
didn't mention before (or that I don't recall seeing, anyway).

This is not a normal Fortran sequential unformatted file. You won't be able
to read it that way. Fortran sequential unformatted files have embedded
record length information. These files can be compiler dependent, although
most Fortran compilers use similar schemes. Thus they aren't usually a good
choice for compatibility with other compilers - particularly non-Fortran
ones. This file won't have the expected embedded information.

It is probably too much fuss to make Matlab write in the exact form that this
read expects (possible, but a bother, and I'd have to do a little research to
get it right). I'm more familiar with the Fortran end. You should be able to
read this file in either of 2 ways.

1. As an unformatted stream (instead of sequential) file. That's conceptually
simplest, but not standardized until f2003. Stream files were designed for
interoperability (although they also have other uses). Most existing
compilers have similar facilities as extensions to f77/f90/f95, although the
exact spelling varies. I forget which, if any, spelling g77 supports. (I
generally recommend moving to a newer compiler, such as g95; my recollection
of g77-specific details is gradually getting dimmer as I now consider it a
legacy compiler).

2. As a direct access (instead of sequential) unformatted file. Although the
standard doesn't require it, almost all implementations (including g77 - that
I do recall about it) do direct access unformatted in a way compatible with
files like this. This approach is a slight hack, but it works. To do that,
you need 2 things.

a) Change the OPEN to add access='direct' and recl=appropriate_value. The
recl is for record length. Basically, the file is divided into records of
that length. It is probably simplest to just consider the whole file to be a
single record, in which case, the appropriate value is the size of the whole
file. The units of size are usually bytes; different compilers can use
different units, but bytes is the most common, and that's what g77 uses. So
for default integer elements (which is what you have), that would be 4 times
the number of elements. If it turns out that the file is long enough that the
record size becomes a problem (not sure when or if you would hit that), you
could arbitrarily divide it into smaller records - perhaps one record per
array column would be convenient.

b) Add rec=record_number to the read statement. If the file is just one
record, that will be rec=1. If you divide the file into multiple records,
you'll need to increment the record number for each read.

And by the way, no unformatted does not have anything in particular to do
with array shape issues. Unformatted just means that the data is in internal
form (aka binary) instead of being converted into text. The conversion to
text is called formatting.

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