gmx analysis tools require big-endian TRR trajectories - Redmine #1926
Archive from user: Daniel Roe
Hi,
Recently on the Amber mailing list a user (Robert Molt) reported that do_x3dna would crash when he tried to run it with a TRR trajectory generated by cpptraj from AmberTools. However, VMD was able to read and display the cpptraj-generated trajectory with no issues. I was able to reproduce this behavior with ‘gmx rms’ and found that when I forced cpptraj to write the TRR trajectory as big-endian, ‘gmx rms’ was able to run successfully. Is this intentional behavior? Should I be forcing cpptraj to write TRR trajectories as big endian by default? Thanks.
-Dan
GROMACS version: VERSION 5.1.2
Precision: single
Memory model: 32 bit
MPI library: thread_mpi
OpenMP support: enabled (GMX_OPENMP_MAX_THREADS = 32)
GPU support: disabled
OpenCL support: disabled
invsqrt routine: gmx_software_invsqrt(x)
SIMD instructions: SSE2
FFT library: fftw-3.3.4-sse2
RDTSCP usage: disabled
C++11 compilation: enabled
TNG support: enabled
Tracing support: disabled
Built on: Thu Mar 17 07:30:12 MDT 2016
Built by: droe@choxnuxe [CMAKE]
Build OS/arch: Linux 3.13.0-83-generic i686
Build CPU vendor: GenuineIntel
Build CPU brand: Intel® Atom™ CPU N280 @ 1.66GHz
Build CPU family: 6 Model: 28 Stepping: 2
Build CPU features: apic clfsh cmov cx8 htt lahf_lm mmx msr pdcm pse
sse2 sse3 ssse3
C compiler: /usr/bin/cc GNU 4.8.4
C compiler flags: -msse2 -Wundef -Wextra -Wno-missing-field-initializers
-Wno-sign-compare -Wpointer-arith -Wall -Wno-unused -Wunused-value
-Wunused-parameter -O3 -DNDEBUG -funroll-all-loops
-fexcess-precision=fast -Wno-array-bounds
C compiler: /usr/bin/c GNU 4.8.4
C compiler flags: -msse2 -std=c++0x
-Wundef -Wextra -Wno-missing-field-initializers -Wpointer-arith -Wall
-Wno-unused-function -O3 -DNDEBUG -funroll-all-loops
-fexcess-precision=fast -Wno-array-bounds
Boost version: 1.55.0 (internal)
(from redmine: issue id 1926, created on 2016-03-18 by gmxdefault, closed on 2016-07-28)
- Changesets:
- Revision f7d4d019 by Mark Abraham on 2016-07-12T14:09:13Z:
Fix trr magic number reading
The trr header-reading routine returned an "OK" value if the magic
number was wrong, which might lead to chaotic results everywhere,
because checking of return values tends not to happen (even when
they're right). Other GROMACS magic-number reading routines tend to
give a fatal error if the the number is wrong, e.g. by reading a file
written in wrong endianness. (This should never be a thing for XDR
files, which are defined to be big endian, but such code has existed.)
This change adds/restores that behaviour to trr reading, along
with separating the behaviour of failing to read a magic integer
from reading one that doesn't match.
Fixes #1926
Change-Id: I3cdd8ae9172e3b95fc232d8fa31a442d239233db- Revision d465ad8b by Mark Abraham on 2016-12-09T21:26:18Z:
Fix logic of TRR reading
Commit f7d4d019 introduced a bug where TRR reading reaching the end of
the file was indistinguishable from a reading error or a magic-number
error. This is now fixed, restoring the end-of-file behaviour that
existed before f7d4d019, while retaining the wrong-magic-number
behaviour that it introduced.
Refs #1926
Change-Id: Ic8540846c481f022bc6ae7b774794792c8c7a523- Uploads: