What you say is very interesting Jason. I had not realized this. I thought
that merely turning netcdf option on for restart and coordinate files
should resolve this problem. So I guess any GPU run should have iwrap=1 on
as standard. It would be worth making this clear in the manual and AMBER
GPU webpage as it seems like a gotcha that many people would be caught out
by.
Also considering the ongoing issues with some of the GPU's it would help
with troubleshooting what appears to be an ephemeral problem.
On 10 July 2013 04:06, Jason Swails <jason.swails.gmail.com> wrote:
> Well I had a response typed out, but it was not as instructive as Dan's.
> Since I did have one footnote that he didn't, I'll add just that below.
>
> On Tue, Jul 9, 2013 at 10:47 PM, Daniel Roe <daniel.r.roe.gmail.com>
> wrote:
>
> > [snip]
> > > In terms of NVE simulations would it be advantageous to run a
> > > short 1-2 ns simulation, re-image the trajectory, and then use the new
> > > trajectory coordinates to continue with a full 20 ns NVE simulation?
> >
> > As far as I know re-imaging the trajectory should have no affect on
> > the dynamics. The one exception is possibly if you have distance
> > restraints, which I think are not imaged.
> >
> >
>
> GPUs complicates things a little. Because it uses single precision in some
> locations and enables us to run insanely long simulations, there are times
> when the values of the coordinates become so large as to swamp out too many
> significant bits. When you calculate the image that belongs in the
> 'simulated' cell, you are effectively subtracting two huge numbers, leaving
> you with a very uncertain value for the particle positions (a recipe for
> disaster).
> In this case, the particles need to be re-imaged back into the central
> cell before they move too far to become a problem. However,
> if you just use "iwrap=1"
> in the mdin file
> (and use the 'unwrap' function cpptraj when you need to study diffusion
> properties), you should never have a problem.
>
>
> A groupmate of mine recently ran a ca. 640 ns simulation without wrapping
> on the GPUs, and about halfway through the simulation devolved into NaNs
> and ****s for this very reason. Adding iwrap=1 (and nothing else) fixed
> his problems.
>
> Good luck,
> Jason
>
> P.S. It seems I am an amateur nitpicker today. In principle, Dan's right
> in that imaging has no effect on dynamics, but the very real limitations of
> single precision as it's used in Amber in certain places warrants a
> mention, IMO (especially since 500 ns simulations are now routine).
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jul 10 2013 - 13:30:02 PDT
