SMIRNOFF: Unclear which section(s) are optional and/or depend on each other

[mattwthompson]

There are some cases in which it is not clear which parameter section(s) in a SMIRNOFF force field depend on each other. For example, it is natural [1] to define a TIP3P force field with a <LibraryCharges> section but neglect to add an <Electrostatics> section. This leads to difficulties and strange behaviors in implementation [2], i.e. there is no way to know what cutoff method and distance should be used when the [] section is missing. @j-wags has suggested [3] that if a force field defines any charge methods, it should require an <Electrostatics> tag and if it doesn't, it either doesn't need to or shouldn't be allowed to. Requirements like this should also cover the cases of force fields that do not use electrostatics (if that's something that SMIRNOFF should support in principle).

I think this is only an issue when handlers depend on each other, i.e. when a parameter section is not fully defined when alone. For example, a <Bonds> section doesn't need to know information from other sections, whereas <LibraryCharges> does (<Electrostatics>). There are some cases in which one section could use information from another but does not require it. A <Constraints> section that does not define the distances of constrained bonds will need a corresponding <Bonds> section, but it is also possible to define a <Constraints> section that does fully define all constraint distances.

1. https://github.com/openforcefield/openff-toolkit/blob/0.9.2/openff/toolkit/data/test_forcefields/tip3p.offxml
2. ForceField with no Electrostatics tag can be used to make a system openff-toolkit#716
3. Raise error when force field is missing Electrostatics tag openff-toolkit#833 (comment)

[SimonBoothroyd]

+1 for having each handler specify which other handlers must be present, as well as which handlers they may interact with and if they do how.

Would you be willing to open a OFF-EP and take a stab at updating the spec to include this info?