GROMACS can not reproduce properties with the GROMOS force fields
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.
#4 Updated by Mark Abraham about 1 month 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!