Page Comparison

General updates

• JW –

• Severity: 3/10 now, will become 6/10 in one year (it is and will be worse for OpenFE).

• Timeline if we do nothing: For next year, users can only make environments with both OpenFF and OMMFFs with python 3.10. After that there will be no tested combinations of OFFTK and OMMFFs that people can install.

• Root cause: In GAFF 2.2.20, released in AmberTools 23, some parameters/atom types were used in an unhandled way. So until that was fixed (which it still isn’t), OpenMMForceFields was pinned to AmberTools<=22. AmberTools 22 is only built for Python 3.10, not 3.11. We follow NEP29, which has us only building packages for python >3.10 currently

  • Thanks for reaching out to OE about packaging issue

    • MT – Note that BP came up with a much more graceful solution that’s built into the zstandard python library https://github.com/MolSSI/QCFractal/pull/827#issuecomment-2088711453

  • I’m preparing a live demo for the annual workshop. The plan is roughly to take a OpenFold output, add a ligand, (show off OpenFF stuff), and then pass it to OpenFE to do a bunch of free energy calcs. Are there any particularly cool interchange capabilities I should show off here?

  • OMMFFs - I’m preparing a summary for lead team. Basically the end goal needs to be getting John to either commit to maintaining OMMFFs or explicitly disowning it. I think with the red tests we’ll have momentum from OpenFE as well. Is this summary correct

OpenMMForceFields is falling behind on maintenance in a way that will increase in severity in the coming year.

• • ?

    • Interchange.minimize

    • Interchange.visualize

    • Export to GROMACS, AMBER, OpenMM + run? (take caution re system size → runtime)

    • Serialize to/from json, emphasize implications for portability

    • Interchange.combine?

    • Interchange.from_openmm?

    • Big picture: In-place ligand evolution example?

      • MT – Seems possible on a technical level. Not sure how useful/accurate zero-point energy evals would be. If you just have a ligand in vacuum, the physics would be lickity split, but the repeated exports to OpenMM could be slow. The sketchiest part would be modifying ligand in place- Could be possible with advanced interchange stuff but we probably don’t want to show that publicly.

      • JW – Would make a new interchange for each ligand

      • MT – That makes sense, you should still be cautious with runtime.

      • …

      • JW – If you have any code handy to visualize a minimization trajectory, LMK.

        • MT – I know this was newly added. Lexie would know more and has been using it in her work. Breadcrumbs here.

  • OMMFFs - Thanks for guiding meeting. I’m pushing lead team to work with OpenFE+JC lab on long term plan.

    • MT – PE merged my PR into OpenMM, haven’t manually tested yet. No word on release timeline.

    • MT – OMMFFs repo has everything in that I wanted (lots of old PRs merged, including the change discussed from yesterday where GAFFTemplateGenerator raises an error). MH will tag the release today. Not sure about ETA for conda packages.

    • MT – Not sure about package splitting plans (having a base package without ambertools). Advocating for packaging constraints being Py3.10-12 and AT22+23.

      • JW – Those sound good, should line up well with OpenFF needs.

    • MT – so that should handle us well. Things should be workable early next week. Then everything will get clean once the OpenMM PR is in a release.

    • JW – My next step is to nudge PE to make a bugfix release of OpenMM. Anything you see that would indicate I shouldn’t do that?

      • MT – Nothing from my perspective, though there’s a lot going on with OpenMM that might affect PE’s decisionmaking.

    • MT – Re: Long term planning - …

      • JW – We basically want to feed all the information into JE+DM (costs, alternatives, feelings, etc) and have them make a call that binds OpenFF and OpenFE to a single coordinated course of action (possibly involving agreements with JC lab as well).

Trello

https://trello.com/b/dzvFZnv4/infrastructure

Tutorial collection