-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vdW energy mismatch between Amber and GROMACS/OpenMM #470
Comments
Okay, the problem is that If I turn off the switching function ( (The pseudo-periodic noise is probably just due to float rounding; Amber reports only to something like 0.001 kcal/mol by default.) If use OpenFF's current default ( I'm not sure where the value 8 ends up; nothing happens at 8 A so maybe it'll behave the same if I use 7 or 6. From the Amber22 manual (emphasis mine):
Something is clearly going wrong here. I can't find any mention of an option that adds a potential shift (like For good measure, here's the second plot zoomed out a bit - clearly what's happening is applied the same everywhere below 8 A: import matplotlib.pyplot as plt
import numpy as np
from openff.interchange.drivers import *
from openff.toolkit import *
from openff.interchange._tests import get_test_file_path
ion_ff = ForceField(get_test_file_path("ions.offxml"))
# ion_ff['vdW'].switch_width = Quantity(0.0, "angstrom")
ions = Topology.from_molecules([
Molecule.from_smiles("[#3+1]"),
Molecule.from_smiles("[#17-1]"),
])
ions.box_vectors = Quantity([4, 4, 4] , "nanometer")
out = ion_ff.create_interchange(ions)
fig, (ax1, ax2) = plt.subplots(2)
r = np.linspace(0.3, 1.0, 101)
omm, gmx, amb = list(), list(), list()
for d in r:
out.positions = Quantity(
np.array(
[
[0.0, 0.0, 0.0],
[d, 0.0, 0.0],
]
),
"nanometer",
)
omm.append(get_openmm_energies(out, combine_nonbonded_forces=False).energies['vdW'].m)
gmx.append(get_gromacs_energies(out).energies['vdW'].m)
amb.append(get_amber_energies(out).energies['vdW'].m_as(unit.kilojoule / unit.mol))
ax1.plot(r, omm, 'k-', label='OpenMM')
ax1.plot(r, gmx, 'c.', label='GROMACS')
ax1.plot(r, amb, 'm.-', label='Amber')
ax2.plot(r, np.asarray(omm) - np.asarray(gmx), 'c.', label='OpenMM - GROMACS')
ax2.plot(r, np.asarray(omm) - np.asarray(amb), 'm.', label='OpenMM - Amber')
ax1.set_ylabel(r'$U(r)$')
ax2.set_ylabel(r'$U(r) - U_{OpenMM}(r)$')
ax1.set_xlabel("r, nm")
ax1.legend(loc=0)
ax2.legend(loc=0)
fig.show() Here are the files used under the hood, with and without
|
One bigger picture thing that might be applicable logic to use here - I decided with InterMol that "success" was that all the parameters were translated correctly; if the functional forms were not the same, that wasn't the converter's problem. i.e. if I could get the energies to match with 9 A abrupt cutoffs in both engines, then that was matching. Lack of similar implementation between programs was the program's problem, not mine. |
fswitch is I think short for force-switching, which is not the same multiplying the potential by a scaling function. I don't think there is a way to multiply the potential by a switching function, yes. |
I agree that getting parameters to being written correctly to the data files is a good target; the problem is that OpenFF's force fields use a switching function and there's no better place to try and get that translated that here. People will get different results if the switching function is turned into a hard cutoff. How much? Probably less than other error in most cases, I don't know. Unfortunately it seems the best we can do in this case is document this gap in functionality so that users are aware of what non-bonded settings are included in the force field that can't precisely be used in their workflow. |
Exactly. I would not change it to a hard cutoff, that was just the setting that was implementable in all version of the codes InterMol used, and therefore could be used to show that in THAT mode, the energies were the same. I think using fswitch for AMBER outputs and WARNING the user the change that was made is 100% a great way to go. We can't make simulation engines more cross-compatible. |
Agree on warning users - but my intuition is to default to not using The scope here is internal energy comparisons and an API point that only ever writes out a script to set up a 0-step "simulation." In both cases a warning will be emitted. I expect power users will have their own infrastructure for production runs and aren't as worried about the tail correction, but I do see it as our responsibility to communicate out the settings that are encoded in force field. |
In #914 I have added a warning - until Amber implements this particular type of tail correction, there isn't anything we can do |
The text was updated successfully, but these errors were encountered: