Page Comparison

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 : https://drive.google.com/file/d/1ZA-zuqrhKSlYBEiAIqxwNaHXvgJdlOkT/view?usp=share_link

• alchemiscale 0.2.0 milestone

  • Github link macro
    link https://github.com/openforcefield/alchemiscale/milestone/4

  • 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

    • DD – The current version uses gufe 0.3?

    • RG – Yeah

    • DD – Awesome, this is useful for my testing

    • DD – For JS and MO – This is the current best resource for making networks https://github.com/OpenFreeEnergy/ExampleNotebooks/blob/8b399180601c9645c28450c6e9361a39bff11b20/networks/Preparing AlchemicalNetworks.ipynb

    • JW – Re docs – When is OFE planning to take JM?

      • DS – I’m point person on this, likely second half of this year, june at the earliest

  • 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