Date: Fri, 20 Sep 2002 12:14:11 -0700 (PDT)
From: Thomas Cheatham
Subject: Re: vlimit and vmax


p.s. regarding the NPAIRS, increase this in sizes.h and recompile.

> I started a dynamics simulation on a protein molecule with
> explicit water using Amber 6 ( sander_classic). I am running it on
> an sgi iris platform. The initial minimisation ran without
> problem. when I started the equilibration md , I get the below
> error. How can I rectify this.
...
> NSTEP = 2 TIME(PS) = 0.004 TEMP(K) =215744.72 PRESS

There are clearly some problems, and setting VLIMIT will not overcome
them as by the second step your pressures and electrostatics have already
gone to nan (not a number).

There are three things I would check:

(1) Was the minimization successful in bringing the total energy down
(i.e. large negative electrostatic value if water is present) with an
energy gradient likely less than 0.1 or better?

--if the initial minimization was not sufficient to relax bad overlaps,
initially large forces could blow up the system. Large motions, due to
bad overlap, often lead to SHAKE failures. High velocities are evidence
of large forces...

(2) Are you sure the periodic box size is correct, i.e. it hasn't changed
over the course of your equilibration?

--you can also get effectively large jumps in coordinates due to imaging;
if the box size was too small upon the start of dynamics, imaging could
lead to overlapping atoms that would lead to large forces, etc. In
AMBER6, the minimization restart files do not contain box information and
therefore by default you would be using the values in the prmtop; if these
are not the values you want, in sander_classic's mdin file, in the &ewald
namelist I believe you can set the box size; an alternative is to edit the
last line of the prmtop to manually change the box size.

(3) A further problem may result if atoms are (completely) overlapped in
your coordinates (i.e. you have two atoms on top of one another);
minimization will not fix this since the minimizer cannot escape the
singularity. I saw this happen with earlier versions of LEaP that
accidently placed counterions in the same place. You can detect this
behavior using ptraj to read your prmtop and coordinates and use the
checkoverlap command:

ptraj prmtop << EOF
trajin inpcrd
checkoverlap
EOF


Good luck!