You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is for discussing a strategy in prioritizing tasks for a given network.
Problem statement: with random task execution order, users are not able to pull meaningful predictions until the network has fully finished simulating because many nodes will be disconnected.
There are several advanced strategies on the alchemiscale roadmap that users may want to use in the future, but a 'default' strategy (rather than random task assignment) could be helpful in making sure users get the most usable results without setting a strategy explicitly.
When submitting a large network, when the first few tasks have finished in principle a user could pull down those results and get an initial prediction if these tasks (nodes) are connected. We could set a default behavior that prioritizes well-connected nodes of a submitted network. Another way to think about this is that we would bias alchemiscale to start with nodes that sit in the 'core' of a network, rather than tasks that live on the outer fringes of a network. This way the user will be able to get meaningful predictions throughout the process of the network being executed server-side.
There are likely several ways of computing the 'central-ness' of a node with networkx; I found one here that seems to be what we would be looking for. We would prioritize the highest-scoring node's tasks, then work our way outward toward nodes with the next-highest score, etc.
This strategy may not be as useful for some network design styles, e.g.:
fully-connected networks: all nodes are equally central, so can just assign tasks randomly
star networks: there is an obvious hub node, all tasks that lead to it can just be assigned randomly.
The text was updated successfully, but these errors were encountered:
Thanks for this @JenkeScheen! I agree that this would work well as a relatively simple Strategy that we could implement to make more meaningful forward progress on a network. I'd like to use this approach as one of our initial implementations for Strategys.
If you've got time or feeling industrious, you could begin implementing a rudimentary version of this yourself as well as an alchemscale user, and use its outputs to decide what Transformations to create and action Tasks for first. We likely won't begin implementing initial Strategys until 2024.04.
This issue is for discussing a strategy in prioritizing tasks for a given network.
Problem statement: with random task execution order, users are not able to pull meaningful predictions until the network has fully finished simulating because many nodes will be disconnected.
There are several advanced strategies on the
alchemiscale
roadmap that users may want to use in the future, but a 'default' strategy (rather than random task assignment) could be helpful in making sure users get the most usable results without setting a strategy explicitly.When submitting a large network, when the first few tasks have finished in principle a user could pull down those results and get an initial prediction if these tasks (nodes) are connected. We could set a default behavior that prioritizes well-connected nodes of a submitted network. Another way to think about this is that we would bias
alchemiscale
to start with nodes that sit in the 'core' of a network, rather than tasks that live on the outer fringes of a network. This way the user will be able to get meaningful predictions throughout the process of the network being executed server-side.There are likely several ways of computing the 'central-ness' of a node with
networkx
; I found one here that seems to be what we would be looking for. We would prioritize the highest-scoring node's tasks, then work our way outward toward nodes with the next-highest score, etc.This strategy may not be as useful for some network design styles, e.g.:
The text was updated successfully, but these errors were encountered: