SMIRNOFF: Support charge increments about openff-interchange HOT 4 CLOSED

Having read into some more of the details, this is a little tricky. A custom set of BBCs (using a ChargeIncrementModelHandler) conflicts somewhat with using the default AM1BCC, but this is undocumented in the SMIRNOFF spec.

Electrostatics in general are tricky, and this case is complicated by the fact that it's a mix of "take it or leave it" data from (AM1 or similar methods) and force field parameters (BCCs). The AM1 charges need to be stored at some point, but the BCCs need to be exposed as differentiable objects.

This is probably the time to make electrostatics in general parsed better; the current approach muddies everything up and prevent BCCs or library charges from being exposed as tunable.

There also needs to be some structure for handling metadata (cutoffs, methods, 1-4 scaling factors, etc.) and dispatching the partial charge assignment methods, ideally in a way that is not too specific to SMIRNOFF.

from openff-interchange.

I think re-applying BCCs is a use case we value, and we probably want to avoid re-calculating AM1 charges. I'll try caching the AM1 charges so that BCCs can be quickly re-applied.

from openff-interchange.

I supposed it's possible that the AM1/AM1-Mulliken call here could be executed by a single function that can also cache AM1BCC values for the <ToolkitAM1BCC> tag ... both could involve similar toolkit calls and caching of results.

from openff-interchange.

Implemented

from openff-interchange.