From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Tue Apr 03 2007 - 09:20:25 CDT

On Tue, 3 Apr 2007, namd vmd wrote:

NV> Hi,

dear namd vmd,

NV>
NV> I am trying to analyze my NAMD trajectory in charmm. However, charmm gives
NV> me an error, and the charmm lists tell me the following:

one question remains:
why do you post this to the vmd list instead of the namd list?

NV> ================================
NV> For portability between 32-bit and 64-bit machines CHARMM trajectories
NV> should read/write integers
NV> in 32-bits, which on 64-bit machines requires I4BINARY in pref.dat
NV>
NV> With GFORTRAN there is also possibly an issue with fortran recordlength
NV> fields in the binary file
NV> not being 32-bit. For this GFORTRAN needs the following flag
NV> -frecord-marker=4
NV>
NV> If NAMD produces something that does not meet these criteria, or if the file
NV> contents differ from a
NV> CHARMM trajectory, there will be problems.
NV> ==================================

NV> My questions are"
NV> 1. Does NAMD indeed meet the criteria above?

NAMD always writes 32-bit record markers. the problem mentioned
above affects gfortran. so if it does not work for you and you
use gfortran to compile CHARMM then this is a CHARMM problem
(or more specifically _your_ problem).

NV> 2. If not, is there a way to force this?

see above. you have to compile the CHARMM tools the right way
not NAMD (or VMD). both do _not_ contain fortran code.

NV> 3. How can one know if a given trajectory is in 32-bit binary or 64-bit
NV> binary ?

you can look at the at the hexdump of the trajectory file.
some more details are in the source code for the dcdplugin
for VMD. VMD tries _very_ hard to read any variation of DCD
regardless of endianness and 32/64-bit record markers.

NV> 4. can a 64-bit machine write a 32-bit binary?

yes. even though the exact format of fortran binary i/o is
not defined by any standard (only the behavior, which more
or less dictates the implementation and most compiler implementers
converged to the same conventions). the gfortran way is rather
unusual and the default behavior has actually been reverted
to the common conventions in recent development snapshots.

NV> Sorry for the long title of the email, but it might make future searches
NV> easier. Thank you !

i'm not sure about that. it would be much more appropriate
if you'd try to use VMD for your analysis. ;-)

axel.

-- 
=======================================================================
Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.