Pings for feedback David Mobley Michael Shirts, soliciting general comments Welcoming feedback, specific or along the lines of

• How does this align with our (internal) objectives?

• What should be described more thoroughly/in more detail?

• Is there anything specified here that is pointing down an un-fruitful/headache-filled path?

• Searching for ? should point you to clear decision points I need feedback on

Aims

The object of the OpenFF System is to enable the use of the SMIRNOFF specification in molecular simulation engines with minimal reliance on external converters and third-party libraries. This will enable researchers to implement force fields developed by the Open Force Field Initiative in their simulation workflows (with a few lines of Python code and/or as part of a CLI) as part of parametrized systems that can be sent to molecular simulation engines.

The internal representation is designed to enable evaluations of the potential energy of a configuration of atoms as described by the SMIRNOFF specification. No sole engine is designated as a target to carry out these calculations, preventing limitations arising from such an assumption. Much of the internals of the System class will be constructed on

...

top of existing infrastructure: in particular, the Open Force Field Toolkit already has a mature ForceField class that manages force field parameters and Topology class that describes the cheminformatics molecular topology. These components will be heavily inspectable by the user; allowing, for example, the source of individual force field parameters, tagged with units, to be inspectable from within the parametrized system.

Simple Usage

This snippet demonstrates how an SMIRNOFF force field and molecular topology (ForceField and Topology classes in the OpenFF Toolkit, respectively) can be used to populate an OpenFF System.

from system import System 
from openforcefield.topology import Molecule, Topology
from openforcefield.typing.engines.smirnoff import ForceField


# Load Parsley and populate a dummy topology (ignoring positions for the moment)
openff_forcefield = ForceField('openff-1.1.0.offxml')
openff_topology = Topology.from_molecules(10 * [Molecule.from_smiles('CCO')])

# Construct an OpenFF System with the force field and topology
openff_system = system.System(openff_topology, openff_forcefield)

openff_system.to_file('ethanol.top')
openff_system.to_file('ethanol.gro')

(I know this API is different than ForceField.create_openmm_system.doc(…) but it seems intractable to me for the toolkit to depend on the system object in the same way that it depends on OpenMM since the system will likely contain or construct from the toolkit’s topology and force field. This would, unfortunately, mean that the actual SMARTS-based parametrization maybe would need to be duplicated internally here. I would like to avoid a dependency loop in which they depend on each other.)

Features

Things stored

• Some graph-like representation of the topology

• Complete description of how to compute the potential energy (stored as a ForceField object?)

• Atomic positions

• Box vectors

• Element information

• Other tags for metadata and provenance

...

• Lennard-Jones

• “Lennard-Jones-like” (i.e. 14-7)

• Buckingham (Exp-6)

• Mie

Electrostatics

...

• Partial charges

  • (optional) formal charges

Valence potentials

• Harmonic bonds

• Harmonic angles

• Proper torsions

• Improper torsions

Exceptions

• How to store? InterMol and ParmEd explicitly track Explicitly track non-bonded exceptions (i.e. scaled 1-4 terms interacitons) for all particlesparticle pairs

Constraints

Combining rules

...

• CMAPs

• Urey-Bradleys

Virtual Sites

Polarizability, Dipoles, Multipoles

Serialization

Lossless serialization is provided through exporting a system object to Python dictionaries, from which JSON, messagepack, and other serialization formats are available.

...

Some limited support will exist for converting to objects in other packages. Most conversions No conversion will be lossless, although some edge cases will prevent this from happening reliably. This list but only in edge cases should conversions be prohibitively lossy, and in many cases only a partial view of the object is the target. Some target object may include any of the following:

...

• Single, high-level container object that “contains” everything (System) that contains sufficient data to compute the potential energy

• At a low level, things become Molecule objects

  • Molecule objects may be de-duplicated through some MoleculeType object

• More specific Molecule subclasses can be used to (optionally?) encode physical meaning

  • Protein, Ion, Ligand

• Biopolymers treated with existing conventions (residues and chains)

...

How much cheminformatics data should be stored? Some data (bond orders?) may be lightweight but we don’t want to duplicate efforts that already exist in the toolkit and are not useful for MD engines.

Manipulation of systems

• Combining systems: Systems will be combine-able in a similar manner to the popular ParmEd feature (new_structure = structure1 + structure2)

Interfaces with machine learning libraries

...

• As such, the primary interface will be from the system object to various formats and objects, not the opposite direction. By contrast, reading input files is a desired feature, but is a low priority.

• Important details about how molecular simulations are executed are not in scope. The OpenFF System object will fully describe the structure of the potential energy function energies, but not how to calculate it in the context of a molecular simulation, i.e. propagating a molecular dynamics trajectory. For example, the choices of barostat, timestep, and ensemble are left to the researcher.

• Internal data structures will be remarkably general, but not infinitely so. The primary use cases will be in the domain of computational biophysicsorganic chemistry, specifically implementing the SMIRNOFF format at the molecular scale. A number of scientifically interesting systems will not be supported initially, although efforts will be made to avoiding prohibiting future extensions to do so. Thing includes things like coarse-grained models, multi-body potentials, anisotropic pair potentials, and rigid body.

...

1. How much modification should be allowed? The software is much easier to implement if we force everything to be immutable, but user modifications (changing parameters, coordinates, connectivity, etc.) may be a valuable set of features. There are some options for a middle ground, like allowing mutability at some points but locking things down at certain API calls (i.e. writing out to disk).

   1. (My) general opinion is that some significant world-building should be enabled, but with clear guardrails in place.

2. How to get an MM energy quickly? An internal evaluator would be tricky and do a lot of re-inventing the wheel, writing to disk and calling an an engine has some overhead.

   1. Exporting to and calling OpenMM is probably the path of least resistance, although exporting to other engines may be useful given other constraints. InterMol may be able to play a role here, if needed.

3. Store data (OpenMM’s approach) or store instructions for getting data (just about every other engine out there). Storing just the data is arguably the richest information content, but requires guessing the instructions (or also carrying the instructions along as metadata) for doing most conversions.

   1. Majority currently seems to favor the “instructions” option

4. Should systems be combine-able? This is a nice feature of ParmEd (big_structure = structure1 + structure2) but may be technically tricky to actually implement here. Re-phrased: how valuable a feature would this be? Can probably come back to it later.

   1. Yes!

5. Should a ForceField object be tracked, as distinct from just tracking the parameters? This could enable features like writing a “just the parameters used in this study” OFFXML. There are likely some complexities to deal with, like information loss when actually applying a force field to a system.