Incorrect atomtype assignment
Created an attachment (id=570)
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.
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 9 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.
#3 Updated by Berk Hess over 8 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!