Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Participants

Recording: https://us02web.zoom.us/rec/share/tLvlm2sDGiqe61ZsbFRBlqRGphNekEPjpunvl7X2Hf6BHUUDDncMq6Dn1P_016w.mepV5UcGRmzWqmq1?startTime=1711468924000

Goals

  • alchemiscale.org

    • user questions / issues / feature requests

    • compute resources status

    • current stack versions:

      • alchemiscale: 0.3.0

      • neo4j: 4.4

      • gufe: 0.9.5

      • openfe: 0.14.0

      • perses: protocol-neqcyc

      • openmmforcefields: 0.12.0

  • DD : new proposed stack versions for alchemiscale.org ; awaiting results of QA tests on gufe + openfe 1.0rc1

    • alchemiscale: 0.4.0

    • neo4j: 5.16

    • gufe: 1.0

    • openfe: 1.0

    • feflow: main

    • openmmforcefields: 0.12.0

  • DD : proposal since still waiting on openfe + gufe QA:

    • alchemiscale: 0.4.0

    • neo4j: 5.16

    • gufe: 0.9.5

    • openfe: 0.14.0

    • remove perses

    • openmmforcefields: 0.12.0

  • DD : production issue: exhausting neo4j threadpool on alchemiscale.org due to large AlchemicalNetwork on asap-public-*; need to release and deploy alchemiscale 0.4.0 ASAP

    • may be able to up thread count as workaround, but not ideal

Discussion topics

Notes

  • alchemiscale.org

    • user questions / issues / feature requests

      • JS – Status on HPCs?

      • DD – All of Iris, Lilac, and NRP are up.

      • JS – I submitted a bunch of jobs last night and none of them progressed.

      • MH – Maybe Iris problems?

      • DD – This relates to issue in production. The current network has 6k tasks. What we’ve seen is that if there are more than 2k tasks on a network things get clogged up. This is fixed in alchemiscale 0.4 but that’s not deployed yet. So my goal is to release and deploy 0.4.

      • JS – Will we need to resubmit?

      • DD – Nope.

      • JS – Ok, the urgency on this new dataset is super low. This one is using living networks, running 40-some compounds fully connected. I submitted it to be 0.5 (default weight) and my later submissions will be set higher.

      • DD – Could you set your network weight down to 0.1? This will keep it from cutting in line for default submissons.

      • (DD will set network weight down to 0 , will bump up from 0 after alchemscale 0.4 release)

      • (see recording ~8-15 mins)

    • compute resources status

      • DD – All clusters online, plenty of throughput available.

    • current stack versions:

      • alchemiscale: 0.3.0

      • neo4j: 4.4

      • gufe: 0.9.5

      • openfe: 0.14.0

      • perses: protocol-neqcyc

      • openmmforcefields: 0.12.0

  • DD : proposal since still waiting on openfe + gufe QA:

    • alchemiscale: 0.4.0

    • neo4j: 5.16

    • gufe: 0.9.5

    • openfe: 0.14.0

    • feflow: main

    • openmmforcefields: 0.12.0

    • IA – May need IP to weigh in here.

    • MH – You may need to use a commit of feflow to work with alchemiscale… I changed it in (MH was confused)

    • DD – We might need to hold off on feflow? Then just roll out alchemiscale 0.4. Then stick with old OpenFE and gufe and drop Perses. Noneqcyc will be in feflow in the future. So there will be a deployment for a little while that can’t do noneq cycling.

    • JS – Will first release with noneqcyc coincide with the first F@H-capable release?

    • DD – Yes. F@H will need to use noneqcyc so that won’t run until feflow is out.

    • DD – Any objections to upgrading alchemiscale to 0.4?

      • JW – MO, are openff-2.2.0 benchmarks complete?

        • MO – The 2.2.0 runs are complete, rerunning 2.1.0 but those are just nice-to-haves.

      • JW – DD, would changing alchemsicale version and keeping openfe+gufe versions the same change numerical results?

        • DD – No

    • DD – Ok, I’ll go ahead with this plan

    • JW – Also, happy to turn any extra NRP compute to OpenFE to do their benchmarks

      • MH – Would prefer to keep our compute homogenous for the benchmarks, but thanks.

  • DD : new proposed stack versions for alchemiscale.org ; awaiting results of QA tests on gufe + openfe 1.0rc1

    • MH – Validation still ongoing. Likely still 1-2 weeks of runtime needed. Realized that I never tried making a PR into ASAP-alchemy repo to see if it’s compatible. I was running on Iris and lost everything once it had tech problems.

    • .

    • alchemiscale: 0.4.0

    • neo4j: 5.16

    • gufe: 1.0

    • openfe: 1.0

    • feflow: main

    • openmmforcefields: 0.12.0

  • DD : production issue: exhausting neo4j threadpool on alchemiscale.org due to large AlchemicalNetwork on asap-public-*; need to release and deploy alchemiscale 0.4.0 ASAP

    • may be able to up thread count as workaround, but not ideal

  • JS – Looking to run aqueous solvation free energies. Anyone have recommendations for python tools?

    • IA – Chemaxon has a logS tool

    • MT – Check what people used for SAMPL

    • JW – Same as hydration free energy calcs? Perses can do that

      • JS – I don’t quite think they’re the same

      • MT – Correct (I only know this because my chemical engineering education dealt a lot with solubility and not at all with solvation)

    • MH – https://docs.eyesopen.com/toolkits/python/molproptk/molprops.html#logs "Further, it is not suitable for the PK predictions that come late in a project. However, it is useful for eliminating compounds with severe solubility problems early in the virtual-screening process."

  • JS – DD, could you make a new alchemiscale account for our slackbot?

    • DD – Sure, just let me know what kinds of capabilities/scopes it needs.


Action items

  • David Dotson will investigate slow set_network_weight call (due to TaskHub lock from slow claims from compute services)

Decisions

  • No labels