2021-01-28 Meeting notes

Foyer + MBuild --> OpenFF System creator

• Could eg. attach biopolymers to metal surfaces

  • Decent win for OpenFF, not much of a win for VU

OpenFFSys <--> GMSO interconverter

• New exporters available if we can convert to GMSO?

  • LAMMPS, HOOMD, CASSANDRA

Full collaboration on shared object

• Given that we’ll end up making, in some capacity, a ParmEd replacement, would full collaboration be a way to bring in developer time from VU?

  • Specifically, going from OpenFF format to make AMBER/CHARMM/GROMACS files

    • (Current plans already assume we’ll make AMBER/OpenMM/GROMACS exporters)

  • Importers will be very expensive, and we should avoid them if possible (or deprioritize them)

  • If OFFSys API is friendly enough, then it’ll be easier for external developers to make their own importers

• Possibility for plugin architecture → provide templates/base classes for adding new format support. This would make it so WE aren’t a blocker if external groups want to

• Split this into two options – One with OpenFF governance, other with shared governance

  • Non-shared-governance route is a lot like “option 3”/”Foyer + MBuild --> OpenFF System creator”, but with a heavier emphasis on a carefully-formed API and plugin architecture.

  • What incentivizes people to “do their part”? What if OpenFF doesn’t offer a good API? What if VU’s OFFSys exporter is buggy/unusable?

    • If VU continued development on GMSO, then issues with openFF system would never block VU work

    • Peter probably wants proteins in GMSO.

    • Is there much value in polymer-on-surface system setup functionality?

      • Could do “protein-on-surface” proof of concept by early summer

• Who owns the final thing?

  • Probably MMOSS, if VU can commit to meaningful contributions

• What possible benefits can come from different options?

  • Products can invite community engagement (beyond VU)

  • Products can make cool proofs-of-concept (like protein-on-surface)

  • We can begin a reasonably good, modular replacement for ParmEd

  • QM/MM support? (OpenFF leadership should figure out if this is on the roadmap)

• Desired outcomes for tomorrow

  • Have VU identify what it is that THEY plan/want.

  • Construct a statement of the form “If VU can export to OFFSys, then you will gain AMBER/GROMACS/OpenMM writers” (would they want more? would we do LAMMPS?)

    • We could make the LAMMPS converter if needed, but we’d expect them to do HOOMD and CASSANDRA if they want those as well

  • Emphasize functional importance of non-blocking solution for both sides

  • Maybe don’t commit to MMOSS, but rather an organization that we’re willing to “harm” in case we “take our ball and go home”

  • MT could do most of these things. What are things that VU can do that MT can’t?

    • MT can offer:

      • Ingesting OPLS file from Foyer, producing organic system (this overlaps with plans to support atom-types topologies)

      • mBuild inputs – Should be possible but topology will require extensive work (several weeks)

    • What does VU want?

      • CP2K integration support

      • VASP/Ab-initio support

      • monolayer support

    • What can VU provide?

      • Developer time to solve “sunk costs” like converting to Pint instead of Unyt

    • Do we want to expand our jurisdiction past MM/ML at all?

    •