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

[chris.neale at utoronto.ca]

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.