We stumbled upon a peculiar rounding error when trying to generate the topology for chlorophyll a molecule. The forcefield lists (in CLA.rtp) the charge for MG atom as “1.140797“, but pdb2gmx generates the topology file with the charge “1.1408“ at this atom, while preserving the 6-digit precision for all other atoms. The resulting topology is attached:
This produces +3e-6 nonzero charge of the molecule (unreported by pdb2gmx, but visible from manual summation of the charges) and, eventually, to non-integer charge value of the full photosystem I.
To replicate the issue, the input pdb file and all forcefield parameters are provided in the following GDrive folder:
There is no mentions of “1.1408“ charges anywhere in ff files. Why pdb2gmx changes this particular value while leaving all other charges (with the same 6-digit precision) intact?
This description is technically wrong. While 1.140797 is getting rounded to 1.1408, the charge of HMB1 atom in the same molecule (0.069103), for example, is printed by pdb2gmx as exactly the same, with full 6-digit precision. I have no idea how these two cases are different for “%g” C formatting.
Indeed. I found out now how %g works. It’s very confusing. There the number after the dot specifies the total number of decimals, whereas with %f it is the number of decimals after the decimal point.
Ooh, I think I get it finally. %10g without explicit precision truncates the number to six significant digits, and it doesn’t count leading zeros. So “1.140797” is truncated to “1.14080“, but “0.069103“ and all other charges starting with 0 get the full 6-digit precision.