Pass atom "identifier" to ParmEd
Closed this issue · 2 comments
This is a brief summary of discussions today between @davidlmobley, @leeping, and me in the Slack channel and on the phone.
Summary
When using ParmEd to write out a prmtop file with SMIRNOFF99Frosst parameters, ParmEd will write numeric atom types based on the order of atoms in the OpenMM System. This is probably because the OpenMM System does not have any atom types. This can cause a problem using AMBER tools down the line when the "atom type" field is greater than 2 characters. One way to work around this is to rename the atom types with 2 character strings after being written. An alternative approach is to assign atom types (or identifiers) to the OpenMM System. We could also submit a PR to ParmEd to do this, but it's unclear if we'd want to always rewrite the types when they are missing,00 and writing the random 2 character strings can cause problems (as Lee-Ping mentioned and Niel and I have run into) with certain hard-coded patterns for atom types in AMBER code, that could break for other people.
Workaround
The proximate workaround is to use the "mixed force field" approach. Specifically: use any force field (e.g., GAFF) to completely prepare the system for simulation (including pre-processing with, e.g., tleap), then read in the host and guest to OEMols, read in the coordinates to an OpenMM Topology, split the topology, re-parameterize the host and guest with SMIRNOFF99Frosst, combine the host and guest with the water, ions, and other things, and then write out a combined prmtop and inpcrd. We have done this before (https://github.com/slochower/smirnoff-host-guest/blob/master/02-convert-APR-files.ipynb) so it should not be a problem to prepare each window first and then do the conversion, instead of doing the conversion and then preparing each window using our APR tools.
Follow up
In parallel to the workaround, we will see if we can find a way ("speakeasy") to directly write a frcmod file independently of ParmEd. @nhenriksen and I will report progress on that. We haven't thought through all the complexities, but I think we will (a) assign every atom a unique atom type and then (b) interrogate the parameters in the OpenMM system and write the relevant parameters for each atom in frcmod file. This should get people started using SMIRNOFF99Frosst ligands in simulations.
I somehow missed this discussion back in March (or maybe forgot about it...), but this doesn't sound like an issue that actually belongs in this repo. smirnoff99Frosst is a SMIRNOFF, but the implementation is handled in openforcefield.
Any objection to me closing this issue to avoid confusion since we have a version in openforcefield/openforcefield too?