Switching function of mainline OpenFF force fields not used

[mattwthompson]

This is basically the same as #809 except there may be complications in the hocus pocus of free energy magic and custom forces that makes this harder or impossible. I don't know.

---

OpenFF's mainline force fields use a 1 A switch width with vdW interactions. (The cutoff is at 9 A, so if stored as a switch distance it's written as 8 A). Code paths involving openmmforcefields do not, by default, set any switching function and fall back to OpenMM's default of no switching (a negative value means "don't do that").

>>> openmm.NonbondedForce().getSwitchingDistance()
Quantity(value=-1.0, unit=nanometer)```

This can be set in general in OpenMM like

```python
ForceField.createSystem(
    ...,
    switchDistance=0.8 * openmm.unit.nanometer,
    ...,
)

Unfortunately this is not included in SystemGenerator.create_system which appears to be what this codebase calls. Something like .setSwitchingDistance() after system creation should work in either case.

I don't know how much of an impact this has, but OpenFF's force fields thus far are trained with a 8 A switching distance in condensed-phase fitting and are shipped with that in the non-bonded settings.

Related openmm/openmmforcefields#324

[IAlibay]

Thanks for writing this report @mattwthompson !

For some extra context here - we briefly discussed this at the last Perses sync call. The short summary is that in folk's experience the impact on calculated free energies should be minimal (@hannahbaumann @mikemhenry please correct me if I'm remembering wrongly!). That being said, it is still an unknown and something folks felt should be investigated / validated at some point.

P.S. For now, whilst we are in the process of completing the 1.0 release, this issue has not been review / assigned priority. We will aim to do so as soon as possible. (cc @jameseastwood - something we should remember to add to the maintenance / validation backlog)