torchmdnet coulomb_cutoff only if periodic

[sef43]

fixes #137

For in-vacuum energy evaluations we do not want to use a coulomb cutoff as it introduces errors from the reaction field approximation it uses.

Probably also for mechanical embedding small molecule mixed systems we also do not want to use the coulomb cutoff. This does not yet address that so is still a draft.

[peastman]

Just checking in on the status of this. We're likely to do a 1.6.1 patch in the near future. It would be great if this fix could be included.

[peastman]

Are you still planning to finish this? We've fixed a couple of other bugs, and I'd like to create a release to get them out. Should I keep waiting for this or do the release now?

[sef43]

Hi @peastman, I have updated the PR with sensible default settings for the coulomb cutoff. It can be controlled by the user regardless and this is explained in the docs. It will close #137

[peastman]

Thanks! I'm confused why you disable the cutoff when using createMixedSystem(). For example, think of a membrane simulation where you model the membrane with ML and the surrounding water with MM. It's still a periodic system, and you still need to apply periodic boundary conditions and the minimum image convention for interactions between membrane atoms. The fact that there's also water you're modelling with MM doesn't have anything to do with it. Can you explain the logic?

[sef43]

Yes good point, it is not always the correct behavior, but it is the best default behavior in the basic MM/ML single small molecule mechanical embedding examples such as in the OpenMM cookbook tutorial: https://openmm.github.io/openmm-cookbook/dev/notebooks/tutorials/machine_learning_potentials.html#Simulating-Mixed-ML/MM-Systems.

As seen in the original issue the in-vacuum energies are noticeably perturbed by the cutoff approximation #137 and thus it should not be used for a small molecule in a mechanical embedding scheme.

The user can override the default behavior however they want and this is explained in the documentation.

[peastman]

That doesn't feel right. We shouldn't make assuptions about what systems people will simulate or how models will work.

You assume that any TorchMD-Net model with a Coulomb term will use reaction field. That may be true of AceFF-2.0, but there's nothing stopping someone from creating a model that uses PME. It's very likely that future models will do that.

Even if we assume reaction field, for any ML region that's more than a single molecule, it's essential to include the PBC with minimum image convention. Otherwise each molecule will only ever see one periodic copy of the others. If a molecule drifts over to the next box, it will stop interacting with anything.

And even if we assume you're just simulating a single molecule in a box of MM water, and assume everything is done with reaction field, there's no reason to omit the cutoff between pairs of ML atoms. They should be screened by the water just like everything else. That's what the MM force field would do.

[sef43]

Yes good points, I have simplified the logic to just apply the periodic cutoff based on the openmm System/Topology's PBC settings.

[peastman]

Thanks! Tests are failing with this change:

>       assert np.isclose(refEnergy[model], energyML, rtol=1e-4)
E       assert np.False_
E        +  where np.False_ = <function isclose at 0x7fc21ed2b930>(-362.46139008480094, -379.7851867675781, rtol=0.0001)
E        +    where <function isclose at 0x7fc21ed2b930> = np.isclose

TestTorchMDNetPotential.py:31: AssertionError

You might need to add useCoulombCutoff=True so it will get the same result as before. Also, should it be use_coulomb_cutoff to match the other TorchMD-Net arguments?

Some of the ANI and AIMNet2 tests are also failing. I'm not sure what's happening with that, but I don't think it's related to this change.

[peastman]

Looks good. I'm not sure what's going on with the ANI and AIMNet2 failures, but I'll investigate them in a separate PR. Is this ready to merge?

[sef43]

Yes it is ready!

p.s. the aimnet2 failures look to come from similar reasons (from Claude):

TestAIMNet2 testPeriodicSystem failure

Symptom

test/TestAIMNet2Potential.py::TestAIMNet2::testPeriodicSystem fails on all platforms:

• reference: -151663232.67 kJ/mol
• computed: -151715123.01 kJ/mol
• Δ ≈ −51,900 kJ/mol (rel. 3.4e-4, outside rtol=1e-5)

Non-periodic (testCreatePureMLSystem) and mixed (testCreateMixedSystem) tests pass.

Cause

Upstream change in aimnetcentral, not openmm-ml.

• openmm-ml test added 2026-02-05 (7534b07, PR Convert AIMNet2 to use PythonForce #113). Reference energy generated against aimnet of that era.
• aimnetcentral commit fe23891 (2026-05-02, in v0.2.0): "Long-range Coulomb via nvalchemiops: DSF, Ewald, PME" replaced the in-tree DSF kernel (ops.coulomb_matrix_dsf) with nvalchemiops.torch.interactions.electrostatics.dsf_coulomb. Default dsf_rc=15.0, dsf_alpha=0.2 unchanged; only the implementation differs.

The periodic path is the only one affected because it triggers Switching to DSF Coulomb for PBC in aimnet/calculators/calculator.py.

Verification

aimnet version	E (kJ/mol)	passes?
v0.1.1 (last pre-refactor)	−151663224.6	✅
v0.2.0	−151715123.0	❌
main (0.2.0.post1.dev1+g5b76c17a4)	−151715123.0	❌

Options

1. Pin aimnet < 0.2 in test requirements.
2. Regenerate the reference with AIMNet2ASE on current aimnet and update TestAIMNet2Potential.py:41.
3. File an upstream issue — ~23 kJ/mol/atom drift on a 2269-atom box from a "same-method" refactor is larger than expected; may indicate a self-energy or unit difference.

[peastman]

Thanks!