2020-07-24 System + VS Meeting Notes

Owned by Matt Thompson
Jul 25, 2020
3 min read

Date

Jul 24, 2020

Participants

  • @Matt Thompson

  • @Jeffrey Wagner

  • @Trevor Gokey

Agenda

  • Are VS particles to be included in the OFFTK Topology?

    • If yes, this breaks the nature of a FF not modifying a top

    • If no, they must be stored as particles elsewhere

  • Store particle positions at end of positions array?

  • Bonded exceptions for vdW and Electrostatics will need to be considered separately

    • Not necessarily foreign to toolkit (so long as things like scale12=0 are carried through) but could be tricky

    • Currently assigning scale12, scale13, etc. values by a graph search - VS particles will break this?

  • Generally, what's about OpenMM's implementation is good, and what would you like changed?

Are VS particles to be included in the OFFTK Topology?

Yes, TG did this (out of necessity)
Pandora's box has pretty much already been opened already with ForceField.create_openmm_system(off_topology, return_topology=True)
JW: Will probably need to re-think OFF Topology in general at some point (there are some old API points in Molecule/Topology that muddy water)
General issue: can define VS either on molecule or in force field - this kinda breaks the rules of a clean picture of FF/Top interacting

  • i.e. you can set a bond parameter on a bond in a Molecule, but this doesn't really fit the picture

  • however, you can this with VS, which make it tricky

do particles go in a topology? kinda, if you think about it like a PDB file, but no, not really, if it's a cheminformatics representation

carry two matrices (?) one for topology particles and one for physics particles (atoms + VS atoms)

JW: Suggests thinking about "topology virtual sites" and "system virtual sites" as different things

  • Topology virtual site is

  • System virtual site is

Implies parameter handler needs to create matrix of parameters (already does) but also, for VS, taking that matrix and how to get the "independent variable"

Valence terms generally scale as N (even though number of valence slots is unlikely to be equal to number of valence slots!)

VS may be similar, but simply ruining the 1:1 matching from atoms to VS

Would it be a problem if, somehow, the vdw will sometimes need to produce an output dimension N_VS > N_atoms? Probably yes, requiring some elaborate exceptions for the intramolecular exceptions. A VS needing to know the positions of other atoms should not fundamentaly be an issue. Should be fine in vdW world.

JW: Another unique thing about VS is that normally there is a clean ff <-> system parameter matching for most terms, but not VS. A VS takes in an angle (part of its FF definition) that specifies its position in the system. Suspects this transformation data will need to be stored in the instructions for how the matrix is generated. This makes VS a little different than other terms. But also puts VS in a different position than other things with respect to how FFs are optimized - instead of only need to expose k and length, you also need to expose a part of the algorithm. This would break the "well, most of the stuff we can pre-compute!" that works, i.e. you only need to calculate reference bond lengths once, then you can run your optimization to find the parameters. Would require some more matrix math, but think it can be handled by doing more matrix stuff in the handler.

TG: VS slots can be defined by things other than atom indices, i.e. (0, 1) atoms could have DivalentLonePair and MonovalentLonePair. Should be processed before system, probably by adding the "type" of VS in the smirks map key, i.e. (0, 1, DivalentLonePair). JW points out that, if the VS handler simply provides the geometric transformation and ships that off, the slots don't really matter, and different VS can be assigned to a given tuple of atoms.

Store particle positions at end of positions array?

In-memory representation probably can do whatever you want. If we care about serialization (we probably do!) then we can hopefully let pydantic handle it and just let the dictionaries handle it. May need special consideration for people who want to visualize things, but in general let exporters handle that, do in-memory stuff how we want. Would actually probably best to not explicitly carry VS positions along the way, just re-compute them on the fly as needed. Otherwise, would be redundant data.

Generally, what's about OpenMM's implementation is good, and what would you like changed?

TG: OpenMM worked well, good API. Consider taking inpsiration from what OpenMM has already done.

Action items:

  • Put geometric transform logic into VSHandler.to_openff_system type of function (consider adding it to some spec)

  • Need logic to produce the exception mask for VS (would also go in VSHandler). Would need to provide enough information so as to avoid name collisions in slots, so name things with unique tuples