Page Comparison

JS – JH’s work update - Wanted to draw your attention to what he’s doing for us - Building a different workflow for FE calcs, using components from OpenFE and alchemiscale. So he’s building a similar thing and integrating it into our codebase. https://github.com/choderalab/asapdiscovery/pull/424 - End-to-end pipeline that’ll start at docking and end by pulling down from alchemiscale and running analysis.

DD – Put a different way, JH built openff-qcsubmit which was our interface to QCFractal. So what he’s doing here is building ASAP’s machinery for putting things into alchemiscale and pulling it out as an end-to-end pipeline.

JW – Just a heads up that this working group is actively changing APIs at this stage in the process, so that may impose large costs on folks building on top of these components.

DD – Yes, we’re changing the interfaces. For the most part we keep old data around but we don’t have a retention policy and alchemiscale.org isn’t an archive.

IP – If ASAP needs a specific version of the infra, would it make sense for us to run our own alchemiscale instance?

• DD – Yes, that would make sense.

alchemiscale.org user group

• user questions / issues / feature requests

  • MO – I’ve talked with IA, but I’ve noticed my jobs are starting after 10 min with a result, even though they’re submitted for 10ns.

  • IA – That does sound too fast… IP will discuss this alter, but we were p[laying with the early termination stuff on alchemicscale (if the MBAR falls below a certain value then end the run). So my guess is that this is erroneously terminating early. I’d look at turning this off. Is this a complex simulation?

  • MO – It’s a solvent simultation.

  • IP – Is it possible that you’ve already run the same job and alchemiscale is deduplicating?

  • DD – It shouldn’t be deduplicating in this case, it should be a new calculation.

  • DD – It’s possible that it actually finished (solvation is pretty fast), but 10 min is still fast for that.

  • IA – Which equilibration length?

  • MO – I think default, IIRC the only thing I changed was lambda windows.

  • IP – There’s a chance that this is actually running in 10 mins… I’ve seen solvent stuff going for 1000ns/day. So that would be about 40ns/hour.

  • DD – MO, could you run one of these transformations locally to confirm this behavior? I also just changed our deployment to much beefier GPUs so they may actually be going really fast.

  • MO – Sounds good, I’ll try that and will follow up on the #free-energy-benchmarking slack channel.

  • IA – I’d also look at disabling the early termination behavior just in case (set sampler_settings.online_analysis_target_error to 0)z

• compute resources status

  • DD – 33 workers on PRP, none on Lilac. About 20 running tasks. Oh, there are more that were just submitted, I’ll increase the number of running workers.

• call for new users

  • DD – We have some new users who I just issued credentials to - MWieder and CIacovella.

• current stack versions:

  • alchemiscale: 0.1.3

  • gufe: 0.9.1

  • openfe: 0.11.0

  • perses: protocol-neqcyc

• DD – Note that this will be updated soon.

DD : alchemiscale release v0.1.4 is out!

• features fix for result retrieval encountered by Irfan and Hannah:

  Github link macro
  link https://github.com/openforcefield/alchemiscale/pull/161

• LN – How critical is pydantic<2 pin?

  • DD – We tried to be less harsh with this - HMO tried putting in an import guard to do the import check but we didn’t move ahead with it since there was a mystery error.

  • JW – OpenFF is actively updating - If there’s an import error from us, check back in a day or two and it may be fixed.

  • RG – I think our only exposure to pydantic is openff-models

    • DD – It looks like there may be a direct pydantic import in gufe Settings

  • DD – I’ll open a PR to try adding pydantic 2 to alchemiscale and use the import guard, and will just keep an eye on it.

• ready to deploy; any other stack version updates to include?

  • RG – When will the next release be?

  • DD – Whenever we want

  • RG – I may have some updates next week, possibly affecting stored protein data. I can provide a migration script and reverse-compatible deserialization, would need to decide where it lives.

  • MH – Could get messy to support lots of deserialization methods in the long run. We might just consider supporting version N-1 moving forward.

  • DD – Alchemiscale.org isn’t an archive, and we only say we’ll make our best effort to hold old data. So we can tell people to pull down their important data in advance of a storage-breaking release. We can put a warning during deserialization client-side, where users will get a message that their data may be unavailable in the next release.

  • JW – Could you remind me whether we have a milestone/date when the data becomes stable? I recall we agreed to let it get wiped frequently during development, but I can’t recall if we had a stable next phase planned.

    • DD – No firm plans on this front - right now people should be ready to pull their data down for local storage when the server changes. We can discuss longer-term retention/compatibility in the future.

IP : Protein-ligand benchmarks working group update - Met with IA, JS, HBaumann.

• re-run nan’d simulations with MST – related PR:

  Github link macro
  link https://github.com/openforcefield/protein-ligand-benchmark/pull/95

  run radius

  • IP – Working on rerunning - In progress

• run radial network from HB Hannah

  Github link macro
  link https://github.com/openforcefield/protein-ligand-benchmark/pull/95

  • IA – This one just needs testing. HB ran this the other day - Hif2a was probably a bad test for this because it’s almost two networks.

• IP – I’ll check that these run, will use perses and alchemiscale (though may not do all systems, will focus on ones with particularly good/bad results)

  • IA – We’ll run everything we can with alchemiscale - This excludes systems with charge changes. IP, were you going to send us notebook on how to run perses with charge changes?

  • IP – Oh right, I’ll send that.

• DD – IA, are you working on multi-star maps?

  • IA – Yes, but that’s more distantly in the future.

• Generate manually curated network for some of the systems. Contribution by Ken.

  • IP – KT curated networks for 4 targets - We’d like to include this network in the edges files - It’s another optimal case for benchmarking. Used a mix of intuition and schrodinger tools. Goal is to have an optimal network for benchmarks, to disentangle benchmarking atom map planners vs. FE workflows vs. FFs.

• IA – From our end, HB may go back to looking at LOMAP. HB was looking at HIMAP but it seemed like it’d never finish running for some systems, so it’s possible we’ll end up with a mix.

• IP – Should we run some with kartograf?

  • IA – BRies is running some things now. It’s structurally ready to be used in production but the scoring/mapping is still being optimized.

  • RG + IP – Let’s have a separate meeting/working session on this.

  • IA – I may get HB to make the LOMAP networks using kartograf. Otherwise we’d be mixing perses and lomap, etc.

  • IP – So it could be used, but we won’t plan on using it in the next release.

  • JS – I’d love a new update on kartograf - Maybe BRies can put something together?

  • RG – BR can’t make this meeting, but I’ll be meeting with him tomorrow. I can pass on his information or you could reach out directly.

  • JS – Would love to chat, we’ve been using it a bit and have feedback.

  • (General) – JS and JH can reach out directly to BR, open issues, or talk to OpenFE folks to start a conversation.

alchemiscale development : sprint complete; new sprint begins 8/9

• architecture overview : https://drive.google.com/file/d/1ZA-zuqrhKSlYBEiAIqxwNaHXvgJdlOkT/view?usp=share_link

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

  • DD – protein mutation protocol for alchemiscale - Perses 1222 - IP, could I assign you, which means you can also delegate to IZ?

    • IP – Sure, it probably won’t be done this sprint.

  • DD – alchemiscale 157 - deployment docs - Thanks MH for finishing this!

    • MH – I’ll configure RTD to render the newest verison.

  • OMMFFs 288 - Parsing of OFFXML strings - merged but not released

    • IP – I was holding this release back, I’ll get it out this week.

  • Alchemiscale 138 - prevent actioning tasks that shouldn’t be actionable

  • DD – nontracked item about inconsistent results store was fixed.

  • In review:

    • IP – Perses 1066 - noneq cycling - blocked by internal changes in perses (need to merge+release a bugfix). Good news is that we’ll have a bugfix release Thursday and then can move forward with this.

    • DD – Alchemsicale 132 – KeyboardInterrupt handling - Interested in OFE’s thoughts as to whether this is a good idea.

      • IA – I’d need DS to take a look at this, I’m a little against this becasue it seems like it belongs somewhere else.

  • In progress

    • DD – ALchemsicale 28 - user guide - still on my plate

    • DD – Alchemscale 130 - Backup solutoin - still on me

    • DD – Alchemsciale 30 - I’ll take this from you, MH.

• alchemiscale 0.2.0 milestone:

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

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

• DD – I’ve started reviews of user stories - Will be tagging original authors to determine whether we’ve reached the goals we set out. From that we can determine whether there are new action items we need to pursue.

  • JW – Sounds great

new discussion items from ASAP roadmap: https://asapdiscovery.notion.site/Computational-Chemistry-Core-alchemiscale-related-roadmap-9052f215437246f9be4a11abd10f6d71