2020-09-16 System interoperability/Vanderbilt cooperation Meeting notes

Date

Sep 16, 2020

Attendees

• @Jeffrey Wagner

• @Matt Thompson

• @Michael Shirts

• @John Chodera

• @David Dotson

• JC

  • Interoperability – can provide readers/writers in different languages

  • Pure Python, fully-informed object, which can be converted (perhaps lossily) to other formats

• JC – Can’t have converters before API is settled

  • MS – Not necessarily, will depend on timeline with Vanderbilt.

  • JC – Will depend on incentives. Can make sure we have a increasingly useful product at the end of each step. But also make sure we don’t accumulate technical debt.

• MS – Generally, we want a System object that is complete and extensible. We should be able to import it both via API and from existing file formats. MT, how much of this overlaps with GMSO progress/efforts

  • MT – GMSO aims to solve similar problems. Underlying infrastructure is fairly irreconcilable. MBuild → Foyer → GMSO workflow is basically irreconcilable, since foyer output doesn’t keep track of parameter identity.

  • JW – Could a “cauterized” topology be functional? Like, if loaded from a OMM system or foyer output, could we lose track of the parameter provenance but still have some functionality available?

  • JC – A rich System object may be able to handle certain cases of missing information in a systematic way.

  • MS – How can we make the Vanderbilt work overlap somewhat with us?

  • JW – If GMSO simply doesn’t have data fields for important info in their object model, then any use of their converters will be destined to fail

  • MS – It may still have some value, even with a lossy converter

• MS – Let’s re-focus on finding areas of overlap in effort between us and Vanderbilt

  • MS – This funding will help us avoid “sunk cost fallacy”, will also give us the opportunity to idenitfy places the objects aren’t isomorphic and identify whether this is intentional or simply oversights.

  • MS – What are likely fundamental incompatibilities?

    • MT – Foyer has nothing that SMIRNOFF doesn’t. Main thing they have is a body of work in data files, like OPLS in XML format. It will be hard but possible to have them standardize on using more of OpenFF infrastructure.

    • MT – Foyer is basically a thin wrapper around OpenMM. Foyer FF class inherits heavily from OpenMM FF class. Agree that there’s a big “sunk cost” mentality around GMSO adoption. From an outside perspective, I see that it would be beneficial for them to move away from it.

    • JC – Looking at GMSO, I see that most of the output converters are incomplete/ParmEd dependent. If we made a GMSO ← → OFF System converter, then they could take advantage of our converters.

    • MT – It’s worth considering what the objects will look like in 6 months. I think our scope is much broader than GMSO’s.

    • JC – We might use the GMSO → OpenFF system converter as an initial goal, with the final goal of making a mBuild → OFF System output functionality.

    • MT – Agree

    • MS – Who are the relevant stakeholders at Vanderbilt and what will they (organizationally/emotionally/individually) want to pursue?

      • MT – My perspective is that I’m most proud of the design of GMSO, but see that the implementation is still largely incomplete. Currently nobody else has taken hard ownership of it.

      • MS – We can kind of view this as a chance to design a new object with the understanding that MT gained from designing GMSO.

      • MT – Stakeholders are Peter and Claire, Ray, Justin, Koh, Prashra. 6 or 7 other university on MosDeF grant, mostly just a single PI+GS at each. Other institution people are less software-focused. Big difference in the latter group is that nobody uses AMBER or OMM, some use GROMACS. Would need strong support for LAMMPS, HOOMD, CASSANDRA.

      • JC – Some communication with Andrew White of HOOMD, looking at support for ML potentials

      • MT – Those aren’t trivial, but are tractable. Could get support for this and other formats from community. MosDeF grant is up for renewal in 1ish year. Also looking to get a grant in the same category as MolSSI.

      • MT – As we provide more support for more chemical-engineering use cases, we’ll start gathering stakeholders in adjacent fields.

      • MS – So let’s anticipate having a very broad view for our potential scope.

    • MS – Basically everyone wants a replacement for ParmEd. What’s our position on this?

      • MT – I think it’s possible. Our system object will be largely isomorphic to ParmEd’s internal data representation.

      • MT – Initial System goals are to export faithfully to ParmEd, within the same scope as our current OpenMM System → ParmEd route. The next step will be successfuly exporting new features like vsites to ParmEd. (JC: Also CMAPs would be nice). The “gold medal” is a full set of direct converters to other formats.

• Summary: Identify ways to work on the same code as much as possible. Our desired outcome is to get them investing effort in System and its converters.

  • JW – Do we want to move toward full replacement of GMSO with OpenFF system? Like, having mBuild → OFF System directly? And if so, how do we want to present this initially?

  • MS – It’s their choice. We should take the position that “we want a single system object”, and let them reason out the paths forward.

  • (General) – What’s the “carrot” for vanderbilt?

    • MT – “we’ll handle the interoperability, you handle GMSO → system”

    • MS + JC – “We’ll provide a modern ParmEd if you can get to our format”

• Possibility of help from Jason Swails / Entos?

  • Likely we can get limited advisement from Swails

Action items