Re: [AMBER] NaN error in .rst files

From: Jason Swails <>
Date: Tue, 25 Jan 2011 00:45:50 -0500

iwrap is strictly a visual artifact. In periodic simulations, all periodic
images are simulated at all times, but when visualizing we are restricted to
however many particles we started with in the simulation (that is to say,
one, and only one, unit cell's worth of particles). If you don't turn iwrap
to 1, then the "tracked" molecules don't change. If you do, then the only
tracked particles are the ones that reside in the same unit cell.
Therefore, if one particle migrates out of the unit cell, then its periodic
image that entered that cell (on the opposite side) takes its place in the
restart file.

However, when computing the energy and forces, both images (and the infinite
other images of those molecules) are included so it makes no difference
which one is chosen to represent in the restart file.

If iwrap=0 and you don't wrap molecules back into the unit cell, then they
diffuse to adjacent boxes. This is a problem for a formatted restart file.
The formatted restart file allows only 12 characters (F12.7) to represent
the number: 4 digits ahead of the decimal, the decimal, and 7 digits
behind. Therefore, if a value becomes greater than 9999.9999999, (or less
than -999.9999999, since one character is taken up by the - sign), the
number can no longer be represented in that field. Since the number can no
longer fit, the Fortran convention is to fill it with ************s to
indicate such. However, no program knows what to do with ************s,
since it represents no number. This is a sign of a corrupted restart file.

If you run long enough, this is guaranteed to happen (simple random walk

Hope this helps,

On Tue, Jan 25, 2011 at 12:30 AM, peker milas <> wrote:

> Than you Ross for your quick reply.
> First thing to say, i am not using this flag. But as far as i know in
> the manual it says that flag/option doesn't has no effect on either
> force or energy calculations. That is why i didn't use it. I can turn
> it on and check if same problem appears. But at the same time, i am
> just in the middle of a long calculation, so then another question
> appears in my mind. If i continue with iwrap flag/option, should i
> expect any important difference in the simulation results ? You
> definitely know much more than me about amber, can you tell me if it
> is safe ?
> best
> peker
> On Mon, Jan 24, 2011 at 7:54 PM, Ross Walker <>
> wrote:
> > Hi Peter,
> >
> > Before you check into this any further can I just confirm that you have
> > iwrap=1 set in the &cntrl namelist. If not then this is the problem and
> it
> > is a pmemd / sander issue, completely unrelated to cuda. It will, in
> > principal go away if we move to netcdf restart files.
> >
> > If you can confirm this only occurs with PMEMD.cuda and you have iwrap=1
> set
> > then it warrants investigating and the next step will be to see if anyone
> > has seen this problem on any of the Tesla cards or it is confined to GTX
> > series cards.
> >
> > All the best
> > Ross
> >
> >> -----Original Message-----
> >> From: peker milas []
> >> Sent: Monday, January 24, 2011 2:42 PM
> >> To: AMBER Mailing List
> >> Subject: [AMBER] NaN error in .rst files
> >>
> >> Dear Amber coders/users
> >>
> >> We had a discussion about this problem couple days ago. Briefly at
> >> some point of simulations pmemd.cuda creates NaN s in the restart
> >> files. Then the next step of simulation messes up. This is sort of a
> >> problem which happens in totally random way. As some users already
> >> pointed out, part of it can be related with heating problem because
> >> GTX 470/480 cards were not designed for this kind of intense
> >> calculations. Although i totally agree with this, i couldn't find an
> >> easy way of observing this behavior. In fact there is only nvidia-smi
> >> command which shows me the current state of the card (like its
> >> temperature, etc...). So i really want to go little bit deep with this
> >> problem and i would like to know if anybody knows a good indicator for
> >> checking cards behavior in detail. It can be a command or any sort
> >> additional package/program for monitoring it.
> >>
> >> Any help will be appreciated
> >>
> >> regards
> >> peker milas
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >>
> >>
> >
> >
> > _______________________________________________
> > AMBER mailing list
> >
> >
> >
> _______________________________________________
> AMBER mailing list

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
AMBER mailing list
Received on Mon Jan 24 2011 - 22:00:07 PST
Custom Search