[gmx-users] trjconv -dt issue

[Mark Abraham]

Hi,

On Thu, Aug 20, 2015 at 4:00 PM Matthias Ernst <
matthias.ernst at physik.uni-freiburg.de> wrote:

> Thanks for your explanation, Mark.
>
> Concerning energy files and eneconv:
> - I will try double-precision eneconv, as I don't mind larger files.
> - In reply to the advice to "reset" the time of the energy files: how to
> do it?


I intended you to try eneconv -settime 0 for each file.


> eneconv has no option for this, although the help states:
> "With one file specified for -f:
> Reads one energy file and writes another, applying the -dt, -offset, -t0
> and -settime options and converting to a different format if necessary
> (indicated by file extentions)."
> Strangely, the -t0 option does not exist in eneconv (GROMACS 4.6.5) and
> if I try nevertheless, it states "Invalid command line argument: -t0".
> Is that an error in the help or was the option just forgotten for the

command line parsing of eneconv?
>

Looks like it :-(


> - The eneconv -offset option seems to do nothing for me (or I looked at
> the wrong spot). What does it do and how is supposed to work?
>

See doc string for -dt (so not useful for you)


> - And last: eneconv has, in contrast to trjconv, no -skip option which
> would allow for using every nth frame instead of choosing by time. Is
> that intended? Right now, it could be helpful for me, so I would like to
> state my request for it ;-)
>

Fair enough. My plan to fix such issues in the future is to move all energy
writing to the TNG format introduced in 5.0, and now there is no need for
two separate tools to do the same thing (and neither doing it very well).

A further option for you is to use gmxdump to get the data in a text format
- where the step number will be clear and potentially useful. That's a
one-way trip, however - you won't get the data back into .edr format. There
are some third-party MD analysis packages that might help, I have no idea.

Concerning xtc files:
> Obviously, the data types storing the step counter as well as the
> timestamp are too small for my data. The step counter overflows quite
> rapidly,


I think we changed the step counter to a 64-bit integer before GROMACS 4.5.
Doubtless some places print it badly, but I don't think you're doing 10^19
steps.


> but also the time only works for ps steps up to 1.6777216E7
> (i.e. ~16.777mus). Going further, only even numbers are stored. This
> gives a nasty number of "Timesteps at t=... don't match" messages when
> using gmxcheck to see if everything went alright, obscuring real errors
> that may be in between.
>

Yep. This gear is fast becoming out of date.


> Is there any chance of saving the correct times in the trajectory file
> (like using double-precision like for eneconv) or do I have to take care
> of this separately? Or is there some other format I could use to save
> the data efficiently?
>

Unless you run mdrun in double precision, the step number is the only
reliable thing, unfortunately. Internally, the magnitude of the step number
and time is only used for trivia, and clearly there are a number of things
that could be improved about how we handle writing and post-processing data.

Mark

Thanks a lot,
> Matthias
>
>
> On 08/20/2015 12:56 PM, Mark Abraham wrote:
> > 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.
> >>
>
>
> --
> 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.
>