WARNING :Overriding atomtypes

User discussions
1

GROMACS version: 2018.1
GROMACS modification: No

Hello I am currently working on Protein stabilization in ionic liquids. However, I have encountered an error during “gmx grompp” for adding ions. I simulate my protein in amber99SB-ILDN force field and my ionic liquid cation and anion were parameterized in amber force field as well.

I used gmx insert-molecules to include the cations and anions. However, when I use the command gmx grompp for ions.mdp, there was an error showing the following:

GROMACS: gmx grompp, version 2018.1
Executable: /usr/bin/gmx
Data prefix: /usr
Working dir: /mnt/c/Users/User/Desktop/protein_IL/ionic liquid
Command line:
gmx grompp -f ions.mdp -c protein_sol.gro -p topol.top -o ions.tpr

NOTE 1 [file ions.mdp]:
With Verlet lists the optimal nstlist is >= 10, with GPUs >= 20. Note
that with the Verlet scheme, nstlist has no effect on the accuracy of
your simulation.

Setting the LD random seed to 1594047435

WARNING 1 [file Anion_atomtypes.itp, line 3]:
Overriding atomtype c3

WARNING 2 [file Anion_atomtypes.itp, line 4]:
Overriding atomtype h1

May I know what is the issue causing this warning?

Thank you very much.

2

Hi Raymond,

It’s quite literally doing what it’s saying :-)

The atom types “C3” and “H1” are part of the default amber force field, and defined there.

Then you are including your file anion_atomtypes.itp, in which you define new atom types with the same name (on the lines specified). These will override the previously defined atom types.

Now, if those parameters are identical to the ones in the default amber force field the result will of course be identical, but otherwise you are changing the parameters for all C3 and H1 atom types (in which case you need to decide whether that’s something you want or not).

Cheers,

Erik

3

Hi Erik,

So does it mean I have to change all the parameter for the C3 and H1 atom types?

To explain my issue further, I am separating the atom types directive from the main anion topology so that I could avoid the “invalid order for directive atomtype” error. I have included the “.itp” file at the top of the “topol.top” as shown below:

; Command line:
; gmx pdb2gmx -f CALB.pdb -o calb.gro -water tip3p
; Force field was read from the standard GROMACS share directory.
;

; Include forcefield parameters
#include “amber99sb-ildn.ff/forcefield.itp”

; Include Cation atomtypes topology
#include “Cation_atomtypes.itp”
; Include Anion atomtypes topology
#include “Anion_atomtypes.itp”

; Include Cation topology
#include “Cation_GMX.itp”
; Include Anion topology
#include “Anion_GMX.itp”

[ moleculetype ]
; Name nrexcl
Protein_chain_A 3

[ atoms ]
; nr type resnr residue atom cgnr charge mass typeB chargeB massB
; residue 1 LEU rtp NLEU q +1.0
1 N3 1 LEU N 1 0.101 14.01 ; qtot 0.101
2 H 1 LEU H1 2 0.2148 1.008 ; qtot 0.3158
3 H 1 LEU H2 3 0.2148 1.008 ; qtot 0.5306

Based on the topology file and suggestion that you provided, does it mean that I only include the “Cation_atomtypes.itp” and delete the “Anion_atomtypes.itp” to prevent the repetition of the same name? Since the “Cation_atomtypes.itp” contain the parameter for the C3 and H1?

Sincerely,
Raymond

4

  1. If the two files contain the same parameters, just include one of them.

  2. If the actual parameters for the actual identical atom types are identical, but the files both contain several other parameters you need, then you can ignore the warning, since you are just overwriting numbers with identical numbers. But, for the record, it’s important to check they really are identical before relying on that…

  3. If they are different and you know what version you want to use, make sure that version comes last, and then ignore the warning.

  4. If they are different, but you want to use both versions (say, one set for the protein and another for the ligand), then you need to alter the atomtype names for one set of parameters and refer to the altered names e.g. for your ligand.

5

Dear Erik,

Alright, I will give a try on it too see if it works.

Thank you very much Erik and thank you for your time and the suggestions.

Sincerely,
Raymond

6

It’s a shame you never mentioned you’re using ACPYPE. If you had so, I would have seen this before.

You should have use:

  -g, --disambiguate    disambiguate lower and uppercase atomtypes in GMX top file

But I’m about to make this behaviour default in ACPYPE (which I’ll rectify ASAP).

Quick story:

  • Before GMX 4.5, gromacs was not making difference between atomtypes upper x lower case, so e.g. CA and ca were treated the same way and Lindahl’s explanations tell you the rest. So, at that time, -g option was appending a ca as ca_.
  • Nowadays, fortunately, GMX atomtypes are case sensitive but I haven’t made -g default.
  • Note that in Amber parlance, uppercase atomtypes mean they come for AMBERFF while lowercase mean they come from GAFF/GAFF2.