You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From version 0.8.1 of the toolkit the sigma parameter is incorrectly calculated as rmin_half / 2 ** (1/6) when it should be computed as 2 * rmin_half / 2 ** (1/6), i.e. it will be off by a factor of two. The reverse is also true when computing rmin_half from sigma.
As, due to the same PR, sigma will now never be None, its value will always be used when creating an OpenMM system. Hence, any force field which defines parameters in terms of rmin_half (all of the OpenFF production force fields) will be incorrectly applied to systems, and the science likely invalid.
I discovered this bug as all of my simulations NaN'd after upgrading to the latest toolkit version so hopefully this should be obvious when it affects users, although users just doing an energy minimisation or a single point evaluation will likely not notice this bug even though it will be present.
To Reproduce
molecule = Molecule.from_smiles("C")
force_field = ForceField("openff-1.2.0.offxml")
system = force_field.create_openmm_system(molecule.to_topology())
with open(f"system-{openforcefield.__version__}.xml", "w") as file:
file.write(XmlSerializer.serialize(system))
Ideally we should look into adding regression tests so that human eyes alone (even if multiple pairs of them) aren't the only defense against bugs like this. Maybe the current benchmarking effort can be made into a small suite of tests that run periodically?
Describe the bug
From version 0.8.1 of the toolkit the
sigma
parameter is incorrectly calculated asrmin_half / 2 ** (1/6)
when it should be computed as2 * rmin_half / 2 ** (1/6)
, i.e. it will be off by a factor of two. The reverse is also true when computingrmin_half
from sigma.This bug was introduced in #750.
As, due to the same PR,
sigma
will now never beNone
, its value will always be used when creating an OpenMM system. Hence, any force field which defines parameters in terms ofrmin_half
(all of the OpenFF production force fields) will be incorrectly applied to systems, and the science likely invalid.I discovered this bug as all of my simulations NaN'd after upgrading to the latest toolkit version so hopefully this should be obvious when it affects users, although users just doing an energy minimisation or a single point evaluation will likely not notice this bug even though it will be present.
To Reproduce
Output
0.8.0:
0.8.1:
Computing environment (please complete the following information):
conda list
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: