...
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.
2020_09_16 meeting notes
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
To Dos
MS will prepare initial contact pitch for Vanderbilt
MT and JW will work on preparing System object prototype.
MT will make System object into a weekly meeting – Will send out a whenisgood.