[gmx-users] Re: mdrun -rerun and box size bug not fixed?

[Berk Hess]

>From: Michel Cuendet <michel.cuendet at isb-sib.ch>
>Reply-To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>To: gmx-users at gromacs.org
>Subject: [gmx-users] Re: mdrun -rerun and box size bug not fixed?
>Date: Tue, 6 Nov 2007 15:26:54 +0100
>
>
>Hi Berk,
>
>Thanks for your reply.
>
>>
>>The box is read, but in several parts of the code there are  optimizations
>>for fixed box dimensions (i.e. no pcoupl, no deform).
>>This is indeed a bit tricky, but I don't know if we would want to  change
>>this
>>for the rerun option.
>
>Maybe the optimizations are not necessary for the rerun option, as  energy 
>evaluations usually involve a limited number of frames. I  think that the 
>box sizes should really be read from the traj. The  present behavior seems 
>dangerous (I almost wasted a week of work  figuring it out, and some users 
>might never double check...)
>

The optimizations are certainly not necessary, but currently the information
that we are doing a rerun is not passed on to any routine except for
the main loop. We would have to pass this information along.

>>We do want scaling of velocties, since this influences the kinetic  
>>energy,
>>also for reruns.
>
>I never understood this one. The kinetic energy at step N should  depend 
>only on the velocities at time step N. If a frame in the  trajectory 
>contains the positions and velocities at time step N as it  should, no 
>rescaling is necessary.
>
>If on the other hand only velocities at step N-1/2 are saved,  velocities 
>at step N+1/2 would have to be calculated in order to get  accurate kinetic 
>energy at step N. In this case, rescaling indeed  needs to take place. But 
>the rescaling will be nonsense if a Nosé- Hoover thermostat is used, since 
>the thermostat momentum is not read  from the trajectory. If this is the 
>case, there should be a large  warning sign when using -rerun with 
>Nosé-Hoover. A solution would be  to output the kinetic energy at time step 
>  N-1/2 during the rerun,  which is in any case more accurate than the one 
>at step N, and is  just as good for statistics.

Ekin[t] = (Ekin[t-dt/2]+Ekin[t+dt/2])/2
This currently indeed goes wrong with Nose-Hoover, since the current
trajectory formats can not store the Nose-Hoover variables.
The kinetic energy at half steps does not match the potential energy
at the full step for calculating the total energy.

In general we do not want anything different to happen during an rerun
than would happen during a normal run, exactly to avoid discrepancies
between normal runs and reruns. Therefore we would like to avoid
passing along the rerun info deeping into the code.

>
>See a paper coming soon in JCP:
>M. M. A. Cuendet and W. F. van Gunsteren, On the calculation of  
>velocity-dependent properties in molecular dynamics simulations using  the 
>leap-frog integration algorithm, J. Chem. Phys. (in print) (2007).
>
>>We could consider using nstenergy=1 for rerun, but I think that  currently
>>you should already get the energy as often as for the original run,  
>>unless
>>you use a trajectory without step numbers (e.g. pdb).
>
>This is good, but without nstenergy=1 the averages are wrong in  md.log and 
>at the end of the run.

This is a nasty issue that we still have not fixed. We should fix this,
but things are complicated due to the way the averages and fluctations
are stored.

Berk.

_________________________________________________________________
Live Search, for accurate results! http://www.live.nl