Pdb2gmx fatal error: residue naming

User discussions
1

GROMACS version:
GROMACS modification: Yes/No
Here post your question

i use pdb: 5fwk and chose OPLS force field. The pdb2gmx program threw the following error:

Residue 639 named ASP of a molecule in the input file was mapped
to an entry in the topology database, but the atom CA used in
that entry is not found in the input file. Perhaps your atom
and/or residue naming needs to be fixed.

my command:

gmx pdb2gmx -f 5fwk.pdb -o str_processed.gro -water spce -ignh

what am i doing wrong or how can i go about that error?

2

Please search in the forum, it has discussed many times in the forum.

3

Hi @scinikhil

Would you mind pointing to a thread showing a solution to this problem?

I ask because I have asked a similar question to the forum but in my case is about n-terminal acetylation (residue ACE):

Yet, I haven’t got any pointers to a solution. In my experience, with this particuler error, the forum is very useful to understand what the problem is but there are no solutions reported.

I find hard to believe that simple problems like this remain unresolved. As you say, it must have been discussed and solved many times.

Thank you.

Ivan

4

see here

I find hard to believe that simple problems like this remain unresolved. As you say, it must have been discussed and solved many times.

You need to search it in forum or a general google search will redirect you to similar or excact problem. I just spent 10 sec and got the above hit.

5

Hi @scinikhil

If my memory serves me right, that is the top hit that I got doing a search to try to solve this kind of problem.

Could you please do the community, @kj655, and me a favour?

Within that post (that is 17 years old) or any other post:
Could you please specifically point to the solution?
(Not the description of the problem but the solution.)

It seems that knowledgeable scientists over the years have found this atom-naming incompatibility a challenging problem. See for instance this 2021 exchange between @awacha and @jalemkul .

My understanding is that that very conversation lead to a 2023 publication by those two scientists.

The solution proposed in that paper points to a converter on a GitLab page. Unfortunately, the README.md in GitLab says only this:

"
Note: This is work in progress. Do not use this code, not even at your own
risk! The resulting force field is not guaranteed to be correct at all.

On-line documentation: https://awacha.gitlab.io/charmm2gmx
"

In conclusion, for over 17 years people have been reporting this problem. If you could show a documented solution, I and many others would be profoundly grateful to you.

Ivan

6

@kj655 issue is different from what you are having.
You can use charmm-gui pdbreader to add ace cap or you can define a manual entry for ace in your field as per the charmm definition.