Make default SMIRNOFF force field openff-2.2.1

[epretti]

Resolves #409.

[mattwthompson]

LGTM!

I did some aggressive searching elsewhere in the repo, please consider each of these suggestions optional (they're mostly out of scope, too, and could be split out into separate issues & PRs if I'm not mistaken on their value):

• A changelog entry, if we're doing that during development (at release time is also fine)
• A look at template_generator_kwargs in the Espaloma code, which says 2.0.0 is used by default. From a glance through the code, I think the documentation is correct, but it could also be updated to 2.2.1.
• The _filter_openff testing utility hard-codes a solution around "openff-2.0.0-rc.1". OpenFF has recently introduced more pre-release force fields, two RCs of 2.3.0 and an alpha of 3.0.0. I would expect this to cause failing tests if the most recent openff-forcefields is installed and all available force fields are iterated through

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.17%. Comparing base (ea248b4) to head (2fa5b68).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #417   +/-   ##
=======================================
  Coverage   84.17%   84.17%           
=======================================
  Files           5        5           
  Lines         771      771           
=======================================
  Hits          649      649           
  Misses        122      122           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[epretti]

A changelog entry, if we're doing that during development (at release time is also fine)

I think we usually update this at release time.

A look at template_generator_kwargs in the Espaloma code, which says 2.0.0 is used by default. From a glance through the code, I think the documentation is correct, but it could also be updated to 2.2.1.

I saw this too; should have asked about it. I didn't update it since it didn't look to be updated last time to 2.1.0 and I wasn't sure if there was an Espaloma-specific reason for this. Do you know what the "unconstrained" force fields are, and if there's a reason the Espaloma generator uses one (openff_unconstrained-2.0.0)? I noticed that the SMIRNOFF generator filters these out.

The _filter_openff testing utility hard-codes a solution around "openff-2.0.0-rc.1". OpenFF has recently introduced more pre-release force fields, two RCs of 2.3.0 and an alpha of 3.0.0. I would expect this to cause failing tests if the most recent openff-forcefields is installed and all available force fields are iterated through

This shouldn't have to do with them being prereleases; it was because 2.0.0rc1 has a bad value (see #330). I see at least one test is installing the 2025.10.1 version of openff-forcefields which should have those new force fields, so they should be getting picked up in the tests that try all of the installed ones.

[mattwthompson]

Do you know what the "unconstrained" force fields are

They're the same but without a parameter that matches all bonds between hydrogens and heavy atoms. It should be functionally analogous to openmm.app.ForceField.createSystem(..., constraints=HBonds)

and if there's a reason the Espaloma generator uses one (openff_unconstrained-2.0.0)?

My guess is it has something to do with Interchange's behavior around constrained bonds; OpenMM doesn't need to know the harmonic bond parameters if the bond is going to be constrained, but Espaloma might. The paper trail on Interchange's behavior starts here and may or may not have changed since the decision to use the unconstrained one with Espaloma. In any case, we should leave it place with Espaloma.

I'm not sure why the unconstrained ones aren't used in the SMIRNOFF template generator. I would have guessed the opposite, since bond information can easily be discarded but can't be written back in if it's not there. I could be wrong (and certainly don't think we should change this now).

2.0.0rc1

Thanks for jogging my memory! I had forgotten about the specific issue with that force field.

[epretti]

OK, I think we can make openff_unconstrained-2.2.1 the default for Espaloma. It looks like that was done here for Espaloma (although the code uses 2.1.1 in some places and 2.2.1 in another, and the corresponding PR mentions 2.1.0 and 2.2.0 also, but I don't see any reason it shouldn't just be consistent).

[epretti]

Tests I'd assume should be unrelated are failing. They're GAFF tests with the molecule [H][c]1[n][c]([Cl])[c]([H])[c]([H])[c]1[C]([H])([H])[N]1/[C](=[N]/[C]#[N])[S][C]([H])([H])[C]1([H])[H]. OpenFF is claiming that No registered toolkits can provide the capability "assign_partial_charges" but it's really just because antechamber's running and then crashing on it. I would think that something is wrong with this molecule, except that this failure is proving impossible for me to reproduce locally.

I'm going to run the test again to see if the failure is reproducible on CI.

[epretti]

The test that was failing before doesn't appear to have failed again. I can't reproduce this locally and it shouldn't be affected by the changes here. We should keep an eye out for it though.

GitHub still won't let me merge this, I think because OpenMM 8.2 was still being tested when the PR was opened?