2020-10-21 System + Toolkit Infrastructure chat

Owned by Matt Thompson, created
Oct 21, 2020
3 min read

Date

Oct 21, 2020

Participants

  • @Matt Thompson

  • @Jeffrey Wagner

Notes

Matt's question about torsions (was in the middle of typing up in Slack):

I have a niche implementation question about torsion interpolation for those are currently exploring it: is there a sense of how often torsions are interpolated vs. extrapolated? Extrapolation is definitely within the spec but may present an issue with matrix representations. Say you have k for bond orders 1 and 2 and the handler is presented two bonds with orders 1.3 and 0.9. Linear interpolation can “interpolate” out to 0.9, or to values above 2 no problem (save for the naming of the method, I guess). But this may not work for matrix representations: the case of 1.3 can be written as a linear combination (0.3 of one k value, 0.7 of the other) but I’m not sure how to cleanly represent the cases less than 1 and greater than 2. There may be a linear algebra trick I’m unaware of, but this would either need to be disallowed in the spec (bad idea) or hacked around in the matrix representation (less bad but aslo undesirable).

basically, this is solved by allowing negative and >1 values in the matrix. the math works out for a back-of-the-envelope example (k1, k2 = 100, 200; 200 * 1.3 + 100 * -0.3 = 230)

Scattered System + Toolkit design discussion:

Starting from this issue: Decouple typing from system generation · Issue #748 · openforcefield/openff-toolkit

  • General: Probably a good idea, unclear which route is best, leaning (1) for now. May run into an issue of data without its context if the slots-smirks mapping is detached from the handler and the particular topology used to generate it

On the need for meta-handlers:

  • There needs to be an ElectrostaticsHandler that acts as a meta-handler, i.e. containing several smaller handlers that can modify charges

  • There may need to be a vdWHandler that also acts as a meta-handler, i.e. separately doing atoms and virtual sites with their own "sub"-handler

  • Q: Should we allow arbitrarily meta handlers, recursively allowing the same glass to gobble up things of the same type

    • A: Ideally no, this adds complexity that might be tricky. But a NonBondedHandler that contains vdWHandler and ElectrostaticsHandler could be a counter-example, if its existence is justified (scientific question)

  • General: should meta handlers have allowed sets of handlers they're allowed to own (registry pattern) or the opposite, in which handlers know what meta handlers they're allowed to be a part of?

    • A: Registry pattern is pretty good in its current use. But probably need to wait until implementation to decide.

  • Meta handlers probably look at a lot different than PotentialHandlers.

    • MT: Only makes sense to have have slots at the lowest level (a PotentialHandler), not the meta handler level. For each handler, include logic about how slots and parameters interact.

    • JW: Will stew on a different idea in which you can go up and down in a hierarchy and see different slots with different views

  • General: recursive handlers are fine for ParameterHandlers, unclear if they're good/useful/feasible for PotentialHandlers

  • each PotentialHandler will look super different in practical terms of its data, but need to enforce some common basics, i.e. methods for getting parameter sources

Pre-/Post-topology discussion:

  • remains an open question if a Post-Topology is useful

  • Probably need to hammer out a lot of details to inform this

  • basically doing what would ForceField.modify_topology would do

    • assign partial bond orders

    • assign/verify aromaticity model

    • assign partial charges (run all electrostatics-related handlers)

    • add virtual sites

    • assign atom types (in an alternate universe that support Amber-style atom-typing)

  • these pieces of information are each double-listed between the system and topology

  • .modify topology() would act on and return a Topology (no new class), and provide a single location where all this happens

Immediate things to figure out:

  • should slot maps live in the toolkit or system? in ParameterHandlers or PotentialHandlers? MT will continue working down this path - (1) in linked issue, both as an implementation process and for information gathering