Project

General

Profile

Bug #2884

GROMACS can not reproduce properties with the GROMOS force fields

Added by Berk Hess 7 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Affected version - extra info:
any version after 4.0.7
Affected version:
Difficulty:
uncategorized
Close

Description

The GROMOS force fields have been parameterized with a physically incorrect multiple-time-stepping scheme using a twin-range cut-off. When using a single range cut-off (or a physically correct Trotter multiple-time-stepping scheme as introduced in version 4.5), physical properties, such as densities of liquids, can differ from the intended values. Thus GROMACS could no longer reproduce all properties of the GROMOS force fields since the GROMOS scheme was removed in version 4.5 released in 2010.

Note that certain properties or certain molecules might be affected less by this, but we will perform such checks. Therefore a warning will be added in grompp in version 2019.2 when a GROMOS force field from the GROMACS distribution is used. We will consider removing the GROMOS force fields in version 2020 to avoid generation of incorrect results.


Related issues

Related to GROMACS - Bug #1400: Can't reproduce results on DPPC with reaction field under version 4.5.3 compared to 4.0.7Closed12/10/2013

Associated revisions

Revision ecc01b63 (diff)
Added by Berk Hess 7 months ago

Add grompp warning with use of GROMOS FF

Replaced GROMOS-based simulation database entry with similar
OPLS-based one, since our test systems should not trigger warnings
unless that is the intent of the test.

Refs #2884

Change-Id: I55afcf7ea5b423fa27792acebe09ea520b475974

Revision 3c14bc8b (diff)
Added by Berk Hess 3 months ago

Add grompp warning with use of GROMOS FF

Added OPLS-based simulation database entry to replace
the current GROMOS-based one, to avoid simulations triggering
warnings when this is not the intent of the test case.

This commit was cherry-picked from release-2019 and updated for master
branch. The latter makes more widespread use of the GROMOS test setup
that we wish to replace.

Split some PME tests so that we test normal PME with xyz PBC
separately from walls with xy PBC.

Removed unused duplicate files in testing.

Refs #2884

Change-Id: I55afcf7ea5b423fa27792acebe09ea520b475974

History

#1 Updated by Gerrit Code Review Bot 7 months ago

Gerrit received a related patchset '3' for Issue #2884.
Uploader: Mark Abraham ()
Change-Id: gromacs~release-2019~I55afcf7ea5b423fa27792acebe09ea520b475974
Gerrit URL: https://gerrit.gromacs.org/9274

#2 Updated by Berk Hess 7 months ago

  • Status changed from New to In Progress

#3 Updated by Mark Abraham 7 months ago

  • Description updated (diff)

Added Berk's text to the issue description

#4 Updated by Mark Abraham 7 months ago

Berk Hess wrote:

We will consider removing the GROMOS force fields in version 2020 to avoid generation of incorrect results.

As one of several aspects of our long-running general move towards "correct, useful, and performant by default" I am generally on board with this. We should note a general policy in our documentation for force fields (or force field families) that we a) bundle, and b) intend to support. If e.g. CHARMM36 was a very large amount better than CHARMM22 in its GROMACS implementation, then we'd be considering deprecating our support/bundling of it, also.

As with other things we plan to remove, it would be advisable to have a period of deprecation first, to give the community a chance to observe that there are useful subsets of functionality in the GROMACS+GROMOS combination. Are there studies showing the efficacy of GROMACS implementations of GROMOS force fields in a) reproducing the GROMOS implementations (whether in older GROMACS or GROMOS itself), and b) reproducing experiment? I am aware of a few papers observing that the GROMACS did change its implementation (which was noted in the GROMACS release notes and for several years in the GROMACS manual). It's a pity some of the authors of such papers chose to speculate that this was done for performance reasons without consulting the GROMACS developers.

Note that if there is interest in continuing to have a version of the GROMOS scheme implemented using the GROMACS infrastructure, it is likely that the necessary pieces will emerge from the PRACE-funded NB-LIB project. What we do is all free and open-source, so people are welcome to step up and implement the things they way they want for their science!

#5 Updated by Mark Abraham 7 months ago

  • Related to Bug #1400: Can't reproduce results on DPPC with reaction field under version 4.5.3 compared to 4.0.7 added

#6 Updated by Thomas Piggot 4 months ago

Hi,

I have been working on testing and validating different GROMOS-based lipid (CKP and 54A7/53A6L) and protein (54A7) force fields in GROMACS for a while now. In particular I have been looking at the impact of a few different simulation settings on the properties of PC membranes and several different protein systems.

These simulations are on-going but I thought it important to comment on this bug based upon what I've done so far. My current results with several different setups are showing that for the GROMOS 54A7 protein force field, you can perform accurate protein simulations in GROMACS using recommended settings (e.g. with the Verlet cut-off scheme). For the two related lipid force fields, which it is worth noting were both originally tested using GROMACS and not the GROMOS software, the matter is slightly more complicated. The GROMOS-CKP lipids perform fine using the recommended setups in more recent GROMACS versions, as per the proteins. However, and as noted in some of recent published work out there, the 53A6L/54A7 lipid parameters do not. However, I believe that this is not a (current) GROMACS problem, rather an issue with these parameters and the use of sub-optimal simulation settings in their original testing and validation.

However, I should stress here that these above statements are based upon comparing back to some reference simulations performed in GROMACS with the group cut-off scheme, a single-range 1.4 nm cut-off, and atom-based charge groups (with both RF and PME). One of the reasons for using this as a reference setup was to remove any potential issues surrounding the different multiple-time-stepping algorithms. Please correct me if I am wrong, but wasn't the original argument for a twin-range cut-off simply one of speed rather than anything else? In other words, shouldn't the force field behave the same with a single-range cut-off as with the twin-range setup, if things are done appropriately?

As I mentioned, the results I've briefly discussed here are preliminary at the moment but I thought worth sharing. I definitely believe it is important to keep these force fields available within GROMACS.

Cheers

Tom

#7 Updated by Erik Lindahl about 2 months ago

  • Status changed from In Progress to Closed

We have already taken the decision not to support the GROMOS force fields.

The issue with cutoffs is not even up to debate. As we'll show in an upcoming paper, the way GROMACS and other modern MD codes handle the integration is correct in terms of physics and ensembles, whereas the scheme strongly advocated by GROMOS is simply not a physically correct integration, no matter how much work that has been invested in it. We're well aware that might hurt some users who have relied on it for historical reasons, but science can be a cruel mistress, and as a field we can only make progress by ceasing to use algorithms or setups that are not good.

Unfortunately this has been combined with several publications from GROMOS authors trying to blame codes.

GROMACS has long since made the decision our integration should be physically correct. That might indeed mean some results will deviate for force fields that rely on incorrect integration (in the literal sense that the dynamical system will not progress according to any Hamiltonian). To protect users who are not aware of this we also think it's a fair idea to warn when such a force field is used with GROMACS.

We also believe enough in open source and science that we're not going to physically prevent it, but issues with such force fields should be directed to the people still using them.

#8 Updated by Erik Lindahl about 2 months ago

NB: Multiple-time-step integration does indeed work fine when implemented as a proper symplectic trotter factorisation, the way GROMACS and many other codes do it. In practice that means applying the long-range component as an impulse every N steps.

Adding a saved long-range component every time step will not even conserve energy, it is not time-reversible, and the results will be highly dependent both on the time step, long-range impulse interval, and specific cutoffs. Tuning a force field to such a setup effectively means introducing new errors to cover errors in the setup. That might reproduce some properties as long as one sticks to the exact setup, but it is simply not transferable. As a field, we accepted such compromises for a long time because we didn't know better, but today we do.

#9 Updated by Mark Abraham about 2 months ago

Thomas wrote

However, I should stress here that these above statements are based upon comparing back to some reference simulations performed in GROMACS with the group cut-off scheme, a single-range 1.4 nm cut-off, and atom-based charge groups (with both RF and PME). One of the reasons for using this as a reference setup was to remove any potential issues surrounding the different multiple-time-stepping algorithms. Please correct me if I am wrong, but wasn't the original argument for a twin-range cut-off simply one of speed rather than anything else?

The earliest mention of it in the literature only referred to its performance. But that paper was thereafter cited as supporting the "stability" of the scheme, which is true (given the thermostat settings) in the same sense as a patient in a straightjacket feels "secure." :-)

In other words, shouldn't the force field behave the same with a single-range cut-off as with the twin-range setup, if things are done appropriately?

For the reasons Erik just mentioned, the twin-range scheme is in no way equivalent to any single-range scheme. Any usefulness of the parameters in a single-range schemes is welcome but fortuitous.

As I mentioned, the results I've briefly discussed here are preliminary at the moment but I thought worth sharing. I definitely believe it is important to keep these force fields available within GROMACS.

We certainly won't try to stop someone running it, but we might choose to stop distributing it :-)

Also available in: Atom PDF