2020-09-15 Meeting notes

MVP

• Should we think about MVP as “top down” (Starting will full ultimate feature list) or “bottom up” (starting from minimal functionality and going up from there)

  • MT – Top-down would be better

  • (General) would be best for vague areas, like to_parmed, to have logic for detecting when they’re going wrong (like, if we try to translate something unsupported)

• Should try to approach it from “top down” perspective, but focus on building well-thought-out “immortal” portions (like energy and conversion tests) that will make iterations much faster.

• Invest in making infrastructure to answer energy-accuracy/precision questions – This will be used both in test suite and in benchmarks

• Top-down feature list

  • Interoperability

    • Requirements:

      • Gold: Aspirational parmed replacement

      • Silver: to_parmed that can do more than we can currently, and supports all current FF features (so like vsites eventually)

      • Bronze: to_parmed that supports everything our current OMM_system → parmed pathway does and throws errors if it’s doing something it knows it can’t

  • Single point energies

    • Implementation details:

      • Argument: Coordinates

      • Argument: OpenMM or numpy

    • Requirements

      • Gold: numpy/jax ?periodic/PME implementation? ?GBSA?

      • Silver: numpy/jax valence terms + vaccuum NB

      • Bronze: OpenMM

  • ML-friendly API

    • Requirements:

      • Platinum: Documentation and tutorials for using ML frameworks to do something kinda productive with Silver.

      • Gold: Numpy-all-the-way energy evaluation (just a big matrix multiplication that eats coordinates)

      • Silver: Offering customizability for P and Q (rolled vs unrolled torsions, etc)

      • Bronze: Spitting out at least one representation of P and Q

  • Free energy calculation-supporting API

    • Requirements

      • Gold: ?

      • Silver: ?

      • Bronze: Gather requirements for gold and silver. Do a simple FE calculation (like benzene in water to chlorobenzene)

    • Not clear what API points/features are needed here

      • JW and JC met a few weeks ago adjacent to this: 2020-09-01 Wagner/Chodera Meeting notes

      • Would want the ability to contain parameters for known “mutations” (eg. amino acid protomers, ligand modifications)

      • Some understanding of residues (likely handled by Topology)

      • If a small change is made to a System (like H → Cl), then we’d need to store two copies of the entire system. This is wasteful

      • Could we store a SystemDiff, which can be applied to the H system like a patch, to yield the Cl system?

      • May require labeling different parts of a System as mutable or immutable

        • Eg, materials science linkers

      • Would be nice if SystemDiffs constituted a state function

      • Special nonbonded interactions are anticipated to be a particularly tricky case. Not sure how to handle this.

        • Logically-consistent way to handle it is “Upon modification, the desired System should be the same as if this system were recreated from scratch”

        • This will be tricky when loading from system types with different interaction rules (like, no cutoff specified)

        • Could we circumvent some complexity if we never imported from non-SMIRNOFF sources?

      • Could even two SMIRNOFF-created systems be combined? What if they had different cutoffs? Or different valence parameters (like, one was Parsley, and the other was ligand-specific parameters from the bespoke workflow?)

        • Could have each molecule in the System have a mapping back to its FF, so that mutations can be applied on-the-fly.

        • Each molecule could “reject” modifications if the underlying force field can’t support the new topology

        • Could make a SystemCombinerRegistry so that people can subclass ParanoidSystemCombiner into their own dangerous medical procedures.

      • Should Topology be mutable?

        • As much as possible

        • General design points should enable this if possible

        •  

Jurisdiction with existing toolkit objects

MT wants what is effectively a “pre-” and “post-” typing Topology

• “pre-” is a cheminformatics view of a chemical topology

• “post-” is a more MM/free energy view

• would give some clarity to questions like

  • “where to virtual sites go?” (only allowed in a post-, not in a pre-)

    • JW – If charge_from_molecules goes the way I think, then the molecules listed will sneakily be turned into LibraryCharges before parameterization. Maybe the same thing could be applied for API-defined vsites

      • some trickiness here since vsites could be applied non-symettrically to a symmetric molecule (though partial charges could also be the same)

  • “where are residues stored?” (again, only in post-)

    • JW - Could have TopologyHandlers that do things like split residues around peptide/disulfide bonds

  • what’s the periodicity? (pre- tracks a bool is_periodic post- stores the box vectors with units)

  • pre- could store all conformers, post- would only have one position per atom

  • other questions about bond order, partial charge, stereochemistry?

• unclear if this must be a different object/class, different views of the same class, or maybe a single “superclass” that has some API locked down based on its state

• JW – Maybe the central question is: What does it mean for the “post-” fields to be filled out in a “pre” topology?