Re: [AMBER] Fwd: NVE GPU question

From: Joseph Baker <>
Date: Thu, 22 Jan 2015 19:26:24 -0500

Here is a plot with different values of dsum_tol, with a 1 fs timestep, 8 A
cutoff. The drifts are from a linear fit to the entire data set (not great,
obviously, but gives the trends). The black curve is shorter just because I
ran it less steps (forgot to change nstlim to a smaller number in the other
three simulations). Y-axis units are the units of Etot in the Amber output,
and x-axis is picoseconds.

Black curve (dsum_tol = default)
drift = 7.4 x 10^-4 kT/ns/dof

Red curve (dsum_tol = 1 x 10^-6)
drift = 4.6 x 10^-4 kT/ns/dof

Green curve (dsum_tol = 1 x 10^-7)
drift = 3.2 x 10^-4 kT/ns/dof

Blue curve (dsum_tol = 1 x 10^-8)
drift = -1.1 x 10^-4 kT/ns/dof

So, dsum_tol does appear to have an influence on the energy conservation.
Is it still not as good as one would like at dsum_tol = 1 x 10^-8? Also, is
it strange that there are "steps" in the Etot vs time curves?


On Thu, Jan 22, 2015 at 6:24 PM, Joseph Baker <> wrote:

> Hi all,
> Jason, I did have a dt=0.0001 test and there the drift was 1.8 x 10^-4
> kT/ns/dof (compared to 2.9 x 10^-4 and 3.6 x 10^-4 for dt=0.005 and
> dt=0.001, respectively). So better, but not by leaps and bounds.
> I am trying dsum_tol tests now, and will see how that goes. I have not
> tried the PME order because I have been using pmemd.cuda, as you mention.
> I haven't tried ntwf to check the forces yet, and I don't have CPU data
> for this system. I will check that to see if the drift is better on the CPU.
> Gerald, I've been computing the drift by using the regression tool in
> xmgrace to fit a line to the Etot vs time data from the amber output file.
> That slope I then I convert to kT/ns/dof by taking
> slope/0.593*1000/(3*number of atoms) (the factor of 1000 is to convert to
> ns since the time unit in the Etot vs time file is ps)
> Thomas, thanks for the additional input on the grid size.
> Joe
> On Thu, Jan 22, 2015 at 5:58 PM, Thomas Cheatham <> wrote:
>> > ‚ÄčAh, ew_type=1 means pure Ewald (no PME). So rsum_tol doesn't do what I
>> > thought it did... I guess dsum_tol is the setting to play with, although
>> > it's not clear to me that that will improve overall accuracy.
>> >
>> > You could also try to set the PME order to 5 or so (I don't think that
>> will
>> > work with pmemd.cuda, but it should work with pmemd, and hopefully give
>> > better accuracy in the reciprocal forces).
>> ...and increase FFT grid size (in addition to order) for the
>> reciprocal...
>> --tec3
>> _______________________________________________
>> AMBER mailing list

AMBER mailing list

(image/jpeg attachment: nveplots.jpg)

Received on Thu Jan 22 2015 - 16:30:02 PST
Custom Search