Page Comparison

alchemiscale.org user group

• user questions / issues / feature requests

  • DD : hif2a issues resolved?

    • MO – I reran the whole thing, not just the subset. I was able to replicate some of the 2.5-2.9 kcal/mol errors. I just got those results this mornings, will pull down those edges and check them out this morning. I’m also doing some local runs with solvent (which HB said do really poorly) and I haven’t replicated the errors.

    • DD – Ideas for next steps?

    • MO – One of the ligands is a sulfone intermediate - Maybe we should switch to Sage 2.1.

    • DD – So, no indication of error in 12 runs?

    • MO – Right.

    • MO – There’s also a gist on GH with some code that may have worked fine, so I may make a backdated env with old OpenFE and see if I can replicate that.

    • JS – Has anyone gotten good results for hif2a?

    • MO – Ana Calderuse in Mobley lab ran using septop and got fine looking results

    • JS – Maybe an inherent issue with the method?

    • MO - AC ran a monomer version of hif2a. But HB ran a dimer version. JC said it’d be fine to run as a monomer. We different people have run it in differnt forms, and also the monomer vs. dimer ones had different protonation states.

    • JS – Interestingly, I recall JC saying to run it as a dimer.

    • MO – I think IP was going to try running it as a monomer at JC’s suggestion.

    • DD – Context from OFF slack: https://openforcefieldgroup.slack.com/archives/C02GG1D331P/p1695747313085039

    • JS – MO, if this continues being a problem, I’m happy to do some runs/pitch in.

  • MO : ambertools charging issue - We found a workaround for the issue that my labmate was having and I sent JW a writeup. I did see some issues in the local runs, and it clears after the 4th or 5th retry.

    • JW – Yeah, thanks for the writeup. I’m hoping it a node-specific/slow filesystem thing that will be resolved externally.

  • JS : asap-alchemy analysis of results from alchemiscale execution

    • https://docs.alchemiscale.org/en/latest/tutorials/demo/Alchemiscale%20Demo.html

    • JS – Root cause of the problem was that the ligand name wasn’t standardized in cinnabar - In one place it had a _1 suffix and in the other it didn’t.

    • DD – We should see if we can make the corrective change in cinnabar - I think IA manages that

    • JS – But overall good news, we’re seeing a correlation. Hoping to submit a whole ton of alchemiscale jobs in the next ~month. Will you need advance warning?

      • DD – No need to warn me. Just be aware that you’re on lilac so that may get saturated.

      • MH – I think we’re just waiting on JC to approve running on OSG, then we should have plenty of compute. So if it runs slow, just ask JC if you can spin up workers on OSG. It may be good to ask for pre-approval so that I can just “flip the switch” and get you runners on OSG.

    • JH – Question about new OMMFFs release. Want to try out bespoke FFs on alchemiscale.

      • DD – Sure, I’ll deploy new OMMFFs. 0.12.0.

      • DD – GUFE 184 is the issue that anchors this whole discussion. IA just commented that there may be more to do for gromacs but this should be ready for bespoke FFs.

• compute resources status

  • DD – Hundreds of workers on Lilac and PRP, feel free to submit more.

  • JW – More workers than jobs?

  • DD – Yes, I periodically scale things down, but on kubernetes there’s no way to only kill idle workers. We’re running on low priority so PRP admins don’t complain much.

• current stack versions:

  • alchemiscale: 0.2.1

  • gufe: 0.9.4

  • openfe: 0.13.0

  • perses: protocol-neqcyc

    • DD – We’ll eventually drop perses from this deployment in favor of feflow. That should be a place for forked perses functioanlity now in OpenFE to come back, and a lightweight way to collect protocols.

    • MH – Right, we’re trying to find a way to make things lighter-weight.

    • DD – IP got the noneqcyclingprotocol merged in, and made it independent of perses (instead dependent on OpenFE). Once we have a 0.1 release of feflow we’ll swap it in for perses.

alchemiscale development : current sprint spans 10/11 - 10/23

• 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

  • call for volunteers for available issues

• alchemiscale 0.3.0 milestone:

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

• alchemiscale-fah: 0.1.0 milestone

  • Github link macro
    link https://github.com/openforcefield/alchemiscale-fah/milestone/1

• review Completed cards

  • DD – IP finished feflow 1 - Thanks IP!

  • DD – PLB 93 is still in progress, but nobody on this call can update status.

• updates on In Review, In Progress, and Available cards

  • DD – alchemiscale fah 1 - I’m working on this. Hoping to have a protocolunit that lives on F@H and distributes tasks to workers. Have some questions for JC about data models and other things.

  • JS – Are we planning to serve repex on F@H? I know we have noneqcycling currently and that’s due to architecture constraints.

  • DD – We are, we’re aiming to get two protocols on this - noneqcyc and times square sampling (which I think is related to repex, maybe it s a “SAMS” implementation).

  • JS – I’ll look into that… I’m not familiar with times square sampling. Do you know why times square instead of repex?

    • DD – I’d previously asked this group which one to go for first, answer was noneqcyc first, and then as a second pick we did times square sampling. (same as self adjusted mixture sampling (SAMS)). The reason we’re doing two is to make sure our architecture can accomodate a variety of protocols. JC was going to work with IZ to figure out the science of this. I’ll raise this as an issue on feflow.

  • DD – feflow 3 - Changing noneqcycprotocol to be a little more modular - this will give us a more natural interface for F@H architecture. I’ve got a prototype in this PR.

    • (DD walks through some architecture of the F@H adaptor, see ~35 minutes in recording)

• Availalbe

  • Alchemiscale 136 - I’ll spin this into smaller more digestible issues

  • DD – Anyone interested in any of the available issues on the board?

DD : gufe#184 - openmmforcefields next release?

• (OMMFFs had the 0.12.0 release)

IP :

• Protein-ligand benchmarks working group update

• Protocols migration to

  Github link macro
  link https://github.com/choderalab/feflow

• (IP not present)

JW – We’ve not had quorum for many meetings. And I’ll break quorum by being out all november. Is the governance structure useful? Should we not require everyone to be present? Should we grant JS voting power?

• (See recording, ~40 minutes)

• (General) – Would be good to rethink voting/project management structure.

• JE will ping OpenFE to send a delegate next week

• JS will see if he can get JC to attend next week