Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strategy: task prioritization of 'core' of network #232

Open
JenkeScheen opened this issue Jan 24, 2024 · 1 comment
Open

Strategy: task prioritization of 'core' of network #232

JenkeScheen opened this issue Jan 24, 2024 · 1 comment

Comments

@JenkeScheen
Copy link

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.
@dotsdl
Copy link
Member

dotsdl commented Feb 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants