Re: AMBER: Binary file curiosities

From: David LeBard <>
Date: Sat, 4 Aug 2007 14:34:23 -0700

Professors Case and Cheatham,

Thank you very much for the helpful responses. Although I realize the
binpos format is generally non-transferable, I really like the file type for
its slender size and simplicity.

Although I will work on the NetCDF format next since it appears to be the
future for scientific data, I wanted to report that I was able to read the
binpos file in fortran. In case other AMBER users want do this this with
fortan as well, I am including a rather pointless pseudo code that should
work for reading the binpos format using a fortran compiler that supports
the "binary" form option.


====== Start Binpos Fortran Pseudocode ========
program dummy
  implicit none

  integer :: iBin, i, j, nAtom
  character :: magicNum(4)
  real, pointer, dimension(:) :: xx,yy,zz

  print *, " Enter the number of configurations: "
  read (*,*) numConfigs

  read(iBin) magicNum ! Read the 4 char magic string

  do i = 1, numConfigs ! Loop over all configs
   read(iBin) nAtom ! Read the number of atoms every time

   if (i .eq. 1) then ! Allocate coordinate storage,
    allocate(xx(nAtom)) ! and assume its the same every time

   read(iBin) (xx(j),yy(j),zz(j),j=1,nAtom) ! Read in all coordinates



end program dummy
====== End Binpos Fortran Pseudocode ========

On 8/3/07, Thomas Cheatham III <> wrote:
> > I have been playing with reading the various binary AMBER trajectory
> data
> > types lately, and I noticed a few things that strike me as puzzling
> > "features" of AMBER. For instance, from what I can tell from mdwrit.f,
> if
> > you choose the option NTRX=1 in sander you get an unformatted file that
> > looks exactly like the formatted mdcrd file. However, I do not see the
> NTRX is for specifying the format of the "refc" coordinates that are read
> in so will not alter output. For output, you would play with NTXO.
> The binary formats in AMBER are old; they are not transferable among
> different hardware (for example SGI vs. Linux) meaning that in general you
> need to re-read them on the platform that produced them to be safe using
> the same compiler.
> It would not be too hard to adapt ptraj to read some of these (although I
> haven't seen the need except perhaps to provide greater precision plus
> there is the added difficulty that these are fortran implementation
> dependent). Instead we went the NetCDF route...
> > option to write these types of files from ptraj, only binpos binary
> files
> > are available (from my inspection of trajectory.c). Also, possibly due
> to
> > my lack of c expertise, I do not see the option to read binary mdcrd
> files
> > within ptraj itself. So my questions are the following: 1) Why such
> > inconsistencies with the binary file types across the various sander
> > modules? I understand that you must try to be as backward compatible as
> > possible, but consistency between file reads and writes would make
> things
> > much easier for the users (including myself). 2) Is the magic number in
> the
> The older binary format is not "transferable" and Fortran-implementation
> specific. To my knowledge, very few people use it (except perhaps with
> NMODE restrt files).
> > binpos file type only used only to determine the difference between
> binpos
> > and CHARMM trajectories? 3) Has anyone worked with reading binpos files
> in
> > fortran, particularly using direct access reads? If so, can you please
> DAC may have more to say on this regarding the binpos format, but the
> ptraj parser for file types if fairly simple in that it looks at the top
> of the files and makes some assumptions based on what is seen.
> > provide any examples? 4) Is there any documentation anywhere on the
> binpos
> > file type? I have been looking all over, and only believe I know what
> is in
> > the file because of the "od" command and code/comments inside ptraj.
> > Please, if I am missing an obvious reference to the binpos file
> structure,
> > do not hesitate to send it my way.
> If I were to play with binary formats, I would opt for the NetCDF format
> which is supported in current releases of ptraj/AMBER. The binpos is a
> simple format but may depend on endian order (and hence not be
> transferable among machines?). It will be the most compact. NetCDF is
> less compact but more transferable.
> -- tom
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to
> To unsubscribe, send "unsubscribe amber" to

The AMBER Mail Reflector
To post, send mail to
To unsubscribe, send "unsubscribe amber" to
Received on Sun Aug 05 2007 - 06:08:12 PDT
Custom Search