Skip to Content.
Sympa Menu

forum - Re: [abinit-forum] Re: header format of binary files: documentation out-of-date?

forum@abinit.org

Subject: The ABINIT Users Mailing List ( CLOSED )

List archive

Re: [abinit-forum] Re: header format of binary files: documentation out-of-date?


Chronological Thread 
  • From: matthieu verstraete <matthieu.jean.verstraete@gmail.com>
  • To: forum@abinit.org
  • Subject: Re: [abinit-forum] Re: header format of binary files: documentation out-of-date?
  • Date: Mon, 1 Jun 2009 10:59:25 +0200
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=n7zrdKLYl4HQAuOlBMxJPbpZYXz4qE8TmnYGtwAauIUxL6Zw/03aGZHljcS9gOveYy /8jgRezXIA0w/wg3+l30p1HhyRbq+cW+T39+xgygdVxzBT1knVDbqYP7HN4M+DVJjHls uMivHlra1wwts5LWpR0uqoyfSlatVokV77/cA=

Hello everyone,

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.


> I don't agree with this. I have analysed binary files before, either
> from Fortran or from C. Moreover, the documentation explains
> the header structure in terms of the Fortran write statement !
> For example:
>
> write(unit=header) codvsn,headform,fform
> write(unit=header) bantot,date,intxc,ixc,natom,ngfft(1:3),&
> & nkpt,nspden,nspinor,nsppol,nsym,npsp,ntypat,occopt,pertcase,usepaw,&
> &
> ecut,ecutdg,ecutsm,ecut_eff,qptn(1:3),rprimd(1:3,1:3),stmbias,tphysel,tsmear

In the source code:

...
read (unitfi) codvsn,headform,fform
...
read(unitfi) bantot, hdr%date, hdr%intxc, hdr%ixc, natom, hdr%ngfft(1:3),&
& nkpt, hdr%nspden, hdr%nspinor, nsppol, nsym, npsp, ntypat,
hdr%occopt, hdr%pertcase,&
& hdr%usepaw, hdr%ecut, hdr%ecutdg, hdr%ecutsm, hdr%ecut_eff,
hdr%qptn(1:3), hdr%rprimd,&
& hdr%stmbias, hdr%tphysel, hdr%tsmear, hdr%usewvl


see src/59_io_mpi/hdr_io.F90:
http://www.abinit.org/downloads/browse-lastest-sources?currenturl=aHR0cDovL3d3d29sZC5hYmluaXQub3JnL3BhY2thZ2Uvcm9ib2RvY181LjguMi81OV9pb19tcGkvXzU5X2lvX21waV8uaHRtbA==&linkurl=Li9oZHJfaW9fRjkwLmh0bWwjcm9ibzQ3OQ==&attrtype=href

You are correct that the documentation is out of date, but only by
missing the usewvl variable on the end, but that's all. I have updated
the documentation in our current development version.

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 (can you check your output
to see if bantot is 1 or 228? For the density, probably 1...).

Try making a test binary file with your f90 compiler, looking at the
beginning and end of each record (or check for the end of the 2nd
record of you DEN file.


> I assume an integer is the usual 4 bytes.
this can also be platform dependent, of course, and abinit uses
default ints, which can vary.

> 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! Your code will never be portable, I promise.
You could also wrap the fortran reading, importing the hdr_io bits you
need, or even add your functionnality into cut3d :)

> I can't find:
>  headform, fform, bantot, pertcase, ecutdg, ecut_eff
Indeed these are not input variables, they are internal ones. Some
description is given in the source file cited above.

Matthieu


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Matthieu Verstraete

European Theoretical Spectroscopy Facility (ETSF)
Dpto. Fisica de Materiales,
U. del Pais Vasco,
Centro Joxe Mari Korta, Av. de Tolosa, 72, Phone: +34-943018393
E-20018 Donostia-San Sebastian, Spain Fax  : +34-943018390

Mail : matthieu.jean.verstraete@gmail.com
http://www-users.york.ac.uk/~mjv500




Archive powered by MHonArc 2.6.15.

Top of Page