There has been a quite a bit of discussion on this list lately about how to
efficiently use the binary trajectory files that LAMMPS produces. Is there
a proper definition (other than the source code) of the DCD file format
that all simulation and visualization programs adhere to? In particular,
are there issues with endianness and word lengths across different
architectures?
Lutz
There has been a quite a bit of discussion on this list lately about how to
efficiently use the binary trajectory files that LAMMPS produces. Is there
a proper definition (other than the source code) of the DCD file format
that all simulation and visualization programs adhere to? In particular,
are there issues with endianness and word lengths across different
architectures?
lutz,
there is a number of different variations of the .dcd format and
it being a fortran unformatted output format, there are endian
_and_ platform issues as well. john stone and i had recently a
lot of negative fun to make the vmd molfile plugin compatible to
g95/gfortran compiled versions of CHARMM and X-plor as they used
64-bit record length markers by default (even on 32-bit machines).
to have a visualization program compatible with all variations of
big/little endian and 64-bit/32-bit record length markers and
integers is painful. however, if you stick to c generated output
in 32-bit same endiannes style you have to consider only three
substyles, x-plor, charmm (old), charmm (new, with supercell
information). most visualization programs read only a subset
of the information you can store in the header as many simulation
codes don't update it (for performance reasons).
if you also want to write velocity/forces .dcd files, you have
to change the 'magic' string 'CORD' with 'VEL ' or 'FRC ',
respectively. the .dcd support in LAMMPS is quite reasonable.
i only found one problem with using it on fedora core 6 machines,
where there is some kind of a compiler/optimizer bug that can
be worked around by replacing valid code with other valid code.
cheers,
axel.
Hi Lutz,
Here's a description:
http://www.ks.uiuc.edu/Research/vmd/plugins/molfile/dcdplugin.html
The one inconsistency with the description above is that LAMMPS writes out
coordinates in single precision (float) instead of double. However, the
resulting DCD files can be read by both VMD and CHARMM, so I'm not sure if
the documentation has an error (and from the source of the VMD reader it
can only handle single-precision trajectories). There is an issue with
endianness (LAMMPS will write a binary file in the machine's native
format) but VMD can read either endian-format file.