2020-09-16 Interoperability notes

60 min?

@Michael Shirts

• Discuss what we want to do along the aims of the proposal for molecular interoperability, who will do it, and how it will align with Vanderbilt/GMSO

Separating internal representation from interoperability

@Matt Thompson

• MT: hard to decouple internal representation from interoperability; easy for a question to drift from one bin to the other

  • e.g. have this openmm layer, goes into ParmEd’s internal representation, then goes from there

• JC: we want an internal representation that is very FF-centric, as opposed to e.g. ParmEd being very AMBER-centric

  • interoperability can then be something that follows from the FF-centric internal representation

  • there are some political things we can do to drive adoption as well

  • having this component for handling a parameterized system can be used directly by folks in MolSSI, for example (have some immediate users)

System Object MVP

2020-09-15 Meeting notes

Cannibalizing interoperability that InterMol already supports

• LAMMPS/AMBER/GROMACS/DESMOND writers

• Infrastructure for energy comparisons between different engines

Design considerations for downstream FE users/libraries

• The idea is that we want a base class that can do some sort of vanilla MD, and then a derived class will be built on top of that by free energy scientists/developers

Any other follow-up from Bayly/Chodera video chat

Recording here: https://openforcefieldgroup.slack.com/archives/C8NE3J96U/p1600196037022400

Summary of Matt’s notes

• Need to design a "simple, here's your MD starting point" approach that doesn't itself to FE, but can enable FE infra to be built on top of

• CB would like to be able to splice out a part of a System and stitch it into other tools

• Be generally concerned with scope creep, particularly for data that cannot be optimized/compressed.

More here: 2020-09-15 System/Interoperability notes