Matt Thompson

Code changes are all in place - this time with tests that actually test the expected behavior. Just waiting on 0.11.2 to be released.

I think today, the general topic of periodicity is handled by whether or not the topology has box vectors [^1]. The other combinations of vdW and electrostatics non-bonded methods, long-range...

I think overlapping SMIRKS is a dangerous footgun and one that's not going to go away as long as we explicitly support loading multiple force fields in and TIP3P parameters...

It would be useful if we could reproduce `ForceField("openff-2.0.0.offxml", "tip4p.offxml")` giving TIP3P charges to water; I don't recall if that happened or if it was just something we were worried...

Something's wrong with either the SMIRNOFF definitions used here or the charges as assigned: 

Above should be fixed by https://github.com/openforcefield/openff-interchange/pull/480

Here are the different `State` object generated by each code path: [openff.xml.txt](https://github.com/openforcefield/openff-toolkit/files/9426361/openff.xml.txt) [openmm.xml.txt](https://github.com/openforcefield/openff-toolkit/files/9426362/openmm.xml.txt) I'm working on figuring out if there are any substantive differences between them or if the energy...

By manual inspection: * 🟢 Periodic boxes are precisely identical * 🟢 Particle masses are precisely identical * 🟡 Virtual sites use different types * OpenMM uses `OutOfPlaneSite` * OpenFF...

As far as I'm aware, OpenMM does not have a clean way to serialize their `Topology` object for easy comparison, nor do I know how to quickly compare their states...

I've pushed a dev-only version of my local notebook to a separate branch: 47088c712d8b282c56764b617bd39e6000d88e2b