[gmx-users] trjconv -dt issue

[Mark Abraham]

Hi,

This is indeed problematic. The .edr format (and its tools) are designed
with limitations that were not really a problem 10 years ago. One of the
limitations is that the time itself is stored in the same precision as the
simulation data, and this starts to lose precision as the simulation
proceeds into the millions of MD steps.

I think your practical course is to keep the simulation in the chunks that
you already have, and do your subsampling from them. You may get a better
result if you pre-process each chunk to "start" from zero time (or making
smaller chunks if you need to). This will help by keeping the side of the
stride closer to the absolute value of the time.

Another alternative is to pre-process the chunks with a double-precision
eneconv, which will write the times in double precision. That won't help if
they're stored wrongly in the first place, but may help you handle some
longer trajectory (at cost of more disk space).

Mark

On Wed, Aug 19, 2015 at 11:50 PM Matthias Ernst <
matthias.ernst at physik.uni-freiburg.de> wrote:

> Hello,
>
> I have a quite long continuous trajectory coming from several initial
> input pieces (cluster crashed...) that I want to downsample, as a start
> from 0.5ps timestep in the source files to just 1ps and later bigger
> timesteps.
>
> Using the -dt option of trjconv (GROMACS 4.6.5.), there seem to be
> rounding issues which leads to times at .5ps being written from some
> timestamp on (4.1943e+06). Is this a known behaviour?
>
> Related to this, what does the following sentence in the help for
> trjconv -dt mean:
> "This option relies on the accuracy of the times in your input
> trajectory, so if these are inaccurate use the -timestep option to
> modify the time (this can be done simultaneously)."
> How can I change the input timestep to get a "proper" output of output
> frames? I tried to use -timestep 1 it to my trajectory with 0.5ps
> timestep and it seems to produce "correct" timestamps in 1ps steps in
> the output file but the coordinates still are those of the initial
> frames with the 0.5ps timestamps, meaning it just relabels the
> timestamps of the frames. Using "-timestep 0.5 -dt 1" together does not
> change the result compared to "-dt 1" only.
>
> If I rather use the "-t0 0" option, I can "reset" the time of the first
> frame and then, it looks like it writes the "correct" 1ps stepped frames
> with 1ps timestamps, but starting at time 0. As I have several
> trajectory pieces from a continuous timeseries to concatenate, I would
> have to run trjconv once more just to correct and "reset" the time to
> its initial value, which means a lot of unnecessary data transfer,
> especially in the case of long trajectories.
> Is this really necessary or is there another way to get a "proper"
> downsampling?
> I know I can use  the -skip 2 option but e.g. not for eneconv which only
> supports -dt and has the same issues. Further, just using -skip 2 is not
> possible if some input files are at 0.5ps, but some other already at 1ps
> time steps.
>
> Thank you for your help,
> Matthias
>
> --
> Progress... http://www.phdcomics.com/comics/archive.php?comicid=1611
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>