Discrepancy in atom types assigned by OpenFF and AmberTools

[sbkashif]

Overview

There is an issue that is blocking PR #36 merge , and a workaround is currently under progress at https://github.com/sbkashif/polymerizeit/issues/29

Issue details

For a typical polymerization reaction to work with existing PolymerizeIt infrastructure, atom types must be assigned in a certain way to be able to make similar atoms with similar tags. More specifically, there should be enough distinction between dissimilar atoms. For example, in a trimesoyl chloride (TMC) molecule, AmberTools assigns different atom types for carbon in aromatic (ca) and carboxylic (co) groups. However, @tramp037 's proposed merge with MuPT currently depends on using OpenFF Interchange to generate initial gro and top files from SMILES strings, where _merge_atom_types utility assigns the same atom type (C1) to both the said carbons because they have same non-bonded parameters (consistent with OpenFF philosophy). While assigned same atom types, bonded parameters are still different for ca-ca and co-co bonds. It later creates incorrect unified ff_bonded.itp file (in a PolymerezeIt! utility) which relies on mapping atom indices to atom types to create [bondtypes] section. Thus, it creates two entries for C1-C1 with different k0 and x0 values as both ca and co are assigned C1 atom type.

Possible solution

We are woking on a solution to allow invoking AmberTools for GAFF parameterization. Currently, the workflow from MuPT representation to PolymerizeIt-Ready files has OpenFF the sole option for parameterizing initial monomers and repeat units. Please follow the issue thread in PolymerizeIt repo for details. We will mark the PR #36 ready for review once this issue is sorted.

[timbernat]

Should this be a MuPT Issue, since the blocker is coming from openff-toolkit/ambertools? What changes within MuPT (if any) would help to unblock this?

assigns the same atom type to both the said carbons because they have same non-bonded parameters (consistent with OpenFF philosophy)

Yes, this is a feature and not a bug in OpenFFt, since atom types are not meaningful in this context as the SMIRNOFF spec lays out; they're added post-facto as a compatibility measure with tools which require them

[mrshirts]

Just to clarify, if you NEED to have atom types, or use a specific force field, we will probably need to parameterize via GMSO/Foyer. The SMIRNOFF spec uses chemical neighborhood typing, not atom-based typing, which has a lot of advantages but is not compatible with atom-typing. GMSO/Foyer, which we will incorporate soon into an AA workflow, does use atom typing. OPLSaa is in, I don't know if gaff/gaff2 will be. See https://github.com/mosdef-hub/foyer/tree/main/foyer/forcefields/xml.

OpenFF can output atom types, but defaults to atom type for each atom in a molecule.

[mrshirts]

Opening a new issue specifically on GAFF/GAFF2 for Foyer, in #54