2023-07-25 alchemiscale Working Group meeting notes

Owned by David Dotson, created
Last updated: Aug 03, 2023
6 min read

Participants

  • @Jeffrey Wagner

  • @Irfan Alibay

  • @Iván Pulido

  • Levi Naden

  • @David W.H. Swenson

  • @Mike Henry

  • @James Eastwood

  • @David Dotson

  • @Joshua Horton

 

Recording: https://drive.google.com/file/d/1O2QZEXY1NTY_Yl4SU7yBfc9-hpAECZE5/view?usp=drive_link

Notes

  • alchemiscale.org user group

    • user questions / issues / feature requests

      • IP – I haven’t looked into my jobs, but I know they’re not running

      • DD – They’re not being actioned and won’t be actioned until they’re updated.

    • compute resources status

      • DD – ~70 workers on lilac, ~60 on PRP, plenty more capacity. Earlier had 360 simultaneous workers. JC is pursuing more resources on ACCESS.

      • IA – MH, you mentioned you had some new resource at some point. Did that pan out?

        • MH – I haven’t had time to test that out yet. But it’s whatever the new name for Open Science Grid is. I was able to get OpenFE containers built+running on GPUs. Now I just need to test running production systems, gonna start with TYK2. The trick is that they’re all pre-emptible, so less than 24 hours is needed, less than 12 is ideal. So just one leg on an FE calc would fit well. Also looking at getting changes to bespokefit to work - like, standing up bespokefit QM workers. Should be good at checkpointing/scaling.

      • DD – MH, do you want a credential for alchemiscale.org?

        • MH – Could I get an isolated scope for testing without breaking production stuff?

        • DD – Sure. Will do.(Action item created at bottom of notes)

      •  

      •  

    • call for new users

      • IP : Josh Horton?

      • JH – I’ve already got keys for it

    • current stack versions:

      • alchemiscale: 0.1.3

      • gufe: 0.9.1

      • openfe: 0.11.0

      • perses: protocol-neqcyc

      • IA – RG had a hotfix for GUFE for loading nonstandard residues into GUFE objects. If that’s needed it’ll require a version bump/release.

      • DD – Sounds good, just let me know when you do.

  • DD : welcome back!

    • alchemiscale 0.1.3 released 2023.06.29; deployed for alchemiscale.org on 2023.07.01

  • JH : offxml string parsing in openmmforcefields; allow support for FF injection into Protocol Settings

    • JH – CI passes, just waiting on fixes in OMMFFs.

    • MH – I wanted a second review from IP.

    • IP – I’ve started working on it - What we need for the next release of OMMFFs is fixes for CI (mostly done), but also changes to how we use Espaloma FF. Once we have that fixed we can make a new release. But I think those changes are independent of JH’s PR. I separated the espaloma tests from the others - We don’t need it to be fully supported when we release a packAge version.

    • MH – Great, IP could you review the current PR and if it’s good we can merge+release?

    • IA – It’d be good to have time for us to test on top of this.

    • MH – That’ll work.

    • IA – We also had an approach of blanket-disabling OpenEye, but I’m gonna wait for RG to return to move on that because it could have a big effect on users.

    • JH – Yeah, that’s because I fit the torsions to OE charges and I want them to be consistent.

    • MH – Is the charge assignment not in the FF at all? Like, can we pass in the charges from BespokeFit into the OFF Toolkit for systemcreation?

    • JH – Yes, we can store them as librarycharges in the OFFXML.

    • …

    • JH – On the free energy side, these look OK. I can run these with bespoke FFs through OpenFE.

    • JW – so now bespokefit, when it runs it adds custom torsions and library charges to FF?

      • JH – not yet, but trying that out

      • JW – think that’s an outstanding idea

        • does it calculate charges for whole mol, only fragments?

        • JH – only fragments; but considering ways to go further with whole molecule after?

      • JW – might be a way to take advantage of AM1BCC running on fragments first

    • JW – can this functionality be used for protein FFs, or is it just small molecules?

      • IA – on OpenFE side, will only be used for small molecules; but we could extend this approach to proteins

      • JW – want to be able to put protein FFs through for rosemary benchmarking

      • JH – might need two pathways to support this? One through SystemGenerator and one through OFF Toolkit

      • or – meeting tomorrow with John to discuss AFAICT

      • MH – that discussion will help to identify optimal path; might make more sense to not bother with openmmforcefields, use interchange instead

        • may also conclude that we can get this functionality through openmmforcefields, but need to assess limitations

      • JW – want to join that discussion

        • interchange may be too strict for a start, but would like to assess suitability

      • (MH invited JWagner+MThompson to discussion tomorrow.)

  • IP : Protein-ligand benchmarks working group update

    • ran all transformations in benchmark dataset (356) with perses REPEX

    • out of these, 326 run without issues

    • IA – also performed these tests on alchemiscale; meet with HB and I next week to go through your results?

      • IP – yes, let’s do it

    • IA – I’m not convinced that the MSTs created are amazing - I’m going to talk with Hannah about looking at different networks. TYK2 is coming out with some not-great results for me which is strange.

    • IP – expected MSTs to not give amazing results; used as a starting point

    • IA – This is a significant degradation compared to LOMAP score which were in the 0.9s. So while Hannah’s learning the ropes this could be a good informative exercise.

    • DD – More details?

    • IP – We wanted to get a network, make a release, and then start with that.

    • DD – I see, so you want to get a cadence for making releases and adding/dropping systems, etc?

    • IP – Exactly, we want to build some momentum to jump start the task force. I have to reach back out to some industry folks who were interested.

    • IA – Re: PLB - Working on cinnabar - There’s utility in PLB for converting between exptl values and delta G. I’m not convinced that this is best placed in the PLB. My current thoughts are cinnabar or openff-units. Talked to MT and he’s ambivalent.

    • DD – This is handy

    • IA – Where should this go? Openff-units? Cinnabar?

      • DD – Cinnabar sounds good

      • IP – Openff-units would make sense

      • JW – I think cinnabar, wiht openff-utils as a second place

      • DD – Would this need to move in lockstep with cinnabar?

      • IA – It does have most to do with analysis of PL systems. But cinnabar would use openff-units.

      • JH – Cinnabar would make the most sense.

      • JW – Maybe PLB is the right place?

      • IA – Our thinking was that PLB would have ligands and proteins, so it’d be lightweight/data-only. And we need this soon.

      • JW – How is one of them faster?

      • IA – PLB has lots of data decisions tied up in release process. CInnabar is under heavy pressure for release.

      • DD – I think cinnabar is a good choice.

      • IP – Some question about dep direction

      • DD – Seems like a question of whether cinnabar should be a dep of PLB, or vice versa.

      • IP – Once task force is moving, we can revisit. Right now it makes more sense as cinnabar

      • IA – Gotcha. I’ll make a copy of this in cinnabar.

      •  

    •  

  • alchemiscale development : new sprint begins 7/26, runs till 8/7

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

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

    • alchemiscale 0.2.0 milestone:

    • alchemiscale 0.1.4 milestone:

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

      • In review

        • DD – PLB 93 is ready for review?

          • IP – Yes

        • DD – alchemiscale 157?

          • MH – Ready for review. Kinda spilled over in scope.

        • IP – Perses 1066 should be ready for review

          • DD – Updated

      • In progress

        • DD – Alchemiscale 28 - User guide - I’m pulling together materials. Will be making its way into sphinx docs. Last night IA shared a great notebook with me about this. It’s wonderful - Thanks a million, IA!

        • DD – Alchemiscale 30 – Have to add some deployment docs about compute services. I’ll ping you, MH

          • MH – Sounds good.

        • DD – Alchemiscale 130 - Backup solutions - MH, I’ve done some backups myself, want to pass this to me?

          • MH – I haven’t made much progress on this. Could you send me your notes? I don’t know how to do this in a docker compose file. Will need an external program to trigger actions. Some doubts about state management.

          • DD – Yeah, I think we’ll just document a “here’s how to manually backup”, and we’ll let the people who are amanging the deployment figure out how to trigger them.

        • IP – Test noneq protocol against repex protocol - This is related to my earlier comments about running the whole dataset. Still in progress, we’ll meet about it next week.

        • DD – OMMFFs 288 marked as in-progress.

      • Available

        • DD – I want to finish up user story review for OpenFF and ASAP. These were submitted months ago. So I want to look back and see what the remaining gaps are and how to prioritize effort.

        • DD – Alchemiscale 132 and 138 - Some stuff I wanted to get into previous milestone and will try to finish in this one.

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

  • LN – Nothing to put on the agenda - But two updates

  • MH – I made a PR on QCF fixing a thing with qcportal/pandas.

    • LN – I’ll talk to BPritchard about this.

  • JW – Also numpy 2 is coming in Dec/Jan. c-f recipes mostly implicitly pin this, but folks on pip may want to proactively downpin.

Discussion topics

Notes

Notes



Action items

@David Dotson will issue @Mike Henry a compute identity for testing on OSG

Decisions