Atomtype Cu2+ not found

GROMACS version: 5.2
GROMACS modification: Yes/No
I have a problem; I built a simulation box with a slab of graphene in the middle of the box, filled with water on one side and saline (NaCl) on other side. I have checked the executable files (.gro, .itp, topol , …) several times and they are correct , but I give this error : atomtype Cu2+ not found.
Does anyone have any experience to share with me?

Dear maryam,
gromacs is not able to recognize the atom types. You have to give the atom type information .first step is to check in atomtype.atp file whether your atom type is there or not. Another way is , you have to include the atom type in your ffnonbonded.itp file according to your forcefield.

Thanks for your advice.
You know there isn’t any Cu+2 in the box (graphene, water, and salt water solution), but I give the error about it.

Its the file:

; Include forcefield parameters
#include <p.oplsaa.ff/forcefield.itp>
#include <graphene.itp>

;Include water topology
#include “oplsaa.ff/spce.itp”

;Include ions topology
#include “oplsaa.ff/ions.itp”

[ system ]

[ molecules ]
SOL 50572
NA 634
CL 634

I understood that your system does not have any Cu2+. In this case, the error may be due to one of the atoms/residues in the gro file labelled as Cu2. If it is the case, that is misleading, you have to change the name/label is something more unique.
Best regards

It appears you’re mixing and matching different force field file locations. What is the source of p.oplsaa.ff and what force field files does it call within it? This is the most likely source of error, that the force field specifies Cu2+ as a valid atom type but this is not part of the standard OPLS-AA distribution. The error does not originate from your coordinate or topology files, but from the force field itself.

From the post I understood that did not have any copper (Cu2+) in the system, that was the reason why I have assumed that there may be some problems in the coordination file.
Best regards

The error is about an atom type, information that is not in a coordinate file. It’s a problem parsing the force field, which I think is likely to be due to mixing different sources of force fields, standard and non-standard. We need more information from about how the files have been prepared.

In order not to make wrong changes in the opls force field of gromacs program, I took a copy of it it and changed its name (p.oplsaa.ff).