Project

General

Profile

Bug #115

double frames after use of eneconv -f file1.edr file2.edr

Added by Alexandra Patriksson about 13 years ago. Updated about 12 years ago.

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

Description

Sometimes when I have run a simulation as several shorter subsimulations and
want to connect the edr-files from the subsimulations using eneconv, then the
large edr-file, made from all the small edr-files, gets double frames. If I run
gmxcheck -e on this "large" file I can get something like this:

----------------
Checking energy file trp_AAG_3.edr

Opened trp_AAG_3.edr as single precision energy file
frame: 0 (index 0), t: 0.000
Reading frame 200000 time 200000.000
Timesteps at t=200000 don't match (0.984375, 0.015625)

Timesteps at t=200000 don't match (0.015625, 1)
Reading frame 400000 time 399999.031
Timesteps at t=400000 don't match (0.96875, 0.03125)

Timesteps at t=400000 don't match (0.03125, 1)
Last frame read 500002 time 500000.000

Found 500003 frames.


This never happens to the xtc or trr-files because trjcat takes care of the
double frames. Why can't eneconv do that as well?

ebug.tgz (1.08 MB) ebug.tgz energy files David van der Spoel, 09/11/2007 09:27 PM
ebug.tgz (6.4 KB) ebug.tgz smaller energy files David van der Spoel, 09/11/2007 09:33 PM

History

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

It does normally, except that your simulations are so long that the precision of the floating point numbers is not enough to recognize the time stamps on the frames. This can probably be fixed only by introducing a new energy file format with double precision numbers for times and long ints for step number (we will soon reach more then 4e9 time steps as well).

However if you can show some example where this happens with energy files and not with e.g. xtc files I can have another look at it.

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

Created an attachment (id=232)
energy files

These two energy files reproduce the bug.

eneconv_d -f first second -o combined
gmxcheck -f combined

#3 Updated by David van der Spoel about 12 years ago

Created an attachment (id=233)
smaller energy files

These are smaller and reproduce the problem.

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

Fixed in CVS by comparing the time differences in first and second frames to the timestep rather than the precision of the float values. Note that there still are these comparisons (with GMX_REAL_EPS) present when using the begin and end options. These have not been changed for now.

Also available in: Atom PDF