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.szil...@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.abra...@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 <tyugas...@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-requ...@maillist.sys.kth.se пишет: >>> > Message: 2 >>> > Date: Tue, 16 Feb 2016 11:23:06 +0000 >>> > From: Mark Abraham<mark.j.abra...@gmail.com> >>> > To:gmx-us...@gromacs.org,gromacs.org_gmx-users@maillist.sys.kth.se >>> > Subject: Re: [gmx-users] gromacs.org_gmx-users Digest, Vol 142, Issue >>> > 76 >>> > Message-ID: >>> > < >>> camnumasutdhr8sot1qt4xdczogsdjsfgo8umiuhrpffxxfa...@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< >>> tyugas...@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-requ...@maillist.sys.kth.se >>> ?????: >>> >>> > >Message: 1 >>> >>> > >Date: Mon, 15 Feb 2016 13:15:02 +0000 >>> >>> > >From: Mark Abraham<mark.j.abra...@gmail.com> >>> >>> > >To:gmx-us...@gromacs.org,gromacs.org_gmx-users@maillist.sys.kth.se >>> >>> > >Subject: Re: [gmx-users] correct rlist and Verlet scheme >>> >>> > >Message-ID: >>> >>> > > < >>> >> >camnumatmbmgvbfj49ez+4k_bftdmkyfyiw5iz-eecwicujb...@mail.gmail.com> >>> >>> > >Content-Type: text/plain; charset=UTF-8 >>> >>> > > >>> >>> > >Hi, >>> >>> > > >>> >>> > >On Mon, Feb 15, 2016 at 12:17 PM Timofey Tyugashev< >>> >> >tyugas...@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-requ...@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-requ...@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-requ...@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-requ...@gromacs.org.