Bug #882
trjconv creates infinite trajectory
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 trajectoryUnder 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.
Associated revisions
Merge "Fixes #882 - looping bug in trxio.c" into release-4-5-patches
History
#1 Updated by David van der Spoel about 7 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 7 years ago
- File bugtest.gro bugtest.gro added
- File bugtest_s10.xtc bugtest_s10.xtc added
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 7 years ago
- Priority changed from Normal to High
- Target version set to 4.5.6
#4 Updated by Rossen Apostolov almost 7 years ago
- Priority changed from High to Normal
#5 Updated by David van der Spoel almost 7 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 7 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 6 years ago
- Status changed from New to Closed
Fixes #882 - looping bug in trxio.c
This led to infinite output files in the case of a corrupt
input file.
Change-Id: I25d61752d901012e9ce5e6adae1679c2ef99467a