double frames after use of eneconv -f file1.edr file2.edr
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?
#1 Updated by David van der Spoel about 13 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.
#4 Updated by David van der Spoel about 13 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.