Project

General

Profile

Bug #117

Reading back XTC trajectories yields "wrong" numbers and errors

Added by Marc Baaden about 13 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
High
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

For analysis I wanted to check XTC files via gmxcheck prior to running other Gromacs tools.

Issue #1) I noticed that I don't always get the same numbers with version 3.3.1 as compared
to version 3.2.1. Example:

WITH 3.3.1:
Reading frame 0 time 1.000
  1. Atoms 3072
    Precision 0.001 (nm)
    Reading frame 9000 time 9001.000

Item #frames Timestep (ps)
Step 10000 1
Time 10000 1
Lambda 0
Coords 10000 1
Velocities 0
Forces 0
Box 10000 1

WITH 3.2.1:
Reading frame 0 time 1.000
  1. Atoms 3072
    Precision 0.001 (nm)
    Last frame 9999 time 10000.000

Item #frames Timestep (ps)
Step 10000 1
Time 10000 1
Lambda 0
Coords 10000 1
Velocities 0
Forces 0
Box 10000 1

Issue #2) For some XTC trajectories I get continuous errors like:
[..]
Warning at frame 2691: coordinates for atom 1741 are large (1.517)
Warning at frame 2691: coordinates for atom 1741 are large (10.574)
Warning at frame 2691: coordinates for atom 1742 are large (-3.856)
[..]
whith 3.3.1 whereas there is no problem with 3.2.1. This is problematic because given the
number of warnings that is output it takes an eternity to process the trajectory.

Concerning the first part of the bug, it's hopefully only a difference in the output/printing. But I
would want to be sure that XTC reading in 3.3.1 can be trusted before doing all my analysis
with it :)

For the second part - as I couldn't find anything wrong with my trajectory - it would be good to
be able to turn those warnings off.

History

#1 Updated by David van der Spoel almost 13 years ago

Hi Marc,

could you please upload an example? Maybe you can reduce the number of atoms if
it's big.

#2 Updated by David van der Spoel over 12 years ago

Marc,

can you please upload an example that gives this behavior? We have fixed bugs
with xtc io in CVS, but there can also be bugs due to sick compilers, most
notably gc 4.1.x

#3 Updated by Marc Baaden over 12 years ago

Hi,
sorry for taking so long. The file is a little more than 100 MB. So I put it on
a website at

http://www.shaman.ibpc.fr/gmxbug117.xtc

I hope this helps,
Marc

(In reply to comment #2)

Marc,

can you please upload an example that gives this behavior? We have fixed bugs
with xtc io in CVS, but there can also be bugs due to sick compilers, most
notably gc 4.1.x

#4 Updated by David van der Spoel over 12 years ago

I've reproduced the counting, but this is a feature. Counting is now more or
less logarithmic. How about the second problem? Do you have an example for this?

#5 Updated by Marc Baaden over 12 years ago

(In reply to comment #4)

I've reproduced the counting, but this is a feature. Counting is now more or
less logarithmic. How about the second problem? Do you have an example for

this?

Ok. The second one is at
http://www.shaman.ibpc.fr/gmxbug117bis.xtc

#6 Updated by David van der Spoel over 12 years ago

The message is because your box is zero. Maybe there should be an exemption for
that. I've implemented that in CVS now.

Note that some analysis tools assume you have periodic boundary conditions.

#7 Updated by Marc Baaden over 12 years ago

This was an implicit solvent simulation, so the absent box makes sense. Is this
the expected behavior for "in vacuo" simulations, or should one provide a box
even for those? (the trajectory was run with Amber/GB and then converted into
Gromacs/XTC)

#8 Updated by David van der Spoel over 12 years ago

It's not a problem, and as said I've put in a test for a zero box. You only have
to look out for analysis tools that use periodicity. If you find one that gives
you a wrong answer then please file a new bugzilla.

Also available in: Atom PDF