Skip to content

Some torsions have two terms with the same periodicity which could be made into one term #148

@j-wags

Description

@j-wags

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 fit Not the case since we only fit k for 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 a k and a phase (where the phase values will be hard to scale/regularize compared to the apples-to-applesness of fitting two ks)

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions