-
Notifications
You must be signed in to change notification settings - Fork 25
Description
Summary
I point out that there are some torsion parameters in our FFs that have multiple terms with the same periodicity, and that these could be combined into a single term. I then write out how they could be combined, and list the pros and cons, and in doing so I convince myself that it would be a bad idea in the end. I'm posting this as an issue so that people in the future can save a few minutes in case they go down the same line of thinking. Happy for this to be closed any time.
Details
It appears that at least one torsion has two terms with the same periodicity - t25 in openff-2.3.0 has two periodicity=2 terms:
| <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 ** 1" phase2="0.0 * degree ** 1" phase3="0.0 * degree ** 1" phase4="270.0 * degree ** 1" phase5="90.0 * degree ** 1" id="t25" k1="-0.08703450796813 * mole ** -1 * kilocalorie ** 1" k2="0.1275825325254 * mole ** -1 * kilocalorie ** 1" k3="-0.9452470883987 * mole ** -1 * kilocalorie ** 1" k4="0.0459593141179 * mole ** -1 * kilocalorie ** 1" k5="-0.07468995659357 * mole ** -1 * kilocalorie ** 1" idivf1="1.0" idivf2="1.0" idivf3="1.0" idivf4="1.0" idivf5="1.0"></Proper> |
I think (but haven't done trig/mathy derivations in a long time) that in such situations these can be expressed as a single cosine with a modified amplitude and phase.
Thinking through this a bit, I see the following pros and cons for combining them:
Pros:
- Possibly better interoperability (eg ParmEd by default not allowing duplicate torsions with same periodicity)
Maybe an easier time for the optimizer during FF fitting since it'll have fewer parameters to fitNot the case since we only fitkfor each term currently, see below
Cons:
- The phase values for this torsion seems to be physically motivated (0 and 270 degrees), making them easier to reason around in the future, and possibly constraining the range of torsion profiles in a physically meaningful way
- Upon further thought, this may not actually reduce the number of parameters being fit, since in the current situation we're fitting two
ks, and in the "one cosine" situation we'd be fitting akand aphase(where the phase values will be hard to scale/regularize compared to the apples-to-applesness of fitting twoks)
So overall I don't actually recommend combining these terms in the FF itself, since software/workflows that need a single term per periodicity value can always use the trig identity above to create it during export, but keeping the terms separate preserves important info for folks doing subsequent rounds of FF fitting.