Open jchodera opened 1 year ago
@peastman : Is there a way we could permit openmm.app.ForceField.registerAtomType()
to allow multiple registrations of the same atom type provided the definitions are identical?
The alternative would require substantial editing of the ParmEd data structures, or even worse, the ffxml
files, to de-duplicate entries based on what has already been registered.
Another possibility would be to completely change the way we handle GAFF and use LEaP to generate an OpenMM System
, and then use convert_system_to_ffxml
so that each molecule receives a completely distinct set of atom types, rather than sharing the common gaff*.xml
atom types. This would be a major change in behavior that we'd have to test extensively, but in case prmchk2
ever generates conflicting new types in the frcmod
file it generates for different molecules loaded into the same ForceField
object, this might be the most future-proof approach.
That seems reasonable. We just need to verify that the class, element, and mass are all identical.
With https://github.com/openmm/openmm/pull/4531 patched into my local setup, I have this package's tests passing (so far) with AmberTools 23 installed
I don't know a good way to run this package's tests here against development builds of OpenMM - I patched $CONDA_PREFIX/lib/python3.11/site-packages/openmm/app/forcefield.py
and refuse to let that propagate out past my machine
Is that PR finished? I've been ignoring it since you have it marked as a draft. Once it's ready we can merge it and get it into the next release.
Actually, I see it's a brand new PR. I was just confused. :) Let me know when it's ready for review.
I think it's ready as-is - I marked it as a draft only because I wasn't sure if I was going to break CI or not.
The CI runs (in the main repo) are coming in green so far, so I'd be happy to take feedback there (or here) on what to do next (add tests? test here? etc.)
The update from
ambertools
22 to 23 appears to cause the tests to fail:This appears to be due to a new
gaff2.dat
that is distributed with this release (and possibly earlier?) that includes new types:The
parmchk2
tool now generates parameters for this version, it appears.For example, for the
bace
testsystemCAT-13d
ligand withgaff-2.11
,ambertools=22
generates thefrcmod
file:Now, with
ambertools=23
, thefrcmod
file is different:It appears that the second time a molecule generates the
c5
parameter, OpenMMForceField
complains that we are trying to load in a newc5
type.There are a few problems to be solved here:
parmchk*
generates parameters for the desiredgaff.dat
, not just the latestgaff.dat
frcmod
files generate new atom types to be loaded (as long as those atom types are identical)Issue 1 is especially puzzling since we feed
parmchk2
the same GAFF parameter file we are using via the-p gaff.dat
argument. I suspect the code forparmchk2
has changed.