Project

General

Profile

Bug #1207

Terminal hack blocks do not seem to affect atom mass

Added by Wouter Boomsma over 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Berk Hess
Category:
preprocessing (pdb2gmx,grompp)
Target version:
5.0
Affected version - extra info:
Affected version:
4.6.6
Difficulty:
uncategorized
Close

Description

In aminoacids.n.tdb and aminoacids.c.tdb type files
it seems that when specifying a rule like this:

[ NH3+ ]
[ replace ]
N N NH3 14.0027 -0.3
CA CA CT1 12.011 0.21
HA HA HB 1.008 0.10
[ Add ]
3 4 H N CA C
HC 1.008 0.33 -1
[ delete ]
HN

The mass specification - for instance the 14.0027, is not
used in the generation of the topology file, in contrast to
the charge value. It is not completely clear that this is
really a bug, but it is surprising behaviour that masses
in the hack blocks are ignored.

Code wise, the responsible lines are in the pdb2top.c file,
in the name2type function:

at->atom[i].type = restp[resind].atom[j].type;
            at->atom[i].q    = restp[resind].atom[j].q;
            at->atom[i].m    = get_atomtype_massA(restp[resind].atom[j].type,
                                                  atype);

At this point in the code restp[resind].atom[j].m actually
contains the modified mass, but this is not copied to the
"at" object, which is later written to the topology file.

checkmass.py (845 Bytes) checkmass.py Roland Schulz, 06/15/2014 04:57 AM

Associated revisions

Revision 3c968b11 (diff)
Added by Erik Lindahl over 4 years ago

Make sure masses are copied from termini databases

Masses should always be copied from termini databases,
where they are mandatory since they are specified before
the charge, rather than picking them from atomtypes.atp.
This patch also adjusts a few of the default CHARMM27
charges in atomtypes.atp that deviated in the 3rd decimal.

Fixes #1207.

Change-Id: I6f0c87989ae285ff435cd56c64432988c6634824

History

#1 Updated by Roland Schulz over 4 years ago

I think this is a bug. The manual says that this column is the new mass. But it isn't sufficient to change the code. This means that the build in force-fields are read different and we need to make sure that this doesn't introduce new bugs. I created a python script (attached) to compare the mass given in atomtypes.atp and in the hackblock (*.tdb). The script needs to be executed from the FF folder. For charmm I get:

NH2 14.0067 14.007
NH3 14.0027 14.007
NP 14.0027 14.007
O 15.9994 15.999
OB 15.9994 15.999
OC 15.9994 15.999
OH1 15.9994 15.999
type OH missing

And comparing it to the original charmm FF files it seems like the tdb is correct and thus this causes (very small) changes from the correct mass in the charmm FF.

#2 Updated by Berk Hess over 4 years ago

I would think the tdb should always be preferred. But that assumes that there are no errors in the tdb entries. We should check all tdb masses before merging a fix. Although this bug doesn't seem to have any significant effects on results for the standard force fields, we should fix this asap.

But that there is a difference seems to indicate that the masses in the atp file are incorrect. I think we should try to get rid of the atp file, since it isn't really used, except for "exotic applications like this, which haven't really been checked.

And we should correct the charmm atp file.

#3 Updated by Erik Lindahl over 4 years ago

  • Target version set to 5.0

#4 Updated by Gerrit Code Review Bot over 4 years ago

Gerrit received a related patchset '1' for Issue #1207.
Uploader: Erik Lindahl ()
Change-Id: I6f0c87989ae285ff435cd56c64432988c6634824
Gerrit URL: https://gerrit.gromacs.org/3645

#5 Updated by Erik Lindahl over 4 years ago

  • Status changed from New to Fix uploaded

#6 Updated by Erik Lindahl over 4 years ago

  • Status changed from Fix uploaded to Resolved
  • % Done changed from 0 to 100

#7 Updated by Erik Lindahl over 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF