Issue with coordinates after equilibration

Description I have recently ported over my workflow to use openff.toolkit instead of the old openforcefield module. This is meant to take in a small molecule mol2 file and a receptor pdb file, parameterize them, minimize, equilibrate, and export to Gromacs (gro/top).

The old version (openforcefield) still works just fine, but the new version (openff-toolkit) produces bad coordinate files after equilibration. Both directories can be found in the attached tarball: openff-issue.tar.gz

The resulting topology files look very similar, with seemingly minor changes to the ligand parameters, but the structure file (conf.gro) for the openff-toolkit script seems to explode after equilibration! Note that the ligand name “<0>” is NOT an issue and is present in both cases.

    1<0>     C1    1518214.8142654.199576.66
    1<0>     C2    2-374233.817505.7462426.0
    1<0>     C3    3545191.3-497387.72653.99
    1<0>     C4    4383505.2-211521.144098.6
    1<0>     C5    5-149680.-202533.374189.9
    1<0>     C6    6-577753.-201560.-223641.
    1<0>     C7    7290914.0-12141.3-333546.
    1<0>     C8    8-177329.563956.8-276489.
    1<0>     C9    9294280.5670759.4-407819.

Steps To Reproduce All files needed to re-produce including the requirements.txt for re-creating the exact conda environments used in both cases are included in their respective directories. Only necessary files for running each one are the ligand mol2 file and receptor pdb file, at which point the output files can be generated by running example.py.

Output No error message is shown. The issue is found in the output files after equilibration as noted above.

Computing environment (please complete the following information):

• Operating system: Both examples were run on Ubuntu 20
• Output of running conda list: Environments are found in the requirements.txt files in the attached directories.

[yabmtm]

Nice catch, @j-wags! I actually thought all my scripts used 4amu/4fs, but you’re right. Using hydrogenMass=3amu on the openff-toolkit script produces normal output… But so does using 4amu on the older openforcefield script…

I didn’t realize that hydrogen masses are subtracted from their bonded heavy atom. Is that generally true across MD engines, e.g. Gromacs?

As long as the forces and integration are stable with 3amu/4fs I see no problem using that for our simulations, but it would still nice to be able to use the more widely accepted mass partitioning scheme of hydrogenMass=4 with a 4fs time-step.

[j-wags]

Thanks for the awesome reproducing example, @yabmtm. I was able to reproduce this on my computer. It looks like the problem is that the old script sets a hydrogen mass of 3 amu, while the new one sets a hydrogen mass of 4 amu. Since the hydrogen mass is subtracted from its bonded heavy atom, it looked like the crashes were being caused by a methyl carbon having too much mass subtracted by its three hydrogens, leading to unstable dynamics. I’m able to run the equilibration using the openff-toolkit-produced system with a hydrogen mass of 3 amu instead of 4.

I don’t know what best practices for hydrogen mass repartitioning are, but a 3 amu carbon simulated with a 4 fs timestep seems dangerous. I’m seeing this hydrogenMass=4 used in other repos, though, so maybe this is standard. It’s also possible that the minimization for this system left a bit of a clash behind that exacerbated the problem, and that a more thorough minimization or gentler heating would resolve this.