Did we agree with SB to not support legacy handlers at all in 0.11.0? Or to expose use_interchage=True/False?
MT – Three options:
Remove old code paths from 0.11.0, maintain 0.10.Z with critical bugfixes only
Have use_interchange=False
Have use_interchange=True
Have use_interchange kwarg exist, initially default to False, later become True
Keep old code paths, don’t change create_openmm_system, use ForceField.create_interchange(top).to_openmm() for continued testing, and swap out create_openmm_system logic on a future date.
JW – Fitting team’s interests seem to be avoiding API changes altogether - So their preference is to stick with 0.10.Z API regardless of whether interchange supports their plugins. This lets them only have one “update day” where they adjust to BOTH the Interchange plugin format AND the 0.11.0 API changes.
JW – regular users will almost never try use_interchange=True if that’s not the default.
MT – Options 2-4 all introduce a new kwarg to the API, which we can probably avoid if nobody is ever going to use it
JW – How about we plan for option 1, and we implement that in the alpha and RC for 0.11.0, and if users start reporting lots of bugs then we revert to option 5 before the final release?
MT – That sounds good. I’m a bit concerned about vsite support
JW – Remember that we don’t need to do vsites perfectly, we just need to have =< as many bugs as 0.10.2, and that there isn’t always a single “correct” answer for vsites. Adding support for charge_from_molecules would be more important that exceeding “=< bugs in vsites”, and maybe even GBSA is more important.