Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GROMACS GROMACS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 315
    • Issues 315
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 92
    • Merge requests 92
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GROMACS
  • GROMACSGROMACS
  • Issues
  • #1926
Closed
Open
Issue created Mar 18, 2016 by Paul Bauer@acmnpvMaintainer

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:
    • GmxAnalysisLittleEndianSegfault.tgz
Assignee
Assign to
Time tracking