Charge precision in topology files: parsing behaviour and validation tolerance

User discussions
,
1

GROMACS version: 2020.7
GROMACS modification: No

Hello,

I’m working with a coarse-grained model that uses fractional charges (1/3 to 16 sig. figs.) distributed across polymer chains, with the terminal bead carrying the remainder to ensure integer total charge. My supervisor raised a concern about whether GROMACS reads the full precision of these values or truncates them during topology parsing.

In my .itp files (manually created, not from pdb2gmx), I specify charges with 16 significant figures. The fractional charges are intentional as they represent charge distribution across virtual sites. By design, when summed across a complete molecule, they total to an integer value.

To test GROMACS’ charge validation behaviour, I deliberately created a test system where the charges had 16 significant figures (0.3333333333333333) but the terminal charge was NOT corrected, so the molecular charge should NOT sum to exactly an integer. I ran grompp with GROMACS 2020.7, and surprisingly, grompp gave no warnings or notes about non-integer charge. I expected at minimum a note like “System has non-zero total charge: 0.000xxx”.

This prompted me to investigate the source code. Looking at src/gromacs/gmxpreprocess/topio.cpp, I found a function that appears to explain this behaviour:

double tolAbs = 1e-6;
double tol = std::max(tolAbs, 0.5 * GMX_REAL_EPS * sumAbsQ);

if (std::abs(qTot - std::round(qTot)) < tol)
{
return std::round(qTot);
}
else
{
return qTot;
}

This appears to use a 10^-6 tolerance when checking molecular charges, which would explain why I got no warning.

What I’m trying to understand is: when I specify charges with many decimal places in my topology file, does GROMACS actually keep that precision internally, or does it get truncated at some point? And when this rounding check happens, is it just deciding whether to show a warning, or is it actually changing the charge values used in the simulation?

Thanks for any help,

Luke

2

GROMACS stores charges in single precision when you compile without GMX_DOUBLE and in double precision when you compile with GMX_DOUBLE.

3

Thanks for clarifying the precision issue. I can see that I have compiled with single precision, which answers my question about truncation, but it doesn’t clarify whether those truncated values are then rounded to exact integers for calculations.

To follow up: when a molecular charge is within the 1e-6 tolerance of an integer (e.g., 1.0000003), does GROMACS:

(a) Just suppress the warning but use the actual non-integer value in calculations? or
(b) Round it to the nearest integer for use in calculations?

I am confused as I would expect grompp to warn about non-integer molecular charge, but it didn’t. I need to determine whether my completed simulations are valid or if they need to be rerun.

Thanks,

Luke

4

GROMACS does not (and should not) modify your charges. There is no check for integer charge on molecules. The is a check, producing a note, for non-integer charge of the total system. But we might want to reconsider that now scaled charge force fields are becoming more popular.

5

Thank you, that clarifies things better. I’m still confused about something fundamental. In gmx dump output, these beads show as q=3.33333e-01, confirming the truncation. This should cause my system charge to deviate from an integer since I designed them to balance at full precision. You mentioned there is a check that produces a note for non-integer system charge, but I received no such note from grompp.

Why didn’t I get a note about non-integer system charge?

My understanding is that non-integer system charges in periodic systems require GROMACS to add a uniform neutralizing background charge to prevent divergence in the electrostatic calculations. Did grompp silently add this background charge to compensate for the truncation error? Or is there a tolerance on the system charge check that my truncation error fell within?

I need to determine whether my completed simulations have been running with an unintended background charge correction.

6

When GROMACS is compiled in mixed-precision (default), charge are stored a fixed precision, so 7 decimal places total.