Unclear use of idivf

[diogomart]

In the ".offxml" file, the torsion potential is written as:

potential="k (1+cos(periodicitytheta-phase))"

However, according to the documentation, idivf divides the barrier height, so the actual potential would look like:

potential="(k / idivf) (1+cos(periodicitytheta-phase))"

Almost all torsions define idivf equal to 1.0, making it look like the barrier heights k are already divided by the number of 4-atom paths. For the few torsions that set idivf different from 1.0, it is unclear if k is divided by idivf.

[davidlmobley]

The idivf is there for convenience for folks porting in FFs from AMBER-like formats which use this frequently in the force field format. I don't think we use it very much (or at all?) however.

I'm not actually sure if you're asking us just to clarify, or to check whether we've implemented it correctly, or to check whether the documentation/description in the OFFXMl is correct... Or all of the above? :)

[diogomart]

It's to check if the documentation is correct. The documentation says k / idivf, but the OFFXML says k. Which one is implemented?

[j-wags]

Ah, I think @diogomart is referring to the OpenMM CustomForce-like potential that we put in the 0.3 SMIRNOFF spec. This was an oversight on my part! The OFFXML formula should include idivf.

Despite writing the wrong formula, division by idivf is happening when torsions are applied. We should fix this in the next SMIRNOFF spec update (and probably change all potential fields to be this format).

[diogomart]

Great, so k / idivf is implemented. Thanks!