Torsions with 90/270 degree phases are sometimes mis-applied

Dear OpenFF developers,

When we are using this wonderful package, we found there are three propertorsion parameters in the sage offxml file somewhat mysterious:

<Proper smirks="[#16X2,#16X1-1,#16X3+1:1]-[#6X3:2]-[#6X4:3]-[#7X4,#7X3:4]" periodicity1="4" periodicity2="3" periodicity3="2" periodicity4="2" periodicity5="1" phase1="0.0 * degree" phase2="0.0 * degree" phase3="0.0 * degree" phase4="270.0 * degree" phase5="90.0 * degree" id="t25" k1="0.1024566756215 * mole**-1 * kilocalorie" k2="0.1025622546566 * mole**-1 * kilocalorie" k3="-0.7270841288504 * mole**-1 * kilocalorie" k4="0.2720289395625 * mole**-1 * kilocalorie" k5="0.4515189222906 * mole**-1 * kilocalorie" idivf1="1.0" idivf2="1.0" idivf3="1.0" idivf4="1.0" idivf5="1.0"></Proper>
<Proper smirks="[#16X2,#16X1-1,#16X3+1:1]-[#6X3:2]-[#6X4:3]-[#7X3$(*-[#6X3,#6X2]):4]" periodicity1="4" periodicity2="3" periodicity3="2" periodicity4="2" periodicity5="1" periodicity6="1" phase1="270.0 * degree" phase2="0.0 * degree" phase3="180.0 * degree" phase4="270.0 * degree" phase5="270.0 * degree" phase6="0.0 * degree" id="t26" k1="0.3613352840084 * mole**-1 * kilocalorie" k2="0.7094107693902 * mole**-1 * kilocalorie" k3="0.2966149422494 * mole**-1 * kilocalorie" k4="0.3825271697743 * mole**-1 * kilocalorie" k5="0.01001366302186 * mole**-1 * kilocalorie" k6="-0.05061714024213 * mole**-1 * kilocalorie" idivf1="1.0" idivf2="1.0" idivf3="1.0" idivf4="1.0" idivf5="1.0" idivf6="1.0"></Proper>
<Proper smirks="[#6X4:1]-[#16X4,#16X3+0:2]-[#7X3:3]-[#6X3:4]" periodicity1="3" periodicity2="2" phase1="90.0 * degree" phase2="0.0 * degree" id="t151" k1="-0.6373653602282 * mole**-1 * kilocalorie" k2="0.2973949413807 * mole**-1 * kilocalorie" idivf1="1.0" idivf2="1.0"></Proper>

More specifically, they are:

1. id=“t25” phase4=“270.0 * degree” phase5=“90.0 * degree”
2. id=“t26” phase1=“270.0 * degree” phase4=“270.0 * degree” phase5=“270.0 * degree”
3. id=“t151” phase1=“90.0 * degree”

These phase values transform the cos series from an even function to an odd function. Therefore, when a dihedral angle is calculated from the atom indices (ordered) as 1-2-3-4 or 4-3-2-1, we get different results.

The label_molecule function in openff toolkit seems to always return atom indices according to their indices in the Molecule data, therefore, the order of the returned 4 atom indices does not always match the order in the defined smirks pattern. For example, for t25, the smirks pattern defined the atom sequence as S-C-C-N, but in a molecule the N atom may appear before the S atom, so in the returned (sorted) atom indices, this group of torsion may be listed as N-C-C-S, and cause some discrepancies for the torsion energy calculations.

Did I misunderstand the ‘label_molecule’ function or the role of the ‘phase’ parameter?

Thank you,

[mattwthompson]

As the choice of these parameters does not fall under the scope of the toolkit’s SMIRNOFF implementation, I have raised an issue elsewhere in hopes we can document these choices: https://github.com/openforcefield/openff-forcefields/issues/53

[lilyminium]

exactly according to the SMIRKS atom labeling, without doing any sorting

IIRC Molecule/Topology.chemical_environment_matches does this, but the parameter handlers used in creating openmm systems and labelling molecules then store the indices in ValenceDict for bonds, angles, proper torsions. (Improper torsions have an ImproperDict and LibraryCharges just use a normal (ordered) dict). When a ValenceDict sets or gets a key, it automatically transforms to sort the indices so the lowest index is first – so the resulting parameter is always applied in a sorted/symmetric way.

That was an overly technical way to say that the implementation always sorts them, but I’m not sure if it’s supposed to be a guaranteed feature in the spec.