VMD-L Mailing List

From: root (root_at_liposome.genebee.msu.su)
Date: Mon Dec 08 1997 - 03:41:44 CST

On Sun, 7 Dec 1997, Andrew Dalke wrote:

> > [...]
> It took me a while to remember what causes the problem -- you are
> running on an Intel box, which is opposite endian to what the NAMD DCD
> writer (run on an HP) produces.

Thanks for confirming my suspicions. I realized this only yesterday, after
I have been also unable to load that accursed alanin.dcd into gOpenMol.
Then that line about '..preserves accuracy much better, but is not
guaranteed to be transportable between computer architectures' came to my
mind. (This is about restart file format, not trajectory, of course).

> There is no easy solution to this problem. The DCD format is
> architecture (and perhaps even compiler) dependent. DCD files

This sounds unfortunate. I thought the matter can be resolved by a byte or
longword halves swapping filter? I have to admit that the 'exact format of
these files is very ugly' bit is not exactly confidence-inspiring.

Andrew, if this is not too much trouble: could you perhaps outline how
complex a parser for isolating the machine-dependant fields from the dcd
can be? An external trajectory conversion utility for those
Intel-handicapped would appear to be much cleaner than incorporating that
code into NAMD or VMD.

> produced by NAMD on an Intel machine should be readable by VMD for
> that OS, but not on machines with different binary representation.
> We've not tested to see if XPLOR or CHARMM for Linux produces
> trajectory files that VMD can read.
>
> We should add this to our FAQ and probably put some sort of error
> message in the DCD reader saying it couldn't read the DCD file
> correctly.

This should be very useful for those unfortunates who have to stick to the
braindead Intel architecture. Unremarkably, gOpenMol has also kept quiet
about broken trajectory format.

Regards,
Eugene

>
> Andrew
> dalke_at_mag.com
> ---
> Not speaking for the Molecular Applications Group.
>