rdkit / rdkit

The official sources for the RDKit library
BSD 3-Clause "New" or "Revised" License
2.65k stars 882 forks source link

Changes to Gasteiger charge parameters to improve agreement with other "popular" implementations? #5869

Open bradakta opened 1 year ago

bradakta commented 1 year ago

Is your feature request related to a problem? Please describe. Gasteiger charges sometimes do not agree between rdkit, AmberTools/antechamber, and OpenBabel. The importance of this is debatable, but the difference seems to stem from additional parameters for aromatic nitrogens that differentiate them from non-aromatic sp2 nitrogens. I cannot verify where these come from, as neither of the other programs have additional citations beyond the original papers (which clearly lack these parameters) -- my best guess is that they were derived from a more contemporary table of ionization potentials and electron affinities.

Describe the solution you'd like My hope is that adding the additional identification of aromatic nitrogens and then assigning them the new a, b, c parameters 12.32, 11.20, 1.34 (as opposed to 12.87, 11.15, 0.85) would improve agreement within tolerance.

Describe alternatives you've considered I'm more adept at AmberTools development and can confirm that removing the additional parameters from AmberTools/antechamber does indeed produce much better agreement for pyridine containing compounds.

Additional context I only dug through the OpenBabel source code and did not actually check calculations with that code. They also store a slightly different table of parameters (I think IP and EA?), so that was a bit of speculative sleuthing.

greglandrum commented 1 year ago

I'd be willing to go with a version of the code which allows a different parameter set to be used, but I am very reluctant to move away from having the published parameters available.

bradakta commented 1 year ago

That's very fair considering that nobody I spoke with has any idea where these parameters came from. Although I did not ask the OpenBabel folks (not even sure who is still active there).

I can take a look at the routine and see if I can manage the change, although this is low on my priority list now that the discrepancy source has been solved.

github-actions[bot] commented 2 weeks ago

This issue was marked as stale because it has been open for 90 days with no activity.