Versions Compared

Old Version 3

changes.mady.by.user Karmen Condic-Jurkic

Saved on

compared with

New Version Current

changes.mady.by.user Karmen Condic-Jurkic

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants

Goals

  • Matt needs to learn how ForceBalance does its internal vectorization

  • Update Trevor/Jeff on current status of vectorization methods from System object

  • Discuss if/how virtual sites prevent special cases for parameter vectorization

  • Determine how to support Trevor’s needs for fitting experiments (with virtual sites)?

  • Determine if parameter handler vectorization methods should be added to the toolkit

Discussion topics

Item

Notes

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?



Action items

  •  

Decisions