Q1 : Folding@Home compute services deployed in production
finish MVP, with integration test suite by 2024.03 2024.05
DD – Hard because we need to mock the F@H work server. Using lots of fastapi to make this mocked server. Testing at different layers - executedag is the low level, then network operations are at a higher level. Also requiring changes in alchemiscale itself, I have an open PR based on allowed protocols. Also working on improved task claiming.
this is delayed; need an additional 2 weeks to finish this out
JW – That’s OK by me.
perform FAH tests with volunteers during 2024.04
DD – Initial deployment will just be on alchemsicale dev host. Then I’ll roll out to public compute more.
IP – Does this require feflow to deploy?
DD – Yes, I’m installing feflow from source in my development branch now.
IP – Ok, I’m checking the PRs from time to time to make sure things are progressing. Please let me know if anything needs my attention.
public work server up by 2024.03.15 2024.05.01
confidential work server up by 2024.04.01 2024.06.01
DD – Some details need to be coordinated with ASAP, this is in progress
Q3 : enable automated Strategy execution by end of Q3, 2024 (2024.10.01)
MH : status of openfe + gufe 1.0 testing
We’re happy with the results we’re getting wiht PLB benchmarkls. Just got some charge change benchmark data. IP do you have any runs involving this? Our results look fine but we’re curious if anyone else has run this. A few outliers but we think it’s due to mapping. Things are moving along and now it’s in RG’s court (benchmarks aren’t a blocker).
RG – Yup, expecting to mint a release by the end of the week.
IP – I do have some CDK8 runs from months/years ago. I don’t think we need to worry about that too much.
MH – Gotcha - HB would still love any data you can share. Still have some charge change jobs running to keep checking.
DD – Great. Once openFE and GUFE 1.0 are out, we can initiate another deployment smoke-test.
IP: feflow needs
Not much to update on here - We’re waiting on 1.0 releases. Will unblock PR #38 (support for 1.0 release). Also blocking a few other changes.
MH – Could you test against the OPenFE RC?
IP – Yeah, we’re testing with the RC. Just one failing test but it’s a negative control. Talking with IA about how to interpret that.
IP – I’m working on protein mutatioin protocol/how to do residue mapping (feflow #7). We’ll probably be using PDBFixer to do mutations and help with mapping. Hoping to make progress on this in the following week.
IK – (feflow #44) I’d love to be able to get my tests to run, just working from a fork now. My PR should be good to go, just works with GUFE serialization. https://github.com/choderalab/feflow/pull/44/files
IP – Wanted to mention that the way we’re extending things involves a lot of things that should be minimized by abstractions at other levels. Currently there’s a lot of “if extension is an instance of X” stuff. For developers they’ll want to know whether there’s an extension in their code path.
MH – It’ll be really good to have this done, then retrospectively look at it any think about refactoring. It’ll be easier to do a design/refactor iteration on it once we decide on the behavior.
…
JW – Who makes this decision. Does feflow have a defined owner?
IP – It’s me right now, but we’re planning to move it to openFE at the 1.0 release.
MH – It’s complicated because of how openfe does releases.
…
DD – Re IP’s earlier comment about finding “extends” logic that works across protocols, the behavior of extends in different cases its likely to be quite different and complex.
IK – Agree that this isn’t an easy problem to generalize.
IP – Please tag me for review when you think it’s ready!
alchemiscale development : new sprint spanning 4/17 - 4/29