Page Comparison

Boron support

• PE – Does OpenFF have plans to support boron?

  • JW – Yes, we just asked the advisory board the other day, and two of our supporting compares are interested. I’m not sure whether we’d add parameters just using QM data, or if we’d wait until we also had phys prop data to fit to.

  • PE – I’m wondering how I should handle boron-containing molecules, since I need to generate conformers, and I’m using openff forcefields to do so. But openff forcefields don’t have parameters for boron. So I’d need to use another method if I wanted to generate boron-cotnaining conformers. Also silicon.

  • JW – Gotcha. I don’t think we’ll have boron parameters in the next several months. We don’t have plans to add silicon currently.

  • PE – Ok, no rush, good to know for my dataset generation and future plans.

RC builds

• JW – These are great - MT integrated these into our test suite and already caught a potential problem.

• JW –

• Sigma=0 vs epsilon=0?

  • (General) – The sigma=0 thing is because of a problem with soft-core potentials. That’s not supported by NonbondedForce.

  • PE will remove check for positive sigma, allow negative harmonicbond k

Units package

• JW – We’re probably moving over to priamrily use Pint soonprimarily use Pint soon

  • We’ll support interoperating between both using openff-units

    Github link macro
    link https://github.com/openforcefield/openff-units/blob/main/openff/units/tests/test_openmm.py

• PE – We have an open discussion on adding support for pint. But it’s not a top priority right now. There would be a few stages here - one is just “doing the right thing” when talking with the C++ layer, then increasing to supporting multiplication between quantities from different package.

• MT – This sounds like a fun direction, but I can’t guarantee that I’ll address these in the course of our work – We need to be driven by user needs.

• PE – Good to keep in mind that an unreliable conversion is worse than nothing, so we’ll want to be extra cautious in adopting this in a widespread context.

• MT – At different points in time, people have asked for a “units-only” OpenMM package. My understanding is that it’s at the stage where people say “that would be nice to do”, but nobody’s done it yet

  • PE – Agree with that summary.

Substructure recognition

• JW – We have chemical substructure recognition from PDB working, leveraging OpenMM’s PDBFile class and the Chemical Components Dictionary.

  • PE – There are much faster alternatives to networkx. I think that IGraph/IGraphtools could be much faster.

  • https://graph-tool.skewed.de/performance

  • https://anaconda.org/conda-forge/graph-tool

• JW – Also chemical perception matching is taking a long time, but we need a chemistry-aware package to do this (RDKit or OpenEye)

• PE – User feedback: Parameterizing stuff using OpenFF is really slow. The slow parts were assigning parameters and running a nanosecond of MD.

  • JW – This is all AM1BCC. We may switch to a much faster graph-based charge assignment but we haven’t made a go/no-go decision on it yet, and there are a lot of unknowns about the implementation.

  • PE – It’d be nice to support a much faster charge method for people who don’t need high accuracy

  • JW will show PE how to force the use of gasteiger charges instead of AM1BCC (results below)

from openff.toolkit.typing.engines.smirnoff import ForceField
from openff.toolkit.topology import Molecule
offmol = Molecule.from_smiles('CCCCCCCO')
ff = ForceField('openff-2.0.0.offxml')

%%time
# Using AM1BCC (default, sepecified in FF)
sys1 = ff.create_openmm_system(offmol.to_topology())

nbf = [force for force in sys1.getForces() if "Nonbonded" in str(force)][0]
for i in range(offmol.n_atoms):
    print(nbf.getParticleParameters(i)[0])

from openff.toolkit.typing.engines.smirnoff.parameters import ChargeIncrementModelHandler

ff2 = ForceField('openff-2.0.0.offxml')
#print(ff2.registered_parameter_handlers)
ff2.deregister_parameter_handler('ToolkitAM1BCC')
#print(ff2.registered_parameter_handlers)
cimh = ChargeIncrementModelHandler(version=0.3, partial_charge_method='gasteiger')
ff2.register_parameter_handler(cimh)
print(ff2.registered_parameter_handlers)

%%time
# Using gasteiger charge assignment
sys2 = ff2.create_openmm_system(offmol.to_topology())

nbf = [force for force in sys2.getForces() if "Nonbonded" in str(force)][0]
for i in range(offmol.n_atoms):
    print(nbf.getParticleParameters(i)[0])

QC datasets

• JW – Initial jobs submitted – We’ll watch to see how this goes and whether updates are needed.

• JW – FYI - It’s not clear what the organizational status of this subproject is. I’m ultimately responsible for the success of specific tasks and the paid time of DDotson, MThompson, and JMitchell. These datasets aren’t on my radar.

• PE – This isn’t an OpenFF project, it’s an NIH project under openMM. We’re using this data to support making ML potentials.

• JW – Sounds good. We’re happy to support this, but it may get sidelined for some time if we have to deal with internal blockers.

• PE – How do we get results out when this is done?

  • JW – We record the input chemical structures as “CMILES”. This is because…

  • PE – Will it be possible to keep the original info on the output structures? Like pubchem ID and amino acid sequence?

  • JW – I believe so. This info may have been packed into the QCA metadata for the jobs, otherwise we may need to offer a secondary index to map from QCA job/compound ID back to the original metadata.