2021_10_26 Evaluator future planning

• DM – Some discussion of having JS take over maintenance of OpenFF Evaluator. SB, what would this encompass?

• SB – Not too much. Just cut a new release that supports vsites. I don’t anticipate a lot more needs until Rosemary is out. So the big thing will be making sure that tests stay passing, and represent Evaluator’s needs to upstream dependencies like Yank, OFF toolkit, etc. If someone needs major new science done (like for the protein FF) then there may be new features, but those would be done as plugins.

• DM – I was imagining this being scoped to continuing maintenance, but that new feature requests would be supported by additional funding.

  • JS – This makes sense. Maintenance wouldn’t take too much effort, but implementing a new property would take significant time.

  • JW – This would come with admin rights on the repo. This could overlap with the big pAPRika PR. So that would be merge-able but it would still be good to have a secondary reviewer.

  • DM – LWang could review?

• SB – There’s chunks of the code that could be stripped out, like reweighting (this was explored, but found to not be a very promising idea, and is just a lot of complexity that may not be worth maintaining). Storage of datasets was written quickly and may be tricky. But as long as the core simulation and data curation stuff stays online, then most of the value will be there.

  • DM – Does reweighting stuff have any remaining promise?

  • SB – Not sure. The process of going back over the trajectories was way slower than would have been beneficial. Performance issues could have been OpenMM-specific. Forcebalance was also taking really large steps and not getting clear results.

  • DM – High reweighting costs on OpenMM would make sense if it was doing them of CPU instead of GPU.

  • SB – Reweighting in GROMACS may be promising once that comes online, since it could get around the performance issues.

  • SB – Thinking about surrogate modeling as well, that can also be hard. OM is finding that some systems are super slow, and so it’s not clear how this will apply to real sets.

• JW – Is it worth drawing a distinction between bugfix PRs and major feature additions?

  • DM – Yeah, for major PRs JS could just initiate the process of recruiting a reviewer.

  • SB – Most changes should be pretty small (like, vsite PRs are just 100-150 lines), but for more than that it’d be good to draw in JW.

• JS – Is there an Evaluator roadmap?

  • SB – Not really, I got it to feature-completeness for my studies and Sage. But there aren’t big items coming up except Chapin’s biopolymer needs.

  • JW – I’m hoping that most of the biopolymer needs will be straightforward, but I could imagine that some of the observables will be complex and require rejiggering.

Next steps

• JW gave JS admin rights on openff-evaluator

• JS will become first-line reviewer for issues and PRs on Evaluator, will ping SB for clarification/sanity checking when need.

• We will not extend support to getting Evaluator running on different hardware/clusters. (SB – DASK-land is complicated. Hold onto the pins from the openFF-sage repo as long as you can)