Re: [AMBER] NVE GPU question

From: Joseph Baker <bakerj.tcnj.edu>
Date: Fri, 23 Jan 2015 11:10:54 -0500

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.


> All the best,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> 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


gpu_vs_cpu.jpg
(image/jpeg attachment: gpu_vs_cpu.jpg)

Received on Fri Jan 23 2015 - 08:30:02 PST
Custom Search