A Charge Model API

[j-wags]

@leeping @MSchauperl @jchodera @davidlmobley @dgasmith

I'd like to restart the discussion of semiempirical charge methods, and how we can encode them in the SMIRNOFF spec.

Currently, users have two options to charge their molecules: 1) adding the <ToolkitAM1BCC/> tag in an OFFXML file, which will go run AM1-BCC with either Quacpac or Antechamber/sqm on the backend. 2) importing charges from the reference molecules loaded into the openforcefield toolkit

We do not currently have a complete implementation of the <ChargeIncrementModel> behavior from the SMIRNOFF spec, as it didn't seem like the format laid out there was general enough.

In this Issue, I'd like for us (and anyone else interested in working with our charge model) to start collecting input and moving toward an API for our charge-generating QM methods. This API should be general enough to support our method development for a year or two.

Even if you don't have a complete solution in mind, it would be good to collect requirements or ideas.

As an added dimension, there's a good amount of interest in a graph-based charge model (lacking geometry), so we can think of how that might tie in as well.

[jchodera]

We do not currently have a complete implementation of the behavior from the SMIRNOFF spec, as it didn't seem like the format laid out there was general enough.

The problem isn't that the spec laid out there isn't general enough---it's plenty flexible!---it's that we need more open source tools available to us before we can implement it. We would need:

• An open source deterministic conformer generation code
• An open source code that can do several semi-empirical calculations we may want to investigate, such as AM1 or PM3 that can also support several initial population analysis methods. AM1-BCC uses an AM1 calculation with Mulliken population analysis (the spec erroneously says CM2) prior to applying BCCs

As noted above, we also are interested in graph-based initial charge determination, inspired by

• Rappe and Goddard charge equilibration
• Gilson et al. VCharge
• a graph-based variant of extended Hückel theory, where a nice open source version exists that is being integrated into RDKit but would have to be modified to use graph-derived distances

We may also want to investigate ML based charge assignment methods:

• Riniker
• Popelier
• general neural networks we could optimize alongside other parameters

So it may indeed be best to generalize this into multiple stages:

• Initial charge assignment stage, using semiempirical QM and population analysis or ML
• Bond charge correction stage using BCCs
• Off-atom charge stage, where we move some charge onto off-atom charge sites using something like BCCs, discussed in this issue

We'd also like to support polarizable sites and multipoles in the future, so we want this approach to be modular and remixable if possible.

[davidlmobley]

@j-wags I think I basically agree with John. Right now we need good tools to give us semiempirical charges in the first place. It sounds like MolSSI may be able to help with this some in the not-too-distant future (cc @dgasmith ). .

[j-wags]

I just spoke with @MSchauperl about what he needs from the ChargeIncrementModel tag. We think it would be good to discuss possible solutions to the questions raised in this Issue at the upcoming charge models meeting.

So that Mike can start prototyping his BCC pipeline, I'll open up a development branch of the toolkit with initial support for the <ChargeIncrementModel> tag, which will only support method="AM1", number_of_conformers="1", and partial_charge_method="Mulliken". The user will need to provide their own conformer, since we don't have a way to deterministically generate them. Hopefully, we can gradually iterate this into our full implementation as we discuss the spec at charge model meetings.

[davidlmobley]

That sounds like a great start, @j-wags