[gmx-developers] mdrun -maxh creates a .xtc trajectory with noisy timestep

[Berk Hess]

Hi,

What you describe should not happen, unless you use a non-standard
procedure.
How do you continue your simulations?

If you do nothing else (no grompp, tpbconv, etc) but mdrun -cpi
then you should not change your spacing in any output file (except for
some extra
energy frames, which is fixed in the next release).

BTW I just made -append the default, since it git master we have md5sums
of the output
files this should be completely safe.

Berk

chris.neale at utoronto.ca wrote:
> Dear developers,
>
> I am posting this directly here because the old wiki wish list section
> does not appear to exist anymore.
>
> The scheduler at our local cluster limits jobs to <=48 h of walltime.
> We therefore grompp jobs that will essentially run forever and use
> mdrun -maxh -noappend to limit walltime with an automated resubmission
> script.
>
> The annoyance is that the .cpt file is written between usual ouput
> time periods and thus the trjconv concatenated trajectory has no
> global timestep. For example, I might get md.part0001.xtc with a frame
> every 10 ps that runs from 0 to 2139.4 ps and then my md.part0002.xtc
> has a frame every 10 ps that starts at 2139.4 ps. I am not sure what
> the behaviour would be if we used mdrun -append, but cluster
> instability has us worried about using that feature in any event.
>
> It would be nice if mdrun could be smarter about when it should output
> to the .xtc and other files (i.e. not resetting its t0 every segment
> of the run). If that is not possible, then it would be nice if the
> user could add another option to mdrun to obtain this behaviour: e.g.
> mdrun -maxh 48 -dtmaxh 5000 where 5000 steps * 0.002 fs timestep is my
> desired 10 ps
>
> -maxh      real   -1    Terminate after 0.99 times this time (hours)
> -dtmaxh    real    1    Hold maxh termination until dt mod dtmaxh = 0
> (in steps)
>
> Ans dtmaxh would probably need to be done in steps, not ps, so that
> rounding errors would not cause a problem.
>
> Here is some output to show what I mean (gromacs 4.0.7)
>
> -$ for i in 2 3 4 5; do gmxcheck  -f md1_50ps.part000${i}.xtc 2>&1
> |grep Read|head -n 1; done
> Reading frame       0 time 4770.000
> Reading frame       0 time 9522.000
> Reading frame       0 time 14268.001
> Reading frame       0 time 19033.000
>
> Thank you,
> Chris.
>