The ABINIT Users Mailing List ( CLOSED )

[Damien Caliste <damien.caliste@cea.fr>]

Hello,

Le 01/06/2009, matthieu verstraete <matthieu.jean.verstraete@gmail.com>
a écrit :
> Joe is correct: fortran writes are ugly things that are very compiler
> dependent. The data fields will be ok, but there can be arbitrary (ie
> compiler-dependent) additional bytes at the beginning and end of each
> _record_ ie for each write()... statement.
Yes, and I would say, at the end also ! For the compilers I know
(ifort, g95 and gfortran), the scheme is like that:
flag - record - flag
* 'flag' is a 4 or 8 bytes length value with the size in bytes of the
record.
* 'record' are the raw data in Big or little endian (yeh).
Most of the flags are 4 bytes long, but gfortran introduced 8 bytes
long flags during its version 4.1 and maybe 4.2 before going back to 4
bytes long.

> > write(unit=header) codvsn,headform,fform
So in your hex dump this looks like:
0e 00 00 00 -> flag, with 14 bytes following.
35 2e 37 2e 33 20 -> codsvn
39 00 00 00 -> headform value
34 00 00 00 -> fform value
0e 00 00 00 -> closing flag of 14 bytes.
...

> The added bytes you find between fform and date come from the
> compiler. Note that the 0e 00 00 00 is repeated before each record,
> then I'm not sure where the 228 comes from
Its the flag for the second record, with 228 bytes written in the
record.

> > I want to access the binary files directly, without cut3d.
> The only safe way to read back a binary fortran file is with the same
> fortran compiler!
Yep, but if you absolutly want some C routines, you may give a look to
the source code of V_Sim. In src/coreTools/toolFortran.c you have a code
to read fortran records, and try to guess the format:
http://inac.cea.fr/L_Sim/V_Sim
See src/renderingMethods/renderingAtomic_d3.c for an example of usage.

Damien.