OFF-EP-0009

[mattwthompson]

• Add LJPME as an option (SMIRNOFF: LJPME not allowed #11)
• Explicitly do not resolve SMIRNOFF: Specifying "PME" as a non-bonded method is somewhat ambiguous #15 Coulomb PME convergence criteria no specified? #50
• Explicitly do not resolve SMIRNOFF: The switching function is never explicitly specified #16
• Do another typo pass-through
• Find link for Amber LJPME
• Find link for CHARMM LJPME
• Incorporate relevant Shirts comments:
  • OFF-EP 0007b — Add long-range vdW treatment attribute in vdW section (alternative to OFF-EP 0007) #44 (comment) - not going to be explicit about this, but worrying about LAMMPS's implementation is not in scope here
  • OFF-EP 0007b — Add long-range vdW treatment attribute in vdW section (alternative to OFF-EP 0007) #44 (comment) valid but not directly relevant
  • OFF-EP 0007b — Add long-range vdW treatment attribute in vdW section (alternative to OFF-EP 0007) #44 (comment) not in scope here
• Chodera comments from 9/5/23 SMIRNOFF committee meeting:
  • Possible incompatibilities with Lorentz-Berthelot mixing rules?
  • Does it make sense to use "conducting boundary" language?
  • Are both the 12 and 6 terms included in reciprocal space?
  • What about non-12-6 potentials?

[mattwthompson]

Jotting down some notes:

After reading the docs and trying to grok the implementation in some OpenMM source code, I'm moving to just use "Ewald3D". I'm not confident that a conducting boundary is not used, but as I understand it there is no concept of a dielectric medium for the vdW term, so I lean towards not including it.

At least in OpenMM world, the incompatibility with Lorentz-Berthelot mixing rules seems to only be in reciprocal space. The docs imply to me that geometric mixing rules are used in reciprocal space no matter what, and that's just an acceptable approximation. From this I'm inclined to treat it as an implementation detail instead of specifying that LJPME cannot ever be used with Lorentz-Berthelot. In fact, GROMACS seems to have no problem doing that.

[jchodera]

I've provided some minor suggestions for improving clarity, but this OFF-EP has my approval to proceed.
Thanks again for rapidly resolving this!

[jchodera]

Shouldn't we just say "Ewald" instead of "particle mesh Ewald" here, and link to a stable description, like http://docs.openmm.org/8.0.0/userguide/theory/02_standard_forces.html#coulomb-interaction-with-ewald-summation? We can mention that PME can be used as an implementation detail.

I thought we decided this is compatible with every potential that employs an 1/r^6, but we may restrict it to LJ-12-6 in the current implementations of the spec?

[j-wags]

Yeah, I agree with not restricting this to LJ-12-6. There are a lot of nuances to what we could put here but I'd have a slight preference for removing the last sentence altogether, implicitly reserving the right to raise NotImplementedErrors on the software level.

[mattwthompson]

Shouldn't we just say ...

Yup - I'm going with "Ewald summation" to be slightly more explicit

I thought we decided this is compatible with every potential that employs an 1/r^6

That's my understanding as well

we may restrict it to LJ-12-6 in the current implementations of the spec?

That is precisely what I intend here - future versions of the spec that include LJ variants or other functional forms altogether should discuss their compatibility with 12-6 Lennard-Jones. In all likelihood it is as simple as the restrictions you describe, but I feel strongly that this proposal should not elaborate on compatibility issues with unsupported potentials. In the "Usage an Impact" section I attempt to encode this:

In this first iteration, periodic_method="Ewald3D" is only compatible with potential="Lennard-Jones-12-6", which is currently the only supported value. Future changes to the potential attribute should discuss compatibility with LJPME, if any, including which terms can be ignored in reciprocal space.

[lilyminium]

LGTM -- thank you for putting together this proposal! I agree with John's comments wrt pinning to a version of the docs, and including a short overview of previous discussion.

[davidlmobley]

One minor comment, but I have nothing else to add to what's already been said; looks good and I approve.

[j-wags]

Thanks for putting this together. I agree with John's comment about adding a few of our discussion points for future people. And I think that bumping the spec version to 0.5 is the right thing to do... it's a little inconvenient but it'll be good to establish a precedent for "doing things right" in future EPs.

[j-wags]

Yeah, I agree with not restricting this to LJ-12-6. There are a lot of nuances to what we could put here but I'd have a slight preference for removing the last sentence altogether, implicitly reserving the right to raise NotImplementedErrors on the software level.

[mattwthompson]

Thanks all for the reviews - I think I've covered everything brought up, but I'll leave this open for a short period of time in case I've introduced new typos or missed an important detail from our discussion in the meeting