The current implementation of AM1CCCHandler does the following: "apply AM1, then apply BCCs that mostly clone the BCCs in OE impl." This will only recover the behavior of AM1BCC if the clone is an exact match. It is currently not an exact match: although the recharge project is very close, it does contain some gaps relative to the original publication (such as the element phosphorus) and some large mismatches from the OE current implementation of AM1BCC (e.g. on sulfones).
Continuing in the direction of https://github.com/proteneer/timemachine/pull/571, this PR proposes the logic: "apply AM1BCC, then apply arbitrary BCCs." This would (1) guarantee that we match the behavior of OE's current implementation of AM1BCC when the parameters are zeros, and (2) allow us to remove the assertion error that is now raised when mols contain phosphorus.
In detail:
Adds a function compute_or_load_am1bcc_charges, refactors to avoid duplication between compute_or_load_am1bcc_charges and compute_or_load_am1_charges
Defines a handler PerturbedAM1BCCHandler that applies adjustable BCCs on top of AM1BCC. (By construction, this exactly corresponds to AM1BCC when the params are zeros, bypassing the need to https://github.com/proteneer/timemachine/issues/353 .)
Refactors AM1CCCHandler into a special case of PerturbedAM1BCCHandler
Renames previous implementation of AM1CCCHandler to _AM1CCCHandler_legacy_impl -- TODO: should this just be removed? or should it be retained as-is, and keep the proposed logic in a separate class
Improve safety of caching mechanism in compute_or_load_bond_smirks_matches
Adds test
By default, I lean toward this style of implementation: compose [trusted_starting_point(x), small_adjustment(x, theta)], rather than reimplementation_of_trusted_starting_point(x, theta). If we choose a different starting point in the future (such as an ML charge model), this would decouple our choice of starting point from our choice of how to learn any small adjustments to it.
The current implementation of
AM1CCCHandler
does the following: "apply AM1, then apply BCCs that mostly clone the BCCs in OE impl." This will only recover the behavior of AM1BCC if the clone is an exact match. It is currently not an exact match: although the recharge project is very close, it does contain some gaps relative to the original publication (such as the element phosphorus) and some large mismatches from the OE current implementation of AM1BCC (e.g. on sulfones).Continuing in the direction of https://github.com/proteneer/timemachine/pull/571, this PR proposes the logic: "apply AM1BCC, then apply arbitrary BCCs." This would (1) guarantee that we match the behavior of OE's current implementation of AM1BCC when the parameters are zeros, and (2) allow us to remove the assertion error that is now raised when mols contain phosphorus.
In detail:
compute_or_load_am1bcc_charges
, refactors to avoid duplication betweencompute_or_load_am1bcc_charges
andcompute_or_load_am1_charges
PerturbedAM1BCCHandler
that applies adjustable BCCs on top of AM1BCC. (By construction, this exactly corresponds to AM1BCC when the params are zeros, bypassing the need to https://github.com/proteneer/timemachine/issues/353 .)AM1CCCHandler
into a special case ofPerturbedAM1BCCHandler
AM1CCCHandler
to_AM1CCCHandler_legacy_impl
-- TODO: should this just be removed? or should it be retained as-is, and keep the proposed logic in a separate classcompute_or_load_bond_smirks_matches
By default, I lean toward this style of implementation: compose
[trusted_starting_point(x), small_adjustment(x, theta)]
, rather thanreimplementation_of_trusted_starting_point(x, theta)
. If we choose a different starting point in the future (such as an ML charge model), this would decouple our choice of starting point from our choice of how to learn any small adjustments to it.