MT – Would like to pitch a project plan for removing experimental decorator from from_openmm before annual meeting. Would like to collect your requirements. I met with RG this morning, and he was supportive of two ideas:
It’s an unavoidable need to squash together OpenMM stuff. Interchange is the only way to do this in our ecosystem. If OpenFE is going to rely on it, it can’t be labeled experimental.
Instead of having interchange.__add__ , have interchange.combine. The latter gives the opportunity for arguments. RG is particularly interested in ways to keep track of residue/atom mapping.
JW – My preferences, in order, are as follows:
Emit a warning when using from_openmm telling users this is kinda new and they may need to submit a bug report
Update the docs to say this is kinda new and they may need to submit a bug report
Keep the interchange_experimental flag
MT – I get the benefits of these options, but it feels like we’re disclaiming everything everywhere and not endorsing that our products actually work. The documentation already explains the warnings. It’s unclear who is actually responsible for studies being correct. So maybe my bigger point is whether there are specific pathways that we should make sure are documented/errored/warned about/tested. So I wanted to invite you to propose requirements.
JW – Hard to enumerate all interop pathways. The big thing is that we have one mouth and need to be heard correctly by industry, academics, and expert users. Eg. Should the RNA example that Josh M is working on be yellow or red?
MT – Issues with RNA include a thing with NADP, and the RNA vdW energy being weird in AMBER (and I think I may have a lead on the vdW thing, gets vdW agreeing to the 5th digit)…. If interchange can digest something using from_openmm, and has tight agreement for energies from 3 engines, that to me means the objective is met. Yellow vs. green is an unclear distinction, people will use what they need in work.
…
MT – Complicated to endorse/not endorse AMBER energies because to_amber writes out prmtop and inpcrd, and the sander.in file is only used in all-in-one “interchange-evaluate-energies” calls. People making workflows are likely to provide their own .in file and “how do we get them to use the right switching in that file” is another (difficult) question
JW – Given this info, I’m most in favor of updating docstrings to say “this has been tested for Sage and some standard format imports, but you may find more edge cases and please report those”. I’d consider this functionality to be green, and to remove the interchange_experimental flag.
…
MT – For JM’s workshop, there are some clear API-breaking improvements that need to be made to from_openmm, which will require changes in the workshop material. How should I proceed?
JW – Plan to go ahead with the update, but communicate with Josh and offer to take responsibility for fixing Josh’s workshop code.
MT – JM should make his WIP notebooks publicly visible to reduce friction.
JW – Agree