[gmx-developers] timestamp rounding in xtc

[Erik Lindahl]

Hi,

Actually there will very soon be a way around it: We have a new and even better highly-compressed trajectory format that will be available from Gromacs-5.0 :-)

Cheers,

Erik

On 09 Nov 2013, at 07:14, Tsjerk Wassenaar <tsjerkw at gmail.com> wrote:

> Hi Paul,
> 
> The rounding is due to the storing of the time in the XDR float format, using limited precision. There is no way around there. To get the time correctly, you can use the time stamps from the energy file, and use paste/awk to replace the rounded time with the actual one, or you can use awk and the time step to set the time.
> 
> Hope it helps,
> 
> Tsjerk
> 
> 
> On Sat, Nov 9, 2013 at 12:50 AM, Whitford, Paul <p.whitford at neu.edu> wrote:
> GMX Developers,
> I have a long simulation, and I noticed that at some point the timestamp in the xtc file gets rounded.  For sufficiently long simulations, this leads to many frames having the same timestamp. Here is a sample output from g_dist
> 
> 15689440.0000000    4.1125884   -0.8720000   -3.9099998    0.9300003
> 15689441.0000000    4.0926588   -0.8410001   -3.8730006    1.0209999
> 15689441.0000000    4.0091296   -0.8900001   -3.7840004    0.9809999
> 15689442.0000000    3.9852955   -0.8520000   -3.7909999    0.8860002
> 15689443.0000000    3.9080644   -0.8450000   -3.6969995    0.9440002
> 15689443.0000000    3.8975551   -0.8559999   -3.6749997    0.9760003
> 15689444.0000000    3.9498629   -0.8680000   -3.7300005    0.9670000
> 15689444.0000000    3.9664337   -0.9370000   -3.7350001    0.9510002
> 
> 
> I then use g_energy for the edr file from the same run:
> 
> 15689440.200000  -68.322456
> 15689440.800000  -24.153179
> 15689441.400000  -172.497147
> 15689442.000000  -143.456650
> 15689442.600000  -225.489212
> 15689443.200000  -185.056137
> 15689443.800000  -192.895752
> 
> 
> I checked gmx_dist.c, and it appears to not be performing any rounding, so it looks like the timestamp is rounded before it is saved to the xtc. Though, perhaps I am misunderstanding the code.
> 
> Additionally, when I run gmxcheck on the xtc file, I get many errors, similar to:
> 
> Reading frame       0 time 15689440.000   
> Reading frame       2 time 15689441.000   
> Timesteps at t=1.56894e+07 don't match (1, 0)
> Reading frame       3 time 15689442.000   
> Timesteps at t=1.56894e+07 don't match (0, 1)
> Reading frame       5 time 15689443.000   
> Timesteps at t=1.56894e+07 don't match (1, 0)
> Reading frame       6 time 15689444.000   
> 
> 
> In later runs, this gets worse, and it appears to round to the nearest 2 ps, and not 1 ps.
> 
> These errors seem consistent with my impression that the timestamp is rounded before it is saved to the xtc.
> 
> Is there a need for this rounding?  I'm having trouble finding the source of it, so I'm also not sure how to disable it.  If you can point me to the right lines, that would be great.
> 
> Your help is much appreciated.
> 
> Paul Whitford
> 
> -------------------------------------------------------
> Paul Whitford, Assistant Professor
> Department of Physics
> Dana Research Center, Room 123
> Northeastern University
> Boston, MA 02115
> Office: 617-373-2952
> Email: p.whitford at neu.edu
> 
> 
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
> 
> 
> 
> -- 
> Tsjerk A. Wassenaar, Ph.D.
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20131109/95f9fd05/attachment.html>