[gmx-users] mdrun-adjusted cutoffs?!

Mark Abraham mark.j.abraham at gmail.com
Mon Dec 10 06:57:00 CET 2018 

Hi,

There's two ways to specify the long-range grid requirements (either
fourierspacing, or fourier-nx and friends,, see
http://manual.gromacs.org/documentation//current/user-guide/mdp-options.html#ewald).
The tuning will override fourierspacing in the same way that it does
rcoulomb. I assume it does not override a manual specification of the grid
dimensions, but I haven't tried it. Have noted to the dev team that we
should check and document that.

Mark

On Sun, Dec 9, 2018 at 7:46 AM Alex <nedomacho at gmail.com> wrote:

> That's very valuable info, thank you.
>
> By the way, all of our production mdp files have something like
> fourierspacing = 0.135, the origin of which is long gone from my memory.
> Does this imply that despite PME tuning our simulations use a fixed
> Fourier grid that ends up in suboptimal performance, or does the tuning
> override it?
>
> Alex
>
> On 12/8/2018 1:34 PM, Mark Abraham wrote:
> > Hi,
> >
> > Note that that will compare runs of differently accurate electrostatic
> > approximation. For iso-accurate comparisons, one must also scale the
> > Fourier grid by the same factor (per the manual section on PME
> autotuning).
> > Of course, if you start from the smallest rcoulomb and use a fixed grid,
> > then the comparisons will be of increasing accuracy, which might be
> enough
> > for the desired conclusion.
> >
> > Mark
> >
> > On Sat., 8 Dec. 2018, 02:05 Szilárd Páll <pall.szilard at gmail.com wrote:
> >
> >> BTW if you have doubts and still want to make sure that the mdrun PME
> >> tuning does not affect your observables, you can always do a few runs
> >> with a fixed rcoulomb > rvdw set in the mdp file (with -notunepme
> >> passed on the command line for consistency) and compare what you get
> >> with the rcoulomb = rvdw case. As Mark said, you should not observe a
> >> difference.
> >>
> >> --
> >> Szilárd
> >> On Fri, Dec 7, 2018 at 7:10 AM Alex <nedomacho at gmail.com> wrote:
> >>> I think that answers my question, thanks. :)
> >>>
> >>> On 12/6/2018 9:38 PM, Mark Abraham wrote:
> >>>> Hi,
> >>>>
> >>>> Zero, because we are shifting between equivalent ways to compute the
> >> total
> >>>> electrostatic interaction.
> >>>>
> >>>> You can turn off the PME tuning with mdrun -notunepme, but unless
> >> there's a
> >>>> bug, all that will do is force it to run slower than optimal.
> >> Obviously you
> >>>> could try it and see that the FE of hydration does not change with the
> >>>> model, so long as you have a reproducible protocol.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>> On Fri., 7 Dec. 2018, 06:39 Alex <nedomacho at gmail.com wrote:
> >>>>
> >>>>> I'm not ignoring the long-range contribution, but yes, most of the
> >>>>> effects I am talking about are short-range. What I am asking is how
> >> much
> >>>>> the free energy of ionic hydration for K+ changes in, say, a system
> >> that
> >>>>> contains KCl in bulk water -- with and without autotuning. Hence also
> >>>>> the earlier question about being able to turn it off at least
> >> temporarily.
> >>>>> Alex
> >>>>>
> >>>>> On 12/6/2018 5:42 AM, Mark Abraham wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> It sounds like you are only looking at the short-ranged component of
> >> the
> >>>>>> electrostatic interaction, and thus ignoring the way the long range
> >>>>>> component also changes. Is the validity of the PME auto tuning the
> >>>>> question
> >>>>>> at hand?
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>> On Thu., 6 Dec. 2018, 21:09 Alex <nedomacho at gmail.com wrote:
> >>>>>>
> >>>>>>> More specifically, electrostatics. For the stuff I'm talking about,
> >> the
> >>>>>>> LJ portion contributes ~20% at the most. When the change in
> >> energetics
> >>>>>>> is a statistically persistent value of order kT (of which about 20%
> >>>>>>> comes from LJ), the quantity of interest (~exp(E/kT)) changes by a
> >>>>>>> factor of 2.72. Again, this is a fairly special case, but I can
> >> easily
> >>>>>>> envision someone doing ion permeation across KcsA and the currents
> >> would
> >>>>>>> be similarly affected. For instance, when I set all cutoffs at 1.0
> >> nm,
> >>>>>>> mdrun ends up using something like 1.1 nm for electrostatics, at
> >> least
> >>>>>>> that's what I see at the top of the log.
> >>>>>>>
> >>>>>>> I agree with what you said about vdW and it can be totally
> >> arbitraty and
> >>>>>>> then often requires crutches elsewhere, but my question was whether
> >> for
> >>>>>>> very sensitive quantities mdrun ends up utilizing the forcefield as
> >> it
> >>>>>>> was designed and not in a "slightly off" regime. Basically, you
> >> asked me
> >>>>>>> to describe our case and why I think there may be a slight issue,
> so
> >>>>>>> there it is.
> >>>>>>>
> >>>>>>> Alex
> >>>>>>>
> >>>>>>> On 12/5/2018 10:34 PM, Mark Abraham wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> One needs to be more specific than NB. There is evidence that VDW
> >>>>> cutoffs
> >>>>>>>> of traditional lengths cause approximation errors that cause
> >>>>> compensating
> >>>>>>>> parameterization errors elsewhere; those effects get worse if the
> >>>>> system
> >>>>>>> is
> >>>>>>>> inhomogeneous. Accordingly, mdrun never touches VDW cutoffs.
> >>>>>>> Electrostatic
> >>>>>>>> with PME is quite another matter - there you need sufficient
> >> overall
> >>>>>>>> accuracy, and there are multiple equivalent ways to do that.
> >>>>>>>>
> >>>>>>>> Mark
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu., 6 Dec. 2018, 09:56 Alex <nedomacho at gmail.com wrote:
> >>>>>>>>
> >>>>>>>>> Hi Mark,
> >>>>>>>>>
> >>>>>>>>> I am not sure it is a concern, to be honest, so let me just lay
> >> out my
> >>>>>>>>> thoughts and maybe you could share your opinion.
> >>>>>>>>>
> >>>>>>>>> I recently shared a link for our recent paper
> >>>>>>>>> (https://www.nature.com/articles/s41563-018-0220-4), in which
> the
> >>>>>>>>> quantity of interest is ion current via pores that disallow what
> >> we
> >>>>>>>>> normally mean by diffusive permeation. Instead, there are
> >> considerable
> >>>>>>>>> barriers and ionic currents are rather precisely described by
> >>>>>>>>> exp(-E/kT), where E is some energy calculated from nonbonded
> >>>>>>>>> interactions and includes a huge contribution from the solvent.
> >> It is
> >>>>> my
> >>>>>>>>> understanding that NB stuff gets parameterized at a particular
> >> cutoff
> >>>>>>>>> value and our results are rather sensitive to that. I can't say
> >> we're
> >>>>>>>>> dying to have extreme repeatability, but is it in your opinion
> >>>>>>>>> acceptable to have variability in the cutoff radii and the rlist
> >>>>> between
> >>>>>>>>> something like 1.0 - 1.2 nm? To begin with, I am not particularly
> >>>>>>>>> worried about it, because we mostly report on qualitative
> >> behaviors,
> >>>>> but
> >>>>>>>>> I am interested in your opinion. I have read the manual and
> >>>>>>>>> unfortunately there is nothing in the way of actually showing
> >>>>> estimates
> >>>>>>>>> of NB energy variation as a function of small differences in
> >> cutoffs.
> >>>>>>>>> Thank you,
> >>>>>>>>>
> >>>>>>>>> Alex
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 12/5/2018 3:36 PM, Mark Abraham wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> There's quite detailed discussion of the treatment of pair
> >> searching
> >>>>> in
> >>>>>>>>>> section 3.4.2 of the reference manual. Perhaps that clarifies
> >> things?
> >>>>>>>>> We're
> >>>>>>>>>> not aware of a reason to want to control things manually, but if
> >> you
> >>>>>>> have
> >>>>>>>>>> one, we're keen to hear of it!
> >>>>>>>>>>
> >>>>>>>>>> Mark
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed., 5 Dec. 2018, 09:59 Alex <nedomacho at gmail.com wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>> We've long noticed that at the beginning of simulations mdrun
> >> goes
> >>>>>>>>> through
> >>>>>>>>>>> what seems like trying to adjust the short-range NB radii to
> its
> >>>>>>> liking.
> >>>>>>>>>>> What is up with that and does this mean that every simulation
> >>>>> proceeds
> >>>>>>>>> with
> >>>>>>>>>>> a new cutoff? If so, is there a way to disable this?
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you,
> >>>>>>>>>>>
> >>>>>>>>>>> Alex
> >>>>>>>>>>> --
> >>>>>>>>>>> Gromacs Users mailing list
> >>>>>>>>>>>
> >>>>>>>>>>> * Please search the archive at
> >>>>>>>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List
> >> before
> >>>>>>>>>>> posting!
> >>>>>>>>>>>
> >>>>>>>>>>> * Can't post? Read
> http://www.gromacs.org/Support/Mailing_Lists
> >>>>>>>>>>>
> >>>>>>>>>>> * For (un)subscribe requests visit
> >>>>>>>>>>>
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> >>>>> or
> >>>>>>>>>>> send a mail to gmx-users-request at gromacs.org.
> >>>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Gromacs Users mailing list
> >>>>>>>>>
> >>>>>>>>> * Please search the archive at
> >>>>>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List
> >> before
> >>>>>>>>> posting!
> >>>>>>>>>
> >>>>>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>>>>>>>>
> >>>>>>>>> * For (un)subscribe requests visit
> >>>>>>>>>
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> >>>>>>>>> send a mail to gmx-users-request at gromacs.org.
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> Gromacs Users mailing list
> >>>>>>>
> >>>>>>> * Please search the archive at
> >>>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> >>>>>>> posting!
> >>>>>>>
> >>>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>>>>>>
> >>>>>>> * For (un)subscribe requests visit
> >>>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> >> or
> >>>>>>> send a mail to gmx-users-request at gromacs.org.
> >>>>>>>
> >>>>> --
> >>>>> Gromacs Users mailing list
> >>>>>
> >>>>> * Please search the archive at
> >>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> >>>>> posting!
> >>>>>
> >>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>>>>
> >>>>> * For (un)subscribe requests visit
> >>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> or
> >>>>> send a mail to gmx-users-request at gromacs.org.
> >>>>>
> >>> --
> >>> Gromacs Users mailing list
> >>>
> >>> * Please search the archive at
> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> >> posting!
> >>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>>
> >>> * For (un)subscribe requests visit
> >>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> >> send a mail to gmx-users-request at gromacs.org.
> >> --
> >> Gromacs Users mailing list
> >>
> >> * Please search the archive at
> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> >> posting!
> >>
> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>
> >> * For (un)subscribe requests visit
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> >> send a mail to gmx-users-request at gromacs.org.
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.

More information about the gromacs.org_gmx-users mailing list