DD : alchemiscale roadmap Q1 : complete “living networks” performance improvements Q1 : Folding@Home compute services deployed in production Q2 : develop Strategy structure, initial implementations Q3 : enable automated Strategy execution by end of Q3, 2024 (2024.10.01) JW – For my ad board update - alchemiscale 0.3 is out? and what is alchemiscale on F@H versioned as? And OpenFE/GUFE compatibility? DD – 0.3 is indeed out. 0.4 is next major milestone. Alchemiscale fah 0.1 is targeted for march. OpenFE/GUFE updating isn’t assigned to a date/tag yet, I’ll need to see how that rollout goes and how many changes are needed on my end, but for now it’s not attached to a date/version.
alchemiscale development : new sprint spanning 2/21 - 3/4
RG : dropping an RC for openfe;. We’ll be trying to break it / doing QA for the next few days so don’t worry about updating alchemiscale. I think it’s code-complete, but we’re going to put some sims through. Migrations aren’t in currently, so that may be tough. I don’t think we’vebrooken much of the API, it’s more that we’ve changed data structures and less function signatures (if at all). I think our testing plan is that MH will spin up a local alchemiscale to do a smoke test. So that should reveal API snafus. RG – Made openfe-skunkworks. THat’s where we’re hiding things when we make the 1.0 release, andit’s a public indication that it’s unstable. MT is going to put his solvation free energies there. MO will be playing with charge models there. That’s also where we could put early Rosemary support. So you might hear about “skunkworks”, and that’s where our dev code will live. So you might need to install both repos to use new/experimental things. DD – Great, this is exciting. IK and I are looking at ways to make deployment faster. How often will I need to rebuild with this? RG – Weekly-ish maybe? Could also automate like nightly releases. How complex is it to update packages in your deployments? DD – Academic center clusters will be complex. But kuberenetes clusters will be happy/easy to redeploy. What we could do is, if this is never intended to be conda-deployed, this could always be pip-installed. Then we could just pull from main. … RG – … Thanks for the dieas about deployment, we’ll let you know once we have more details. But this is mostly an FYI, so now you know about the skunkworks repo.
RG – My guess is that major progress will happen here in the next few weeks, though I can’t speak for MT’s timeline.
DD : doc builds broken. MH, could you take a look? MH – Ah, right, I’m supposed to do this. We can change the config to allow builds with warnings. Right now it’s treating warnings as errors, and we can turn that off. (DD turns off warnings-are-errors live in meeting) MH – I’ll come back and clean this up so we don’t have warning in the future.
DD – Are there plans for an FEFlow release in the future? MH – IP would know. I think we’re a little bogged down in some details and I’m not sure that the release has an ETA. Some things depend on when the openfe/gufe release goes stable. … DD – Ok, I’ll move forward with feflow’s main branch as it is now while the chodera lab team is working on next release. I'll drop perses from our builds from nobody's using noneqcycling protocol (though I may do a quick check to verify that). DD – Any interest for me to attend feflow/OpenFE meetings? MH – I don’t think so… unlikely to impact you. Though maybe it would be nice. DD – There are a few things where we might be helpful/needed, especially since this could unblock depends support
|