Thanks Daniel and Jason for the advice and sharing your knowledge, the box
and re-imaging makes sense now!
Cheers,
Parker
On Wed, Jul 10, 2013 at 4:26 PM, ET <sketchfoot.gmail.com> wrote:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jul 10 2013 - 17:00:02 PDT
