Page Comparison

alchemiscale.org

• user questions / issues / feature requests

  • JS – Question: When I submit a network, there are a bunch of tasks. Is there a specific in which those get executed, or is it a random selection?

    • DD – When a network is submitted, no tasks are created upon submission. Once you do reate tasks and action them, then they’ll get picked up by compute services according to weighted random selection.

    • JS – Would there be scope to make it deterministic?

    • DD – We have knobs you can turn to make it MORE deterministic, but those aren’t exposed in the client yet.

    • JS – I’m asking because, two weeks ago, we talked about pulling down results from unfinished networks. But it made me think that the netowrk might be disconnected, which can give a lot of issues. So would it make sense to, by default, to have some criteria to determine the order of tasks. So, like, if you have a network of 10 ligands, with 2 that are central and 4 hanging off each, you’d want the most “central” edge, between the two “central” ligands, to be run first, so that you get the most possible info from it.

    • DD – What will help us there is the Strategy component. The strategy will decide how to prioritize/action tasks. But I don’t think it’ll make sense to bake in that logic elsewhere as well. Shorter term, the user should create+action their tasks with manually-set priority, or control the order that they’re submitted for execution so that only the important tasks are available initially. Alchemiscale #209 will add a kwarg for setting the weight in action_tasks.

    • DD – There’s also a knob called “priority”, accessed via AlchemiscaleCleitn.set_task_priority, which isn’t currently implemented. This will modify the task’s priority, which is separate from its “actioned weight”. A task can be actioned on more than one network, so there’s a separate “task priority” on the task itself, which is different from the “action’s priority” which is particular to a single network.

    • JW – So nothing ever looks directly at task priority, instead it looks at action priority?

    • DD – No. A manager will ask the server for the task hubs, where each task hub corresponds to one alchemical network. Each task hub has a weight, and each task in a hub has a weight and a priority. It selects a task hub based on a weighted random selection considering the TASK HUB WEIGHTS. The manager takes all the tasks within that hub with the highest (lowest-integer) TASK PRIORITY and executes them first. If there are multiple tasks with the same TASK PRIORITY value, it does a weighted random selection based on the TASK WEIGHTS.

• compute resources status

  • 25 openfe tasks running, 50 openff.

  • JS – I’m gearing up to run a bunch over the holidays. So I might throw a lot in.

  • IA – If there are still problems, I may throw more into the partial charge issue.

    • DD – Are you able to run modified versions of alchemiscale/openfe stack?

    • IA – Yes.

• current stack versions:

  • alchemiscale: 0.2.1

  • gufe: 0.9.5

  • openfe: 0.14.0

  • perses: protocol-neqcyc

  • openmmforcefields: 0.12.0

  • MH – No feflow updates

• DD – ASAP has some unique challenges around protocol execution, because of IP issues. So one concern is that protocols that dump data could release sensitive data on something like NRP hosts. Some of the protocols in feflow would then need ways to run without dumping small molecule components to disk.

  • IA – Kinda depends on how secure alchemiscale host is, since that has serialized mols.

  • DD – Lives in chodera lab/MSKCC, which already has some legal/security status. So IP-wise if something is taken from there it’s not considered a disclosure.

  • IA – Worth considering what happens if a protocol dies halfway and leaves identifying info on disk.

  • DD – Yeah, or if like an NRP host runs backups while a job is running.

  • IA – Does OpenFF clean up temp files after antechamber calls?

  • MT – Yes, uses stdlib.tempfile.

  • MH – NamedTemporaryFIle may be safer.

  • …

• MO – Not much from me, running some jobs to get around partial charge issue.

  • DD – Saw some

  • … (Irfan presents OpenFE partial charge results)…

  • JW – I’ll talk to our lead team, but this seems compelling for:

    • Implementing ELF1 and fixing diagonalization routine

      • IA – Some other antechamber settings we could add, I’ll mention them in an issue

    • Pushing for full NAGL deployment as AM1BCC charge source

      • MH – We should put in some consistency tests for GNN charges so we’re not in the same position in a year.