2024-01-30 alchemiscale : user group meeting notes

alchemiscale.org

• user questions / issues / feature requests

  • JS – Not a question, but thanks for everything you’ve done for ASAP alchemy. Had an issue where we were starting with docking results and ligands didn’t have names, this passed through alchemiscale/openfe just fine, but we had downstream issues. DD helped us out with this.

• compute resources status

  • 87k protocoldagresults complete.

  • Currently looks like a few dozen OpenFE calcs, and single-digit nums of ASAP

  • IA – Would this be a good time to update to new OpenFE since there are so few jobs running?

    • JS – Are there breaking changes in OPenFE 0.15?

    • IA – Some new settings, so serialization might break

    • JS – Go ahead and update and we can deal with consequences later.

    • DD – I’ll do a QA check before doing the full migration, and I’ll let you know if there are issues.

• current stack versions:

  • alchemiscale: 0.3.0

  • gufe: 0.9.5

  • openfe: 0.14.0

  • perses: protocol-neqcyc

  • openmmforcefields: 0.12.0

    • RG – using pydantic 1 or 2?

      • DD – Pydantic 1, we have an open PR (#152) to update but CI is hanging and I haven’t debugged.

      • RG – Gotcha. I was hitting some weird docs errors updating to pydantic 2. So glad to know that you’re not updating in a rush.

      • DD – Ok, let me know your timeline when you do move toward upgrading.

    • DD – Should now be able to submit very large networks (thousands of nodes+transformations). Let me know how this works if anyone tries it.

      • JS – I haven’t done this yet but I’ll report back if

    • IA – Which version of OpenFF Toolkit?

      • DD – This would be in devtools/conda-envs and then server or compute…. but there aren’t any explicit references to OFFTK… Let me spin up a job and check.

      • RG – Our recipes are pinning to 0.13 or 0.14, I think?

      • DD – The server env solves to 0.13.2. I’ll look into this.

      • IA –

      • MH –

        

JW – Status of F@H implementation/prototyping?

• DD – This lives in alchemiscale-fah. I was on-site at chodera lab last week. It’s been a long-running PR with a lot of pieces. The FAH interface is likely to be as complex as the entire original codebase. Needs to talk between alchemiscale work server and FAH work server, handle connection interruptions and other failure modes in both.

• JW – Do you have any external blockers/are you limited by docs or technical access?

• DD – No external blockers, just a lot of work/complexity to handle. Will need to mock F@H server which itself is quite complicated.

• JS – Do you have access to their devs?

• DD – Yes, I’m taking with joseph coffland (alchemiscale-fah issue #1). He’s being very helpful. It’s just very complex.

IA - addition of experimental FE repo (when it’s ready). We’ll need to have an experimental repo so that Meghan can run with different partial charges. Can run at UCI, but it’d be helpful to be able to run with a more heterogenous compute mix. What would be the process of adding new packages to server/workers? I doubt you want us to be throwing additional repos at you since that puts complexity on your plate.

• DD – I assume you’ll be doing local prototyping first, and then you’ll come to me to add it to alchemiscale to test on broader compute. Will it be on C-F or github?

• IA – Probably GH initially.

• DD – Ok, you can just let me know by direct message the first few times. Then we can develop a process and determine the appropriate QA tests.

• JS – IA, could you elaoborate on experimental FE repo?

• IA – It’s not to replace feflow. It’s more of a staging ground to test things. Not sure about long-term future, but initially this will be a place for testing partial charge alternatives.

• JS – If it becomes a place open to external contributions, we could port some non-confidential ASAP stuff to live there

DS – Updates on PLB – possibility of moving? Wearing my POSE lead hat. Everyone is tired of the PLB repo. OpenFF doesn’t want to curate moving forward, OpenFE doesn’t want to take over curation. It seems like one solution would be to move it to the OMSF org.

• JW – This is a correct interpretation of OpenFF’s interests. We’re interested in a bookmark being available at this URL that can help people find the dataset associated with our paper.

• IA – Since this repo is being used by other folks, this will need to be clearly communicated publicly.

• IA – This also doesn’t address what OpenFE is doing. We don’t want to take on running a release.

• DS – We don’t really need a release, a tag would be fine.

• IA – There are things outside the data that require resolution, HB and I can’t take this on. We’re willing to release our structure, not maintain a release. Let’s discuss elsewhere.

• JS – If it’s moving to OMSF, then OMSF is bearing responsiiblity/taking blame. Are there personnel allocated for maintaining/curating this?

• DS – I’d actually be interested in having it in its own org to avoid curation/maintenance expectations.

• DD – Is there a risk that this gets parked and forgotten?

• DS – I think that’s the current state.

• DD – A few months ago, JC presented an idea for the PLB to be less focused on the contents of the set and more on the process for curating. Possibly linked to blinded challenges. Could we move PLB to the OMSF org or a new org that can be picked up by this initiative once it gains steam.

• (general) – Future of IP’s working group?

• DS – I’ll broadcast this plan on the relevant slack channels.

• DD – And I think it’s reasonable to say that things will be unmaintained unless resources are allocated to funding it. If there’s backlash itmight motivate folks to kick in resources for maintenance.