Page Comparison

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

  • perform FAH tests with volunteers during 2024.04 2024.06

    • public work server up by 2024.03.15 2024.06.11

    • confidential work server up by 2024.04.01 2024.07.01

      • DD – HMO reached out and offered to help on this, since he’s already done some encryption stuff for F@H.

• Q2 Q3 : develop Strategy structure, initial implementations

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

    • DD – Not an alchemiscale things, actually an OpenFE ecosystem thing.

    • IA – Do you have a layout of the plans here? We’re hoping to hire someone to take on OpenFE infra and could have this person work with you on this. Would help them by giving them hands-on experience with the codebase.

    • DD – Yeah, happy to talk about this.

    • IA – Let’s discuss in feature/future meeting with JEastwood.

    • IP – I think IA’s point is to have a pair of hands on the infra. Particularly in cinnabar (will need added flexibility to fit this implementation).

    • IA – Was planning to have a call with interested parties on cinnabar in the coming weeks. Anyone interested?

      • DD + IK + IP - please add us

      • IA – And I expect JScheen and JHorton will want to be involved as well.

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

  • DD – May need to move this back to Q4, but will wait until we get closer to make this call.

IP: feflow needs

• IP – IA, I need your review on following PR:

• will need feflow to support openfe + gufe 1.0 to use FahNonEquilibriumCyclingProtocol

  • Github link macro
    link https://github.com/choderalab/feflow/pull/38

  • IA + IP – These results were in the OpenFE keynote and looked pretty good, so should be solid.

  • IA – I might be able to have HB review this in the coming days, but if it works it works.

  • IP – I have some Qs in the PR that are significant.

  • IA – Either HB or I will get to this.

  • IP – Also happy to hop on a call about this.

  • IK – Once this is all merged, I’ll review the cycling extensions.

  • IP – This is blocking some downstream work so it’ll be good to resolve this as soon as possible.

• IP – I also need to clean up the milestones, they don’t reflect current state.

alchemiscale development : new sprint spanning 5/29 - 6/10

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

  • IK – I’ll take care of alchemiscale #275 this week

  • Github link macro
    link https://github.com/openforcefield/alchemiscale/milestone/12

  • DD – As a reminder, re the migration to 1.0s, the plan was to keep the old server up for a limited time, but to eventually shut it down in favor of the new one. There was some discussion about migrating old data into the new schema but this was deemed impractical. This is because the new versions will have schema changes.

  • (Discussed some technical details, new server will need new versions of deps, will have different URL, there will need to be an info campaign to tell users about this)

  • IA – And DS had put together a forward migration strategy starting at version 1.0.

  • DD – And we can have a larger discussion around the alchemiscale retention/migration strategy in light on this mving forward.

  • IA – One thing we’ve discussed before is that there’s a need at OpenFF and OpenFE to put benchmark data somewhere public.

  • JW – Should we have discussion now,or with JE?

  • (General) – We can sketch out some details of solution now without committing FTEs

  • DD – I was thinking I could add an API point to exprt ezenoodo uplaodable tarballs

  • IP – Does it make sense to allow people to query live public alchemiscale databases? Instead of going through zenodo?

  • DD – Not feasible, it’s a massive security risk to allow neo4j queries. That’s why we put this behind an API severice.

  • IA – OpenFE’s been thinking that .. . we considered the idea of storing alchemi… to match gdrive, we want a json file with software provenencce, every edge w/ deltag and errorbars, and version of the PLB.

    • JW – I don’t want to offer a multi-tiered cake of options; every layer we have to maintain would be more work; find appealing an API point that dumps something (even large) that can be dumped on Zenodo

      • makes it a quick and relatively easy operation to create archival extracts

  • IP – I like that approach, I’m not that familiar with zenodo. Would this require an intermediary server/user to download from alchemiscale and upload to zenodo?

  • DD – Yes, there would need to be a user in the middle.

  • IP – In that regard, maybe one way we can automate it is using GH actions.

  • DD – I’d hesitate to automate this since it’s unclear what people want and when things are important artifacts/experiments.

  • IA – Agree, not everythings important and zenodo might get miffed if we’re constantly uploading big things. My thinking for probably best pathway is to have user manually choose to perform this process. My main concern is whether the alchemiscale network has everything you need.

  • IK+DD – Would need network describing the problem, results, maybe metadata. Re: “this used X version of the PLB” - …

  • IP – Does alchemicale network have ligand chemistry information?

    • ?? – Yes

  • IK – Results are stored by reference in neo4j?

    • DD – Attached to task objects

    • (see recording, ~34 mins)

  • IA – mappers don’t remember thei

• 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