AMBER Archive (2006)

Subject: Re: AMBER: problem in center command

From: Thomas Cheatham (
Date: Fri Jan 20 2006 - 21:37:49 CST

> > I can not understand that my mdcrd file is corrupt,
> > but my out file has no problem. I am trying....
> If you look at the energies etc in your mdout you will likely
> see some sort of anomaly consistent with atoms moving beyond
> the ability of mdcrd format to hold the numbers. Around the

As mentioned in previous replies, the precision in the output trajectory
(mdcrd) is rather low. However, this does not effect the MD as it is
running, only when the trajectory is later processed (by any program) or
upon restart if the coordinates have moved really far (since the restrt
file has a slightly higher precision). Internally, all the coordinates
and energies are stored as double precision floating points, so internally
the coordinates and energies are fine and the program is happy even though
the mdcrd may have **** values due to overflow.

As Ross Walker mentioned, this can be caused by instabilities in the
system (leading to large forces and large movements pushing particles away
very fast until they move beyond -999.99 or +9999.99)-- however this is
very unlikely in your case since the energies are fine-- or due to random
thermal motion / diffusion during dynamics where the molecules gradually
move until they go out of the bounds of the trajectory format. You cannot
"fix" the MD trajectory, at least not from the frame with *** onward.
You will have to re-run. If you want to start from the last restrt file
you have prior to the **** in the mdcrd, you will likely encounter the
problem again unless you center the coordinates to the origin. If some
coordinates are already at the origin, and you still have the problem
(perhaps due to an ion that has diffused away in an in vacuo simulation)
you are out of luck and must find a way to prevent the free particles from
diffusing away.

To visually see this behavior in your trajectory, load it into VMD
(*without* having previously done any command such as center, rms or image
commands with ptraj, i.e. load the raw trajectory directly from the MD)
and watch it (until it fails). Likely you will see at least one particle
moving far far away...

In pure non-periodic in-vacuo simulation, there is no easy way to avoid
the problem of particles freely diffusing away (as it is a vacuum!). If
the entire system is moving (which is very likely at least at slow speed
since the probability of assigning an initial velocity at 300K without any
net translational component is rather small) you can set a flag to remove
center of mass rotation and translation every 50-5000 steps (NSCM=500).
More tricky ways to overcome this, if only one or a few particles are
moving away (like ions), are to play with the solvent cap options or to
add weak flatwell distance restraints that add a penalty only when the
atom moves a fair distance from the solute. You could also treat the
non-periodic system as periodic with a large empty box (but of course a
box with sides of less than 999*2 A) however with this you could suffer
periodicity artifacts.

If you are running periodic boundary conditions:

(1) check to make sure you are wrapping the coordinates (IWRAP = 1). If
not, particles will diffuse into adjacent periodic images which given
enough time may blow the trajectory format (even though the imaging is
(2) make sure the center of mass translational motion of the entire
system is being removed periodically (NSCM=100).

Hopefully this should clarify things...

\-/ Thomas E. Cheatham, III (Assistant Professor) College of Pharmacy
-/- Departments of Med. Chem. and of Pharmaceutics and Pharm. Chem.
/-\ Adjunct Asst Prof of Bioeng.; Center for High Performance Computing
\-/ University of Utah, 30 S 2000 E, SH 201, Salt Lake City, UT 84112
/-\ (801) 587-9652; FAX: (801) 585-9119
\-/ BPRP295A

The AMBER Mail Reflector
To post, send mail to
To unsubscribe, send "unsubscribe amber" to