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.
Also, thanks to both you and Ross for bringing up setting nscm to 0. I will
add this to the script and see how that improves thing.
Comparing the dynamic range of the forces should also be straightforward,
as I have the protein system that was behaving well in NVE lying around for
comparison.
Thanks to all for the advice. This should be a good start for devising some
tests to figure out what is going on with the IL.
Joe
On Fri, Jan 23, 2015 at 9:04 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi Joe,
>
> Yes you should have nscm=0 here. You should also devise a list of
> simulations that tests things in a systematic fashion. I would start by
> trying the CPU code and also DPFP - this will show you the effect of the
> precision model. As Jason pointed out the dynamic range of the individual
> forces may be much larger for an ionic liquid due to the high charges. It
> would help to establish what the dynamic range is compared with a typical
> protein in water simulation. If the dynamic range is too large then it may
> be inappropriate for the SPFP precision - at least to the point that you
> may be losing precision - especially if you have lots of forces of opposite
> sign that ultimately sum to zero.
>
> All the best
> Ross
>
> > On Jan 22, 2015, at 4:58 PM, Hector A. Baldoni <hbaldoni.unsl.edu.ar>
> wrote:
> >
> > 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
>
>
> _______________________________________________
> 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 Fri Jan 23 2015 - 07:30:03 PST
