2024-02-06 alchemiscale : dev group meeting notes

DD : alchemiscale roadmap

• Q1 : complete “living networks” performance improvements

  • remove py2neo, replace with official neo4j python driver

  • optimize compute claiming code path

• Q1 : Folding@Home compute services deployed in production

  • finish MVP, with integration test suite by 2024.03

  • perform FAH tests with volunteers during 2024.03

    • public work server up by 2024.03.15

    • confidential work server up by 2024.04.01

      • JW – What does F@H think about running confidential/proprietary sims?

      • DD – We discussed this at JC lab in-person. JC and Sukrit plan to communicate with F@H volunteer base and we’ll use a separate work server for public vs. confidential work. (lots of minor details, see recording ~18 mins)

      • JW – Ok, sounds good. I trust your judgement.

• Q2 : develop Strategy structure, initial implementations

  • DD – RG, is the plan for strategies to live in cinnabar?

  • RG – I don’t recall this decision, but it could work. Cinnabar networks don’t know how much time a sim has been run for or how much effort has been applied by other metrics.

    • IK – Would depend on the type of strategy?

    • RG – Yeah, but you might want to do like forwards and backwards aanlysis to have more info.

    • DD – Would it make sense for us to start developing strategies as a separate package initially?

    • RG – It’d probably be best to do it separately at first, until you know what needs to be accessed and to keep deps minimal for our production package.

    • DD – Ok, that makes sense.

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

alchemiscale development : new sprint spanning 2/7 - 2/20

• architecture overview : PL Benchmarks on FAH - Architecture v6.drawio

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

IK : KeyedChains in gufe?

• (see recording ~23 mins)

• IK – Early on, serialization and deserialization optimizations were important to send objects over internet. Early on, we did to_dict and encode to JSON. But that didn’t hold up when we had thousands of nodes (TYK2 was 250MB serialized in this way). To solve this, we make a keyedchain representation for GUFE tokenizables. This makes a shallow dict, build out the network, does a topolical sort using networkx, … and this makes a minimal representaiton of a GUFE tokenizable that’s good for sending over a network. Is this worth upstreaming?

• RG – Ah, so this is a network representation of keyed dicts? This is cool.

• IK – One added feature is that this stores the key with the object info. So even if you’re running a different version of gufe, you should theoretically be able to build it back up. This is in alchemiscale as KeyedChain.

• RG – This would be good to upstream. Does this have tests? I can help improve coverage if not.

• IK – I have some tests. Will open up a PR and we can progress this.

• (technical discussion, see recording)

• JW – How do I know good patterns around circular references?

  • RG – Maybe writings about the python garbage collector?

  • MH – I think maybe “forward references” and “back references”?

  • RG – Also weakref module in PYthon, and some kind of funky pointers in C++.

  • DD – We’ve made a decision to not have circular references in alchemiscale

  • (Technical discussion)

•  

•  

•