Page Comparison

General updates

• JW – No fires (that I’m aware of) that appeared in last 2 weeks.

• JW – Working with RAlford on a CUDA error. Seems similar to this: https://github.com/openmm/openmm/issues/4370

idivf issue

• JW –

  • BW’s reported bug

    • What should happen:

      • A torsion can have NO idivfns defined

      • `` SOME

      • `` ALL

    • What’s happening in this case:

      • The FF has NO idivfs defined, so the default value should be taken

      • The default is auto, which should raise a NotImplementedError

      • Something else raises an error first.

    • Research

      • All released OFFXMLs have explicitly defined idivfs for each periodicity for Propers

      • No released OFFXMLs have explicitly defined idivfs for Impropers

      • BW’s experimental force field has different number of idivfs and peroditicies for a proper

    • Fixes

      • Open issue on openFF standards raising the point that idivf=”auto” has two different but valid interpretatons (“torsions impinging on central bond” could mean “ethane’s central bond has idivf9 becuase 3x3” or “a torsion with k1-k6 defined should have idivf=1/6 because there are 6 ks”).

      • Open issue on OpenFF standards repo raising the point that impropers could be interpreted either as “one parameter per 3-valent center, applied as trefoil (so 3 OpenMM parameters total)” OR “possibly multiple parameters per 3-valent center, ALL applied as trefoil (so 9 OMM parameters total)”

      • MT – What should happen if one or more ProperTorsion idivfs is missing? I wouldn’t propose filling them in with “auto”. I’d propose raising a parsing error immediately. To do anything else is to interpret a vague spec in a non-reverse-compatible way.

        • JW – So, option 1 is raise a “ParsingNotImplementedYetError”. Option 2 is implement a complicated behavior where idivfs can be stored as undefined, and missing values will be safely roundtripped, and something sane will happen if someone accesses the getter for an undefined idivf (either it returns “undefined” or the default value)

        • MT – I’m in favor of option 1.

        • JW – I’ll implement option 1

    • Thinking through error cases:

      • For PROPERS If a torsion parameter with idivfn=

    "auto" should raise NotImplementedError?

• • • • auto WOULD be applied, a NotImplementedError should be raised.

        • MT – OFFTK currently raises an error about how it can’t convert the word “auto” to a float. This happens both in the case that “auto” is explicitly in the parameter, and in the case where the default value of “auto” is used to fill in unspecified values.

      • For IMPROPERS, idivf is always set to 3. Dangerous?

        • JW – Possibly dangerous because

          • Someone might use impropers to apply to a 5-valent metal center, like trigonal pyramidal, and be surprised by a idivf of 3

          • Not all 3-valent centers are guaranteed to get 3 impropers - the SMIRKS could be defined such that only one improper parameter matches a center (instead of 3)

        • MT – Not a big deal because:

          • The 4-atom form of impropers that we enforce right now ensure that there will always be one central and 3 neighbor atoms, so auto=3 makes sense in the long run.

          • A user could just define an improper that applied 12 times to to a methane. It doesn’t have to make sense to us, they could just do it.

        • MT – JW’s last point is moot, since only one OFFXML parameter is applied per 3-valent center. 3-valent centers DO NOT rely on FF to apply 3 OFFXML parameters to them.

Trello

(reached end of time, will do Friday)