MT/PB Adoption Scoping Meeting

Owned by Matt Thompson, created
Sept 20, 2021
2 min read

Date

Sep 20, 2021

Participants

  • @Matt Thompson

  • @Pavan Behara

Goals

  • Get a better idea of how Pavan/force field scientists use ForceField.create_openmm_system

Discussion topics

Presenter

Notes

Presenter

Notes

PB

Use cases (PB made a couple of slides)

  1. Applying restraints with OpenMM

    1. Should be able to drop-in replace

  2. Fitting with forcebalance itself

    1. Harder to drop-in replace since FB calls out to toolkit’s API

    2. We could make a fork of FB, have PB build against it, do a fit, and compare results

  3. Using OpenFF Evaluator for solvation energies

    1. Evaluator has abstracted a lot of the toolkit calls into its own classes

    2. There’s a ParameterizedSystem class that actually does the create_openmm_system call to create an OpenMM system

    3. Several tests could potentially break, probably integration-tests/default-workflows/run.py would be one of the first to break

Live coding

Working on replacing ForceField.create_openmm_system in some of PB’s fitting scripts.

First attempt: replace with

interchange = Interchange.from_smirnoff( force_field=forcefield, topology=mol.to_topology(), ) system = interchange.to_openmm(combine_nonbonded_forces=True)

This choked on the cutoff handling in to_openmm since the force field wants PME electrostatics, but the topology has no periodicity. This is a bug in the toolkit (matching PME electrostatics with a non-periodic topology is not valid), or at very least it’s a mismatch between the toolkit’s implementation and the SMIRNOFF spec. MT later wrote this up:

So we updated the script to set the box to a large value

top = mol.to_topology() top.box_vectors = [4, 4, 4] * unit.nm interchange = Interchange.from_smirnoff( force_field=forcefield, topology=mol.to_topology(), ) system = interchange.to_openmm(combine_nonbonded_forces=True)

This gets the notebook running, but it was really slow. This makes it hard for PB to do science. The options are

  1. Keep it as is, and single-molecule calculations are slow and a little inaccurate.

  2. Split the non-bonded force into two, one for vdW with a hard cutoff and one for electrostatics with openmm.NonbondedForce.NoCutoff. This would be tricky to implement but should be possible with Interchange. This will cause differences with results generated by the toolkit, though probably small. The differences will be the result of PME errors.

  3. Use a hard cutoff in the electrostatics term. This will not work well with OpenMM, since its implementation of cutoff electrostatics adds a reaction field correction that cannot be disabled, or so it seems.

However, the notebook eventually ran! We did not save the numbers of the “before” results, but PB says the plots look the same by an eye check!

Other engines?

FB interfaces with tinker. Right now PB nor anybody in OpenFF uses it. Might be worth re-evaluating in the future if there are good scientific reasons.

Action items

  • MT will evaluate making a fork of forcebalance that has the drop-in replacement for create_openmm_system

  • MT will look into the same thing for Evaluator.

Decisions

MT won’t set up the fitting notebook locally. Can revisit later if it would be useful, but takes some work to set up.

Will meet again in 2 weeks to test out a forcebalance fork.