Parameter Vectorization Sync-up

ForceBalance vectorization

• ForceBalance normalizes and regularizes ALL parameters into a single, flattened array

• Indices matter - the Nth parameter at one point in an optimization related to the Nth particle later on

• TG – SB calls the output of get_param_matrix the “assignment matrix”.

• TG – I want to be able to say “index 3 is X parameter”. So it’s helpful to have a way to look up the meaning of the rows/columns

• Current System design has the system parameter matrix have # columns = # parameters that are used

• Current OpenFF Recharge design has a more global view - # columns = # parameters in the force field

  • MT – What if columns are traceable back to FF param (by eg smirks pattern)

  • Complication is that multiple vsites in a FF can have the same smirks –

    • May need a custom PotentialKey

    • A single “slot”, typed to have a single “parameter” can be split out into multiple parameters. Already doing something like this with periodic torsions

• End goal is to find a way to deal with flattened representations of virtual sites in Recharge

• TG – Want to have a global design matrix that handles BCCs both from BCCHandler AND virtualsitehandler

• Some problems

  • (solved) System does not offer a way to find VS positions, etc., but Trevor has already implemented this in the toolkit

  • We don’t have any special handling for virtualsites in the System. Do we need any special handling for virtualsites?

    • TG – Will I be able to look up parameters based on a unique identifier?

    • MT – I think so. The PotentialKey should fit for this purpose (basically a string, which is currently a SMIRKS with some optional additional info)

    • TG – Let’s pretend that we have a chargeincrement of variable length, and I need the third one. How do I address that?

    • (General) – We want a way to canonically order the physics values in a FF, so that we can retrieve them by index later.

• Solution:

  • Context

    • It’s OK to do this fitting from dev builds

  • Needs

    • Canonical parameter ordering from FF

      • A parameter ID should remain identical for:

        • The same FF loaded twice (like two different FFs loaded from the same file)

      • Something like ‘VirtualSites/[smirks]-[type]-[name]/chargeincrement1’

      • 

    • VsiteHandler in openff-system?