2023-04-11 Protein-ligand benchmarks meeting notes

Participants

  • @Mike Henry

  • Levi Naden

  • @Richard Gowers

  • @John Chodera

  • @Irfan Alibay

  • Jenke Scheen

  • Megan Osato

  • @Jeffrey Wagner

  • @Iván Pulido

  • @David W.H. Swenson

Recording: https://drive.google.com/file/d/1mZgCyEOS3U9IWDKU5bvZJ0Vycx4MkfpQ/view?usp=share_link

Goals

Discussion topics

Notes

Notes

  • RG : gufe 0.7.0 release

    • DD : alchemiscale 0.1.0 will pin to gufe 0.7.0; objections or reasons why this may be a undesirable?

    • RG – No, there may be some significant changes in the next few days.

    • DD – Could I pin to 0.7*?

    • RG – No, some hashes may change as a result of later updates. Those will likely stabilize at 0.7.1. There are also some roundtrips (like box vectors) which we’re debugging.

  • DD – Anything I can do?

    • RG – Is alchemiscale depending on OpenFE?

    • DD – Yes, via pip install.

    • RG – Benchmarks may have fallen out of date?

      • IA – Nope, it’s up to date and works with the latest version of everything

    • DD – Does GUFE depend on other OpenFE packages or can I install it alone?

      • RG – It should be standalone in the OpenFE pacakges

      • DD – Ah, I was thinking that we needed it for OFE-benchmarks

      • RG – Some fuzzy edges around things like atom mapper.

  • IP – Anything that protocols should be aware of in this release?

    • RG – Settings changes may have been substantial - Now there’s a grand unified settings object.

    • DD – I think I made changes to noneqcyclingprotocol last week to keep this up.

  • IP – Why isn’t python 3.8 supported?

    • DS – We use typing stuff that wasn’t supported in 3.8, so we hopped up to 3.9. The official end of supportdate is in 3 days

  • JW – Hash changes <--> semver? This will probably be an important thing to track.

    • should hash changes be equiv to API changes?

    • RG : yes, agree, so will make those more explicit in the future. 0.7.0 should be seen as 0.7.rc1 this time

  • RG – Aiming to hit 1.0 for the May meeting. We’ll commit to long term support for thje 1.X line but it may get hairy with the 2.0 release coming.

    • JW – OpenFF wants to coordinate with you for the 9ish month breaking release timescale.

    • RG – Agree, let’s chat in May.

  •  

  •  

  • .

  • IP : protein-ligand-benchmark repository working group - call for participants, scheduling, convening

    • IP – About to put out the recruiting call. How can I amke sure it reaches the OpenFold people?

    • JC – Can ask KCJ to repost, or get access to OMSF slack. Or tell me and I can forward to MAQuarishi

    • IP – I’ll send to you to send to MAQ.



  • DD : next sprint begins tomorrow, spans 4/12 - 4/24

    • architecture overview : PL Benchmarks on FAH - Architecture v6.drawio

    • alchemiscale 0.2.0 milestone

      • DD – Note that the current goals for the sprint are items for 0.2 - Mostly docs, and some polish on things like finer grained permissions.

    • coordination board : alchemiscale : Phase 2 - User Feedback and Documentation

    • updates on In Review, In Progress, and Available cards

      • IP – Perses 1066 - Noneq cycling - After last week’s meeting we decided on having this branch be a main/feature branch. So we’ll be making PRs to this branch

      • PR 1177 - Increases test coverage. Some issues from pulling GUFE 0.2, but now it should be getting 0.3 as intended.

        • DD – Great. This isn’t blocking us on alchemiscale releases. What we’ll do is, if we find there are gaps on what the protocol offers, we can fix and redeploy from this branch.

        • IP – Agree. I did notice that it fails with b3.11

      • Re: python 3.11 - currently held back by ambertools

        • JW – meeting with David Case in next couple weeks to get ownership of AT conda feedstock tranferred from Jaime R-G to AMBER community. Once that handover is complete the AT PR backlog (py3.11, m1 macs, AT2023) should start flowing again.

      • RG – Examplenotebooks 42 – Tutorial which uses repex protocol. I’m minimally fixing the notebooks today, then we’ll probably put out a mroe polished version for the May meeting

      • IA : question from BCossins on number of ligands for cmet; PLB #91 - They’re a paying member so can we answer this?

        • JC – I’ll tag in MBoby and we can try to address this.

    • JC – Perses 1128 – No progress since last meeting. Test failures stemming from map indices being out of range.

      • DD – Can you hand this off?

      • IP – We have a perses dev meeting today and we can talk about this.

    • DD – GUFE 143+144 – These are on the speculative side on new designs for where to store things. I cold find time to do these. Was 144 mroe urgent?

      • RG – It is quite urgent since it’ll be breaking so we’d like to line it up for the current relase cycle, so let’s find some time to talk if we don’t want wait 9 months.

      • DD – Sounds good, let’s dicuss friday

    • DD – Deployment (no issue #) is on me, will try to work this week

    • DD – Alchemiscale 28+30 – User guide – Is anyone up to take this on?

      • MH – I’m planning to work on deployment (#30)

      • DD – I’ll run #28

      • (both will reach out to HMO when needed)

    • IP – GUFE 170 – I opened this issue in GUFE about ligand atom mapping. Not super urgent but I’m wondering if there should be some sort of validation, and what assumption to make.

      • RG – Could check to make sure there are no negative indices and no indices greater than n_atoms. We could add this validator, could be worth it.

      • DD – Yeah, mappings should always resolve to real atoms.

      • DS – Not everything needs to be a ligand atom mapping, mappings could be between solvent and other complex cases. Could solve by having well defined component classes.

      • IP – Yeah, this one is for ligandatommapping and smallmoleculecomponents.

      •  

    • .

    • create/nominate new cards for inclusion in this sprint

  •  

Action items

Decisions