On Fri, Jan 23, 2015 at 11:10 AM, Joseph Baker <bakerj.tcnj.edu> wrote:
> Hi Jason,
>
> Some responses below, and a figure attached for CPU vs GPU
>
> On Fri, Jan 23, 2015 at 10:37 AM, Jason Swails <jason.swails.gmail.com>
> wrote:
>
> > On Fri, Jan 23, 2015 at 10:03 AM, Joseph Baker <bakerj.tcnj.edu> wrote:
> >
> > > Hi all,
> > >
> > > Hector, thanks for the link. Our inputs are only different in that you
> > have
> > > turned on SHAKE with a 1 fs timestep. I had not employed SHAKE with
> the 1
> > > fs timestep simulations, as I thought ntc=ntf=2 is typically only
> > required
> > > when going to a 2 fs timestep and/or when TIP3P water is included in
> the
> > > simulation.
> > >
> >
> > This depends strongly on the frequencies of the fastest motions (which
> is
> > really just a reflection of how big the forces become). The stronger the
> > forces (higher the frequencies of some motions), the shorter time step
> that
> > is needed.
> >
> > For typical protein simulations, 0.002 with SHAKE and 0.001 without are
> > *typically* sufficient. It wouldn't surprise me if the IL forces are too
> > high for those time steps to conserve energy as well. But I *would* be
> > surprised if 0.0001 fs was still too long even without SHAKE (I thought I
> > remembered you mentioning that you tried that timestep...).
> >
> > Yes. I did have a dt=0.0001 test of the pure IL without SHAKE and it was
> better than 0.001 and 0.005 for dt, but still did not get to the level of
> energy conservation I was seeing in the protein+water simulation.
>
>
> > This is still all conjecture until the range in which the forces in the
> IL
> > and protein simulations occur is established, though.
> >
> > Agreed. I'll check and see what those force outputs look like.
>
>
> > (I also think that a CPU simulation would be useful to eliminate a quirk
> in
> > the GPU code as a culprit).
> >
> > I ran a CPU test last night. It is the same IL system we've been
> discussing. dt=0.001, cut=8.0, NVE. dsum_tol is at its default value. I've
> plotted the CPU data (black curve, using pmemd.MPI) for Etot vs time
> alongside the GPU data (red curve, using pmemd.cuda). Figure is attached.
> So the CPU average drift (just fitting a line) is better than the GPU
> drift, but it is still of order 10^-4.
>
What about DPFP compared to CPU? If those are basically the same, then
you can probably eliminate "GPU quirk" from your list of suspects.
Another thing Ross pointed out, that might be tough to detect directly, is
cases in which the NET force is small, but the components of that force are
large. It's possible that the SPFP precision model is losing significant
bits when subtracting two large numbers. I'm not sure how this would
manifest in a comparison of force distributions b/w water and the IL,
though...
maybe broader force distributions in the IL?
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jan 23 2015 - 08:30:03 PST
