Hi Joe,
If you don't mind you would try the input in the previous post:
http://archive.ambermd.org/201410/0198.html
May be, the steps in the Etot vs time curves could be due nscm <> 0.
Greeting,
Hector.
> 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?
>
> Thanks,
> Joe
>
>
> On Thu, Jan 22, 2015 at 6:24 PM, Joseph Baker <bakerj.tcnj.edu> 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 <tec3.utah.edu> 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.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>>
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--------------------------------------
Dr. Hector A. Baldoni
Area de Quimica General e Inorganica
Universidad Nacional de San Luis
Chacabuco 917 (D5700BWS)
San Luis - Argentina
hbaldoni at unsl dot edu dot ar
Tel.:+54-(0)266-4520300 ext. 6157
--------------------------------------
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jan 22 2015 - 17:00:02 PST
