[gmx-developers] timestamp rounding in xtc
Whitford, Paul
p.whitford at neu.edu
Sun Nov 10 18:46:48 CET 2013
Tsjerk and Erik,
Thanks for the feedback. That was the workaround I have been using. Looking forward to seeing v 5.0.
Best,
-------------------------------------------------------
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
On Nov 10, 2013, at 6:00 AM, gmx-developers-request at gromacs.org wrote:
> Send gmx-developers mailing list submissions to
> gmx-developers at gromacs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> or, via email, send a message with subject or body 'help' to
> gmx-developers-request at gromacs.org
>
> You can reach the person managing the list at
> gmx-developers-owner at gromacs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gmx-developers digest..."
>
>
> Today's Topics:
>
> 1. Re: timestamp rounding in xtc (Tsjerk Wassenaar)
> 2. Re: timestamp rounding in xtc (Erik Lindahl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 9 Nov 2013 13:14:22 +0100
> From: Tsjerk Wassenaar <tsjerkw at gmail.com>
> Subject: Re: [gmx-developers] timestamp rounding in xtc
> To: Discussion list for GROMACS development
> <gmx-developers at gromacs.org>
> Message-ID:
> <CABzE1ShQ3jN2SCqMHOa3J2hoxqWyY6rAiXsgQvjWXi-nZqJvHg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.gromacs.org/pipermail/gmx-developers/attachments/20131109/82ef8f07/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Sat, 9 Nov 2013 12:43:16 -0500
> From: Erik Lindahl <erik.lindahl at scilifelab.se>
> Subject: Re: [gmx-developers] timestamp rounding in xtc
> To: Discussion list for GROMACS development
> <gmx-developers at gromacs.org>
> Message-ID: <057B92B0-D250-4B2E-8A10-6C40C05629F4 at scilifelab.se>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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://lists.gromacs.org/pipermail/gmx-developers/attachments/20131109/95f9fd05/attachment-0001.html
>
> ------------------------------
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>
>
> End of gmx-developers Digest, Vol 115, Issue 10
> ***********************************************
More information about the gromacs.org_gmx-developers
mailing list