2020-09-16 Interoperability notes

Date

Sep 16, 2020

Participants

  • @Matt Thompson

  • @Michael Shirts

  • @Jeffrey Wagner

  • @David Dotson

  • @John Chodera

Goals

  •  

Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

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

 

 

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:

Action items

Decisions

Most of the notes actually ended up here: Â