[gmx-users] trjconv -dt issue

Matthias Ernst matthias.ernst at physik.uni-freiburg.de
Thu Aug 20 15:59:52 CEST 2015

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? 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?
- 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?
- 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 ;-)

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, 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.
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?

Thanks a lot,

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

More information about the gromacs.org_gmx-users mailing list