Bug #618

Incorrect atomtype assignment

Added by Justin Lemkul almost 10 years ago. Updated over 9 years ago.

preprocessing (pdb2gmx,grompp)
Target version:
Affected version - extra info:
Affected version:


Created an attachment (id=570)
Test case

This was originally reported on the list, but the user has not filed a bug report yet:

I created a test case in the hopes that this gets resolved. It seems to me to be a fairly important problem. The affected version is actually 4.5.3, not 4.5.1, but the version list is not complete. The incorrect atom type is assigned, but can be manipulated by changing the order of the atom types in atomtypes.atp, which seems like a very unstable situation.

I have attached a tarball with my modified force field files and two input .pdb files, along with the output .top files. You will note that the "lone pair" atom types are assigned correctly when they are non-consecutive (test1), but incorrectly assigned when they are the last two atoms (test2). The behavior can also be manipulated by placing the LP atom type first in atomtypes.atp, with varying results depending on the order of the atom types in the file.

files.tgz (32.1 KB) files.tgz Test case Justin Lemkul, 12/08/2010 03:52 AM
files2.tgz (2.5 KB) files2.tgz extensions of test case in files.tgz Sarath Chandra, 12/08/2010 12:40 PM

Associated revisions

Revision f26a2408 (diff)
Added by Berk Hess over 9 years ago

fixed memory error in element setting in pdbio

Atom types without element would cause a NULL pointer to be passed
to sprintf in get_pdb_atomnumber. This could cause the memory of
pdb2gmx to get corrupted and print incorrect atom types and charges.
This would not affect normal pdb files and force fields, since all
atom in there are "real" atoms. This fixes #618


#1 Updated by Sarath Chandra almost 10 years ago

Created an attachment (id=571)
contains test pdb file with topology with work with amber99sb.ff present in files.tgz

The pdb2gmx error of assigning incorrect atomtypes for the pdb files in files.tgz and files2.tgz.
Once a wrong atomtype is assigned to an atom (i) the next atom (i+1) is also assigned wrong atomtype along with mass and charge. Atom i+2, i+3... are assigned properly again until pdb2gmx comes across again the atomtype which initiates the error (in our case LP).

Tests were also done where LP atomtype was replaced with standard amber atomtype HC but the error persisted.

One more thing, pdb2gmx hangs when a blank line is present in the atomtypes.atp at the end of the file.

#2 Updated by Justin Lemkul over 9 years ago

  • Category changed from mdrun to preprocessing (pdb2gmx,grompp)
  • Assignee deleted (Erik Lindahl)
  • Target version changed from 4.5.1 to git master

#3 Updated by Berk Hess over 9 years ago

  • Status changed from New to Closed
  • Assignee set to Berk Hess

This problem is caused by atom types with atomic number 0, which means that the atom
can not be associated with an element. This would cause a NULL string to be passed
to sprintf which caused memory corrupted. I fixed this and your top file is correct now.
Note that you seemed to have mixed up test1 and test2 in your comment.
Note that in your top with correct LP's the O2 was replaced by a BR!


Also available in: Atom PDF