From: Michel Cuendet <[EMAIL PROTECTED]>
Reply-To: Discussion list for GROMACS users <gmx-users@gromacs.org>
To: gmx-users@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
_______________________________________________
gmx-users mailing list gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
