Project

General

Profile

Bug #882

trjconv creates infinite trajectory

Added by Jan Henning Peters about 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
David van der Spoel
Category:
analysis tools
Target version:
4.6
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I observed this problem under the following circumstances:

- the input trajectory is concatenated .xtc file from different trajectories, i.e. containing more then one frame with t=0.0
  - both options -b and -e have been supplied to trjconv  (the problem is not observed if no -b option is used)
  - the -e option specifies a time greater than any timestamp in the trajectory

Under these circumstances, trjconv continues writing out data into the output trajectory file, probably until there is no more space left on the drive (in one case I stopped it after reaching 1.4TB). The output seems to consist of continuous repetitions of the input trajectory.

bugtest.gro (3.49 KB) bugtest.gro structure file Jan Henning Peters, 02/15/2012 11:04 AM
bugtest_s10.xtc (823 KB) bugtest_s10.xtc trajectory file Jan Henning Peters, 02/15/2012 11:04 AM

Associated revisions

Revision effe8e43 (diff)
Added by David van der Spoel almost 8 years ago

Fixes #882 - looping bug in trxio.c

This led to infinite output files in the case of a corrupt
input file.

Change-Id: I25d61752d901012e9ce5e6adae1679c2ef99467a

Revision 81e3359c
Added by Mark Abraham almost 8 years ago

Merge "Fixes #882 - looping bug in trxio.c" into release-4-5-patches

History

#1 Updated by David van der Spoel about 8 years ago

Can you provide an example (not 1.4Tb) and exact command lines to reproduce this?
Which gmx version? I guess this bug will exist in most versions.

#2 Updated by Jan Henning Peters about 8 years ago

Using the attached file and the command line

trjconv -s bugtest.gro -f bugtest_s10.xtc -b 10000 -e 150000 -o error.xtc

,I can reproduce the bug using the following two versions of gromacs:
4.0.7
4.5.5-dev-20110921-e25c350
(I agree that this will probably happen in most versions)

Also, when I tried to further reduce the size of the files (bugtest_s10.xtc is a "-skip 10" version of the full trajectory), the behaviour changed - using the same command on a "-skip 100" trajectory (alternatively on a "-skip 10" version of the attached trajectory), trjconv freezes without creating the output file.

#3 Updated by Rossen Apostolov almost 8 years ago

  • Priority changed from Normal to High
  • Target version set to 4.5.6

#4 Updated by Rossen Apostolov almost 8 years ago

  • Priority changed from High to Normal

#5 Updated by David van der Spoel almost 8 years ago

  • Target version changed from 4.5.6 to 4.6

This is a very nasty bug that sits very deep in the trajectory reading routine, in trxio.c:

if (bTimeSet(TBEGIN) && (fr->time < rTimeValue(TBEGIN))) {
            if (xtc_seek_time(status->fio, rTimeValue(TBEGIN),fr->natoms)) {
                gmx_fatal(FARGS,"Specified frame doesn't exist or file not seekable");
            }

what this does is seek the begin time (-b 10000) if the present time is less than the begin time. However, when the time in the trajectory suddenly jumps backward,
trjconv realizes it is before the -b time, and starts seeking again: from the beginning. Hence the loop.

Unfortunately this code is rather difficult and I would rather not touch it at this point in time. What needs to be done is that xtc_seek_time gets an additional flag telling it to seek forward only, that is not to start from a file offset of zero again. Upping the target version to 4.6, but 5.0 seems more likely.

#6 Updated by Szilárd Páll almost 8 years ago

Can't we aim for 4.5.6? The consensus anyway seems to be that 4.5.6 and 4.6 should come out at the same time and the 4.5.x should enter into a "critical bugfixes only" state.

#7 Updated by Roland Schulz over 7 years ago

  • Status changed from New to Closed

Also available in: Atom PDF