2024-06-25 alchemiscale : dev group meeting notes

DD : alchemiscale roadmap

• Q1 : complete “living networks” performance improvements

• Q1 : Folding@Home compute services deployed in production

  • finish MVP, with integration test suite by 2024.03 2024.06

    • DD – This has been completed, will also spin up dev host shortly. See Alchemiscale-fah #7

  • perform FAH tests with volunteers during 2024.04 2024.06

    • public work server up by 2024.03.15 2024.06.11 2024.07.08

    • confidential work server up by 2024.04.01 2024.07.01 2024.07.31

    • DD – I’ll coordinate with F@H volunteers on slack to get them to start pulling jobs from experimental host.

    • JS – Great to see this making progress. Are there any blockers at the moment?

    • DD – Only blocker is feflow-openfe-gufe compatibility, which has made serious progress (or is done?)

    • IP – Almost, big thing here is charge handling PR.

  • JW – Since we have so much unused capacity, I’m going to encourage the science team to start running FE benchmarks more regularly so that we get more practice.

    • DD – Good idea, lots of

  • IP – We’re going to put in user? charge tests, this requires self-hosted runners. For now we have our own solution using AWS, but we’re planning to adopt POSE’s solution for self-hosted runners. It’s compute-heavy so we need GPUs.

    • DD – Instead of trying to calculate a whole protein-ligand complex, could you try like a solvent sim?

    • IP – Not quite.

    • JW – Is this regarding user/antechamber charge consistency?

    • IP – This is about testing the science - We’ll have pre-set charges on our test systems, this is about testing the free energy METHOD as we make changes to the codebase.

• Q2 Q3 : develop Strategy structure, initial implementations

  • aiming to begin design 6/26 7/10 sprint, followed by MVP development during July

• Q3 : enable automated Strategy execution by end of Q3, 2024 (2024.10.01)

IP: feflow needs

• Charge handling

  • IP – We support the API for GUFE and Openfe 1.0. This should unblock alchemiscale-fah #7. Not sure if other changes will trip things up.

  • DD – The big change we needed was the addition of some parameters to getState (feflow#45). Are we blocked by charge changes?

  • IP – I don’t think so, but we need to check against Ian’s PR (feflow #44).

  • DD – I don’t think #44 (extension support) is a blocker.

  • DD – Do we need feflow#49 to handle user charges?

  • IP – That should already be happening. #49 is more about specifying partial charge method (like, OE vs sqm vs. nagl, etc). This also supports net charge changes.

  • DD – Gotcha. What we want to encourage users to do on F@H is to have people pre-charge your systems, otherwise the charges may not be deterministic. That’s in place without #49, right?

  • IP – Right

  • DD – Ok, great, then I don’t think #49 is a blocker.

  • JS – We’re doing partial charge assignment ahead of time at ASAP. There are a lot of warnings emitted by the openfe toolkit when we do this. JHorton has resolved these warnings. (basically, if you set user partial charges on an openfe molecule, then any operation you do on the molecule subsequently emits a warning. JHorton has figured out how to disable these warnings). These warnings kinda happen outside alchemiscale, rather when we interact with openfe/gufe directly. We get that warning spam both before submitting the networks and when fetching results)

    • JS (chat) – Warning is Partial charges have been provided, these will preferentially be used instead of generating new partial charges', the fix is https://github.com/asapdiscovery/asapdiscovery/pull/1080/files

  • IP – Right, I think that warning was coming from OpenFE. Was this related to user charges being disregarded?

  • JS – No, the partial charges being disregarded was different.

• Self-hosted runners for validation or sanity tests

alchemiscale development : new sprint spanning 6/26 - 7/8

• aim is to complete 0.4.1, deploy to alchemiscale.org, including openfe + gufe 1.0:

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

• coordination board : alchemiscale : Phase 3 - Folding@Home, new features, optimizations, targeted refactors

JS – IP, with noneqcycprotocol almost ready to use via alchemiscale, is there anything we’ll need to change fundamentally in our approach? I know you’d normally run a longer equilibration before starting off FE calcs, is that handled automatically?

IP – In the protocol, you specify equilibrium and noneq steps. You specify how many steps you want each of those to be. But I suppose we expect the initial states to be somewhat equilibrated, since you do many parallel cycles (you don’t want them to drift too much in conformation)

JS – If you have your equil stages, we could run that on alchemiscale wihtout needing to make chagnges on our side. With equil sims being run for A and B, if there’s also a transformation from B to C, will that reuse the equil sim for B?

IP – I don’t think it’d be reused

DD – The tasks are independent and so it wouldn’t be reused. The A-B transformation can’t access the B-C transformation info. This is a little wasteful, but it’s really hard to do - kinda a limitation of gufe data model and alchemiscale (since we don’t ship around trajectory data)

IP – DD, would it be possible to write a protocol that takes result units from other things and pulls that in?

DD – The GUFE data model is pretty flexible, but I don’t think that’d quite work in the alchemiscale framework since it’d need to shuffle a lot of data around. Exorcist tries to handle this since it assumes it’s on a single HPC. But I can’t think of an easy way to make this work within alchemiscale.

(see recording ~38 mins)

JS – Would be handy to be able to extract the simulation coordinates at the end of the equil stage for debugging. Currently hard to debug weird-looking edges.

…

IP – I have some funcitonality in feflow where we could export the trajectory file path.

DD – I don’t think we can do much with a file path - we’ll need the final frame itself. Could you open an issue to export the final frame in… Oh wait, this might be part of the extends support that IK is implementing.