AAM – I’ve been assigned to work on an MMSchema, and there’s another project called molecular mechanics interoperability schema. Hopefully in the future will have performant formats like hdf5 compatibility, but right now we’re leaning on JSON.
Goal of MMSchema is to standardize SCHEMAS, not standardize WORKFLOWS.
Each component of MMIC will specify an exact input schema, and output schema. This schema will be defined using MMIC component definition.
Distinction between strategic and tactical components – Strategic is “high level”; “I want to do an energy minimization with some high-level description”. Tactical components CAN be specified by user, but are otherwise automatically selected at runtime by the strategic components.
Background on OpenFF
Our input molecules need to have:
Atoms: Element, formal charge, stereocehmsitry
Bonds: Integer bond order, stereochemistry
Our current output format is OpenMM System
We consider vdw+ES cutoffs to be part of the force field
Hbond constraints are part of the force field
Vitualsites are in a weird area for us – Right now they should be defined in the FF, but in some cases our API allows users to put them on molecules.
There’s friction here when converting an OpenMM Topology+System to a ParmEd structure because we don’t have atom types
In the future we will output to a new object, the “OpenFF System”. This will have less-lossy conversion to other formats
OpenFF works with MoSDef. They have a pipeline for doing OPLS2 typing starting from graphs of elements – (something like “GAFF SMARTS”)→ a graph with atom types assigned --(Parameter dictionary lookup)→ ParmEd structure
Optimization is done using the ForceBalance package
JW – What if an OpenFF System could contain a combination of OpenFF molecules AND prmtop molecules
AAM – This could be handled using subclassing a new specification from a general base class. We’re not aiming to decide which standards may be used, but rather to host a language for how the standards are defined.