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
{{ message }}
Repository navigation
Parlsey 1.2.0 fails on HMR simulations with propyne-containing molecules #19
Christopher Bayly 11:09
We have just uncovered a really bad symptom with Parsley 1.2 when running MD on a molecule containing a a propyne substituent on a phenyl, as in c1ccccc1C#CC. The symptom is that the MD blows up and returns a NaN, but it only happens when Hydrogen Mass Repartitionlng (HMR) is turned on. We looked into it and the 4 fs timestep with HMR is the cause: the methyl bond with the triple-bond carbon hits a resonant frequency and ultimately explodes causing the NaN. This should not happen and I think I can see why: I think the force constants for the C#C triple bond and the attached methyl C-CH3 do not make sense. For the latter (single bond), bond type b24 has a super-high force constant 1.2977e+03 that you would expect for a triple bond, not a single bond. Conversely the triple bond with bond type b27 has a weak force constant 8.23e+02 that you would expect for a single bond not a triple bond. You can check this against the other "single bond" and "double/triple bond" force constants in the same section of the offxml. The smoking gun is that when we use GAFF2 which has more-or-less expected k's (high for the triple bond, regular low for the single), there is no issue with MD using HMR. (edited)
We will modify 1.2.0 by hand to assign b24’s k to 800, b27’s k to 1000 → Rename to b24-MANand b27-MAN → test against propyne containing molecule (jax 15 beta-secretase case from DH) → Release 1.2.1
OpenMM presumably. Unsure about integrator. @cbayly13 indicated that the error happens reliably and quickly, but is unable to share code since it's internal. I'm working on a reproducing case and will upload that once I have it.
# Create an openforcefield Molecule object from SMILES fromopenforcefield.topologyimportMoleculemolecule=Molecule.from_smiles('c1ccccc1C#CC')
# Define the keyword arguments to feed to ForceField; use heavy hydrogens and constrained X-H bonds # (Note that this differs a bit from allowing SMIRNOFF to control masses and cosntraints) fromsimtkimportopenmm, unitfromsimtk.openmmimportappforcefield_kwargs= { 'constraints' : app.HBonds, 'rigidWater' : True, 'removeCMMotion' : False, 'hydrogenMass' : 4*unit.amu }
# Initialize a SystemGenerator using GAFF fromopenmmforcefields.generatorsimportSystemGeneratorsystem_generator=SystemGenerator(small_molecule_forcefield='openff-1.2.0', forcefield_kwargs=forcefield_kwargs, molecules=molecule)
# Create an OpenMM System from an Open Force Field toolkit Topology object system=system_generator.create_system(molecule.to_topology().to_openmm())
# Run a simulation temperature=300*unit.kelvincollision_rate=1.0/unit.picosecondstimestep=4.0*unit.femtoseconds# Use BAOAB integrator=openmm.LangevinMiddleIntegrator(temperature, collision_rate, timestep)
context=openmm.Context(system, integrator)
molecule.generate_conformers()
context.setPositions(molecule.conformers[0])
# Integrate niterations=1000nsteps_per_iteration=250foriterationinrange(niterations):
integrator.step(nsteps_per_iteration)
state=context.getState(getEnergy=True)
print(f'{state.getTime()/unit.picoseconds:12.3f} ps : potential {state.getPotentialEnergy()/unit.kilocalories_per_mole:16.3f} kcal/mol')
That said, I'm not certain this isn't an OpenMM specific numerical instability with angles near pi, or torsions when any one angle nears pi. I'm pretty sure we are still not using the numerically stable expressions derived by Bill Swope for these terms, which may be needed.
Here's the code to make both normal and unconstrained openff-1.2.1, reproduce the error, and show that it affects the expected force fields.
Making the new FF files
from openforcefield.typing.engines.smirnoff import ForceField
ff = ForceField('openff-1.2.0.offxml')
bh = ff.get_parameter_handler('Bonds')
for param in bh.parameters:
if param.id == "b24":
param.k = 800. * unit.kilocalorie_per_mole / (unit.angstrom ** 2)
print(param)
if param.id == "b27":
param.k = 1000. * unit.kilocalorie_per_mole / (unit.angstrom ** 2)
print(param)
ff.to_file('openff-1.2.1.offxml')
<BondType with smirks: [#6X2:1]-[#6X4:2] length: 1.465575905254 A k: 800.0 kcal/(A**2 mol) id: b24 >
<BondType with smirks: [#6X2:1]#[#6X2:2] length: 1.218049770442 A k: 1000.0 kcal/(A**2 mol) id: b27 >
from openforcefield.typing.engines.smirnoff import ForceField
ff = ForceField('openff_unconstrained-1.2.0.offxml')
bh = ff.get_parameter_handler('Bonds')
for param in bh.parameters:
if param.id == "b24":
param.k = 800. * unit.kilocalorie_per_mole / (unit.angstrom ** 2)
print(param)
if param.id == "b27":
param.k = 1000. * unit.kilocalorie_per_mole / (unit.angstrom ** 2)
print(param)
ff.to_file('openff_unconstrained-1.2.1.offxml')
<BondType with smirks: [#6X2:1]-[#6X4:2] length: 1.465575905254 A k: 800.0 kcal/(A**2 mol) id: b24 >
<BondType with smirks: [#6X2:1]#[#6X2:2] length: 1.218049770442 A k: 1000.0 kcal/(A**2 mol) id: b27 >
Reproducing the error for 1.2.0, and showing it doesn't affect 1.0.0, 1.1.0, and 1.2.1
# Create an openforcefield Molecule object from SMILES
from openforcefield.topology import Molecule
molecule = Molecule.from_smiles('c1ccccc1C#CC')
# Define the keyword arguments to feed to ForceField; use heavy hydrogens and constrained X-H bonds
# (Note that this differs a bit from allowing SMIRNOFF to control masses and cosntraints)
from simtk import openmm, unit
from simtk.openmm import app
forcefield_kwargs = { 'constraints' : app.HBonds, 'rigidWater' : True, 'removeCMMotion' : False, 'hydrogenMass' : 4*unit.amu }
# Initialize a SystemGenerator using GAFF
from openmmforcefields.generators import SystemGenerator
for ff_name in ('openff-1.2.0', 'openff-1.1.0', 'openff-1.0.0', 'openff-1.2.1'):
print()
print()
print(ff_name)
system_generator = SystemGenerator(small_molecule_forcefield=ff_name, forcefield_kwargs=forcefield_kwargs, molecules=molecule)
# Create an OpenMM System from an Open Force Field toolkit Topology object
system = system_generator.create_system(molecule.to_topology().to_openmm())
# Run a simulation
temperature = 300 * unit.kelvin
collision_rate = 1.0 / unit.picoseconds
timestep = 4.0 * unit.femtoseconds
# Use BAOAB
integrator = openmm.LangevinIntegrator(temperature, collision_rate, timestep)
context = openmm.Context(system, integrator)
molecule.generate_conformers()
context.setPositions(molecule.conformers[0])
# Integrate
niterations = 10
nsteps_per_iteration = 250
for iteration in range(niterations):
integrator.step(nsteps_per_iteration)
state = context.getState(getEnergy=True)
print(f'{state.getTime()/unit.picoseconds:12.3f} ps : potential {state.getPotentialEnergy()/unit.kilocalories_per_mole:16.3f} kcal/mol')
openff-1.2.0
1.000 ps : potential 43.568 kcal/mol
2.000 ps : potential nan kcal/mol
3.000 ps : potential nan kcal/mol
4.000 ps : potential nan kcal/mol
5.000 ps : potential nan kcal/mol
6.000 ps : potential nan kcal/mol
7.000 ps : potential nan kcal/mol
8.000 ps : potential nan kcal/mol
9.000 ps : potential nan kcal/mol
10.000 ps : potential nan kcal/mol
We are deviating from the meeting notes above: They say to rename the modified parameters to b24-MAN, but @trevorgokey points out (and I agree) that this is confusing, and even b24-manual is inconvenient, because it makes this force field incomparable (by parameter labeling studies) to others in the Parsley line.
We will leave a manual comment in the OFFXML files explaining the change.
Verified with @davidlmobley -- This is expected, and only the constrained version of the new FF should be used with HMR.
Jeffrey Wagner 15:38
@John Chodera @dmobley @cbayly I've made the proposed changes to create a 1.2.1 release candidate. The normal version of this FF openff-1.2.1 successfully simulates the propyne system. However, openff_unconstrained-1.2.1 still sometimes explodes.
I'm unfamiliar with HMR. Is HMR always run with hbond constraints? If not, the changes in the new unconstrained FF are not adequate to fix the propyne issue.
David Mobley 15:39
That should be what we’re after! The unconstrained FF is not for MD.
15:40
When running MD without constraints on HBonds, one needs a smaller timestep. HMR does nothing to fix this. It simply makes it so that you can get by with an EVEN LARGER timestep than normal when running with HBond constraints.
Activity
jchodera commentedon Sep 4, 2020
Do we know if this happens in both OpenMM and gromacs, or just OpenMM? Also, which integrator was used?
j-wags commentedon Sep 4, 2020
OpenMM presumably. Unsure about integrator. @cbayly13 indicated that the error happens reliably and quickly, but is unable to share code since it's internal. I'm working on a reproducing case and will upload that once I have it.
j-wags commentedon Sep 4, 2020
@jchodera Do you have a code snippet using OpenMM+HMR? DIgging through docs now but having an example would save me some time.
jchodera commentedon Sep 4, 2020
Sure!
output with
openff-1.2.0:with
openff-1.0.0:jchodera commentedon Sep 4, 2020
That said, I'm not certain this isn't an OpenMM specific numerical instability with angles near
pi, or torsions when any one angle nearspi. I'm pretty sure we are still not using the numerically stable expressions derived by Bill Swope for these terms, which may be needed.j-wags commentedon Sep 9, 2020
Thanks @jchodera!
Here's the code to make both normal and unconstrained
openff-1.2.1, reproduce the error, and show that it affects the expected force fields.Making the new FF files
Reproducing the error for 1.2.0, and showing it doesn't affect 1.0.0, 1.1.0, and 1.2.1
j-wags commentedon Sep 9, 2020
We are deviating from the meeting notes above: They say to rename the modified parameters to
b24-MAN, but @trevorgokey points out (and I agree) that this is confusing, and evenb24-manualis inconvenient, because it makes this force field incomparable (by parameter labeling studies) to others in the Parsley line.We will leave a manual comment in the OFFXML files explaining the change.
j-wags commentedon Sep 9, 2020
Ah, testing this with the UNCONSTRAINED candidate FF still shows the explosion. Is this acceptable, or should we look at other solutions?
j-wags commentedon Sep 9, 2020
Verified with @davidlmobley -- This is expected, and only the constrained version of the new FF should be used with HMR.