[gmx-users] correct rlist and Verlet scheme

Wed Feb 17 18:16:02 CET 2016

As soon as I sent this off I realized that the work you refer to is
probably the one that was done by/at DE Shaw, so they must have used
Desmond so the non-bonded treatment is not exactly as in AMBER, but my
point is still valid regarding trying to reproduce the pair list
buffer.

--
Szilárd

On Wed, Feb 17, 2016 at 6:07 PM, Szilárd Páll <pall.szilard at gmail.com> wrote:
> Hi,
>
> The short-range interaction treatment in AMBER and GROMACS is quite
> different (to the best of my knowledge), so obsessing about rlist
> seems pointless to me.
>
> AMBER uses a heuristic list update where search is triggered based
> particles tracking ("safe" but inefficient strategy), whereas GROMACS
> uses a fixed list update frequency. The automated buffer estimate that
> ensures control of the non-boneded drift. Without controlling _both_
> buffer and search frequency (and a bunch of other subtle
> implementation details) you won't achieve identical computation.
>
> Hence, if you want to have (more or less) the same non-bonded
> calculation implemented in GROMACS, strictly speaking you'd have to
> use nstlist=1 or if you accept to be a bit less strict, a huge manual
> buffer (and small-ish nstlist) should achieve more or less the same.
> However, there are plenty of other algorithmic and implementation
> differences between AMBER and GROMACS, so I don't think it's worth
> worrying about getting the Verlet list buffer length to match.
>
> Cheers,
> --
> Szilárd
>
> PS: I thought AMBER FF was parametrized with 0.9 nm cut-off, isn't it?
>
>
> On Wed, Feb 17, 2016 at 2:45 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
>> Hi,
>>
>> Yes, what you say is true, but very much "in short" and AFAIK true of all
>> MD packages. :-)
>>
>> If e.g. AMBER (or anyone else) has a test suite for any force field, then
>> we'll seriously consider implementing it, to e.g. verify before each
>> release. :-) IMO, defining such a suite is a research topic itself -
>> particularly as the original parameterizations did so in the context of
>> limitations in the methods of the day. If a force field was parameterized
>> with a fixed buffer because nobody then knew how large a buffer was
>> necessary for a given quality of relevant observable, it does not follow
>> that the only possible acceptable practice now is to use that fixed buffer.
>>
>> Similar considerations apply to things like e.g. the use of long-ranged
>> corrections for dispersion interactions. e.g. AMBER99 was parameterized
>> without such corrections, so probably has built into its parameters some
>> compensating errors, and any kind of validation-by-replication should in
>> principle not use such corrections. But these days, I think that nobody
>> would actually recommend parameterizing a force field without something
>> like that, and experience suggests that using one is an improvement, even
>> if though the change is not officially sanctioned anywhere that I know of.
>> IMO showing that some range of force fields shows satisfactory agreement
>> with experiment under certain .mdp setting combinations is useful evidence
>> of an implementation that is valid, and that is what one can see in the
>> literature.
>>
>> The state of the art in software engineering is that nobody much has time
>> to test all the things that they'd like to test. (One large exception is
>> software for control of devices that potentially affect human health.)
>> Scientific software development has additional challenges because the
>> people doing it are often lacking in formal training in best practice, and
>> have to appear to publish science, in order to keep attracting funding, and
>> this directly conflicts with spending time on good software engineering
>> practice that granting and tenure committees will ignore later in their
>> careers...
>>
>> Mark
>>
>> On Wed, Feb 17, 2016 at 1:01 PM Timofey Tyugashev <tyugashev at niboch.nsc.ru>
>> wrote:
>>
>>> In short, FFs were tested to some degree when they were added in GROMACS
>>> to reproduce AMBER results, but there is no certainty if they actually
>>> do this now and 'correct' mdp settings to run them are unknown. For any
>>> of the versions that are listed in GROMACS.
>>> Is that correct, or I'm missing something in translation?
>>>
>>> 16.02.2016 18:03, gromacs.org_gmx-users-request at maillist.sys.kth.se пишет:
>>> > Message: 2
>>> > Date: Tue, 16 Feb 2016 11:23:06 +0000
>>> > From: Mark Abraham<mark.j.abraham at gmail.com>
>>> > To:gmx-users at gromacs.org,gromacs.org_gmx-users at maillist.sys.kth.se
>>> > Subject: Re: [gmx-users] gromacs.org_gmx-users Digest, Vol 142, Issue
>>> >       76
>>> > Message-ID:
>>> >       <
>>> CAMNuMASUTdHR8sOt1qt4XdCzOgsDJSfGo8umiUhrpffxXfAagg at mail.gmail.com>
>>> > Content-Type: text/plain; charset=UTF-8
>>> >
>>> > Hi,
>>> >
>>> > The ports of all the AMBER force fields were all tested to reproduce
>>> AMBER
>>> > when when they were added to GROMACS. Many of our regressiontests use
>>> those
>>> > force fields, so there is reason to expect that they all continue to
>>> work.
>>> > The Verlet scheme is tested to implement what the documentation says it
>>> > does. There have been bugs introduced (and fixed) in how GROMACS
>>> > preprocessing tools implement the requirements of AMBER force fields,
>>> > including ILDN.
>>> >
>>> > To be able to say "this force field is tested to work correctly with this
>>> > cutoff scheme in this version of GROMACS" requires the community to agree
>>> > on what that means, e.g. a large collection of single-point
>>> energies+forces
>>> > agree to within a certain precision, and simulations done in a particular
>>> > model physics produce these ensembles with these observables, etc. That
>>> > hasn't happened yet. As far as I know, the ability of the different AMBER
>>> > code versions to correctly continue to implement all the AMBER force
>>> fields
>>> > has a similar kind of question mark over it. Just having the same name is
>>> > not enough;-)
>>> >
>>> > Mark
>>> >
>>> > On Tue, Feb 16, 2016 at 11:17 AM Timofey Tyugashev<
>>> tyugashev at niboch.nsc.ru>
>>> > wrote:
>>> >
>>> >> >So, are there any other Amber force fields more suitable and more
>>> tested
>>> >> >for GROMACS?
>>> >> >
>>> >> >15.02.2016 21:00,gromacs.org_gmx-users-request at maillist.sys.kth.se
>>> ?????:
>>> >>> > >Message: 1
>>> >>> > >Date: Mon, 15 Feb 2016 13:15:02 +0000
>>> >>> > >From: Mark Abraham<mark.j.abraham at gmail.com>
>>> >>> > >To:gmx-users at gromacs.org,gromacs.org_gmx-users at maillist.sys.kth.se
>>> >>> > >Subject: Re: [gmx-users] correct rlist and Verlet scheme
>>> >>> > >Message-ID:
>>> >>> > >       <
>>> >> >CAMNuMATMbmGvbfJ49ez+4K_BftDmkyFYiw5iZ-EECwiCUJBLuQ at mail.gmail.com>
>>> >>> > >Content-Type: text/plain; charset=UTF-8
>>> >>> > >
>>> >>> > >Hi,
>>> >>> > >
>>> >>> > >On Mon, Feb 15, 2016 at 12:17 PM Timofey Tyugashev<
>>> >> >tyugashev at niboch.nsc.ru>
>>> >>> > >wrote:
>>> >>> > >
>>> >>>>> > >> >I've studied the relevant sections of the manual, but I don't
>>> consider
>>> >>>>> > >> >myself to be familiar enough with this field to successfully
>>> guess the
>>> >>>>> > >> >right settings.
>>> >>>>> > >> >
>>> >>>>> > >> >ff99sb-ildn is included in the gromacs distribution, so
>>> shouldn?t be
>>> >>>>> > >> >there some recommended settings for it?
>>> >>> > >Ideally, yes. But nobody has made a particular effort for that
>>> >> >combination.
>>> >>> > >
>>> >>> > >Or else how was it tested to run
>>> >>>>> > >> >properly?
>>> >>>>> > >> >
>>> >>> > >In principle, one would have to e.g. show that
>>> >>> > >https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2970904/   can be
>>> >> >replicated.
>>> >>> > >That's not a straightforward proposition...
>>> >> >--
>>> >> >Gromacs Users mailing list
>>> >> >
>>> >> >* Please search the archive at
>>> >> >http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List  before
>>> >> >posting!
>>> >> >
>>> >> >* Can't post? Readhttp://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 togmx-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.