Bug #1207
Terminal hack blocks do not seem to affect atom mass
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.
Associated revisions
History
#1 Updated by Roland Schulz about 6 years ago
- File checkmass.py checkmass.py added
- Priority changed from Normal to High
- Affected version set to 4.6.6
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 about 6 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 about 6 years ago
- Target version set to 5.0
#4 Updated by Gerrit Code Review Bot about 6 years ago
Gerrit received a related patchset '1' for Issue #1207.
Uploader: Erik Lindahl (erik@kth.se)
Change-Id: I6f0c87989ae285ff435cd56c64432988c6634824
Gerrit URL: https://gerrit.gromacs.org/3645
#5 Updated by Erik Lindahl about 6 years ago
- Status changed from New to Fix uploaded
#6 Updated by Erik Lindahl about 6 years ago
- Status changed from Fix uploaded to Resolved
- % Done changed from 0 to 100
Applied in changeset 3c968b11df40ce9702669536fefe275d253b25a8.
#7 Updated by Erik Lindahl about 6 years ago
- Status changed from Resolved to Closed
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