Cmap potentials in GROMACS 2019 and after

GROMACS version: 5.1.4, 2019, 2020.7, 2021, 2022
GROMACS modification: No

Hello everyone,

I’d like to simulate polylactide using the PLAFF3 force field that contains cmap potentials. I can execute the grompp routine and start simulations with old GROMACS versions, e.g., 5.1.4 and 2019. However, starting from the version of 2020 I obtain the following :

ERROR 1 [file PLAFF3.itp, line 305]:
Unknown atometype C_2

The line 305 is the exact place where the first group of atoms is described in [ cmaptypes ]:
[ cmaptypes ]
; CMAP potential for lactyl unit from PLAFF3
C_2 OS CT C_2 OS 1 36 36 \
8.7134 9.5761 10.4451 11.8312 13.5710 15.5286 17.5743 19.4594\
20.9676 21.6616 21.2127 19.5809 17.2102 14.3267 11.1645 8.2648\
6.0222 4.6832 4.3376 5.0783 6.8393 9.3640 12.2601 15.0876\

I could not find any info on changes in the treatment/reading of the cmaptypes section across different GROMACS versions.

Can I use the new GROMACS versions for my simulations? What could be the reason for this error?

Thank you,
Artem

The error tells you that C_2 is not a defined atom type in the force field. You need to add it (and its parameters) to ffnonbonded.itp.

Hello Justin,
Thank you for your response. The point is that C_2 is defined. This error occurs only in the [ cmaptypes ] section (not in [ bondtypes ], [ angletypes ] etc), and only with new Gromacs versions. I do not understand why it occurs.

Is it a capitalization issue, e.g. c_2 vs. C_2?

No, that is not it. I can specify any atom from [ atomtypes ] and get the same error.

I would be happy to share all the input files to make it easier to find the problem. I think something has changed in the new versions of Gromacs.

That’s probably the only way to figure out what’s going on. A minimal test case that reproduces the problem is the best thing to put together.

Hello Justin! Thank you so much for your time. Here is a link to the test files provided by the PLAFF3 developers in their paper:

I will admit that I cannot explain the version dependence of this error, but the problem is that (for whatever reason), CMAP needs to use the nonbonded types (for you, opls_*) not the translated bonded atom types. This likely has to do with some kind of topology mapping that is specific to CMAP, but that solves the issue. Replace the bonded types with the nonbonded types in the [cmaptypes] entries and grompp stops complaining.

This is a fairly unobvious solution, and it has worked! Thanks a lot for your help and time!