09-13-2022 Thompson/Wang Benchmarking Check-in

Participants

  • @Lily Wang

  • @Matt Thompson

  • @Jeffrey Wagner

Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

Design/code discussion

@Matt Thompson

  • MT – Seems like a good idea to have everything be accessed as a TopologyComponent - This will prepare us for possibly using atom-typed molecules or other things in the future.

  • LW – Was thinking about “swappable components” as plugin.

  • LW – Confused about the distinction between TopologyComponent and TopologyProvider

    • MT – For vaccuum stuff, it doesn’t really make a difference. But we need to keep the door open for more complex systems. So for example we could have a protein TopologyComponent.

    • MT – One big advantage of handling things this way is that we can load stuff into TopologyComponents, then do filtering as we like, and only at the end do we go through the work of assigning parameters. That is, we won’t need to wrestle with OFFMol requirements too early, especially if a filter would reject them BECAUSE they couldn’t become an OFFMol.

  • LW – Use of the word “identifier”?

    • MT – SB used to use “type”, which seemed confusing. Also touches on questions of versioning.

    • JW – This touches on an interesting problem with serialization where, if I can serailize a container that has multiple types of things in it, it’s hard to figure out how to deserialize them if we don’t have a record of what went in.

    • LW – I wonder what happens if we overload the type map (in the current state of the example uses the identifier “openff” twice)

      • MT – My mistake - I should have made those unique.

  • LW – Purpose of allowed_components?

    • MT – This is where this block would communicate which inputs are allowed.

  • LW – to_json should return more than just self.molecule.to_json, right, since it needs to describe what kind of container it is itself

 

  • JW – TopologyComponent <--> Molecule/SimpleMolecule? Should SimpleMolecule be an OpenFF-native OpenMM Chain? If that’s all we need, maybe we don’t need an openff-native class here.

  • JW – Do we need PDBFile TopologyProvider? The only thing I ever do with a PDBFile object is GetTopology. Though I guess it may help to have the entire PDBFile object stored, since then there are a few more guarantees about roundtrippability.

  •  

Unresolved issues from last week

@Lily Wang

  • LW – I’m still not sure whether we want to support stuff like GAFF via openmmforcefields.

    • MT – Same here. It has an uncertain cost and I don’t have a ton of experience around this. But it clearly has a benefit. So it’d be nice to hedge for the future in some way by keeping the door open.

    • JW – I’m still not sure what is required to “do GAFF” - if it’s just “put an OFFMol in openmmforcefields and ask for GAFF”, then the above workflow’s support for OFFMols should pretty much handle it. And if it needs atom typed molecules… then the OpenMM topology support should handle it.

    • MT – Maybe best to keep pseudocoding components and see how it looks

    •  

  • We won’t decide whether GAFF is in spec this week.



Action items

@Matt Thompson will work on fleshing out more pseudocode:
More detailed examples of the OpenMM TopologyComponent/ TopologyProvider layer
Some “modular component” objects for force fields
One for OpenFF/SMIRNOFF force fields
Another for <whatever objects are to be plucked out of openmmforcefields
Some sort of “modular component” for how a topology and force field become a parametrized system
Possibly two, i.e. parallel workflows for OpenFF and OpenMM code paths

Decisions