Skip to content

Conversation

@jaapschoutenalliander
Copy link
Member

Performance: Improve downstream nodes performance

Changes proposed in this PR include:

Create downstream nodes function on BaseGraph and RustworkxGraph, restricting the search locally and using the properties of radiality (which is needed anyway to consistently define downstream)

  • Add downstream functions
  • Rewrite performance tests

Copy link
Member

@Thijss Thijss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work and I think "sorted by distance" seems preserved. Perhaps we can add/alter a test to verify it? Current tests only seem to check results using sets

Comment on lines +241 to +256
def get_downstream_nodes(self, node_id: int, stop_node_ids: list[int], inclusive: bool = False) -> list[int]:
"""Find all nodes connected to the node_id
args:
node_id: node id to start the search from
stop_node_ids: list of node ids to stop the search at
inclusive: whether to include the given node id in the result
returns:
list of node ids sorted by distance, downstream of to the node id
"""
downstream_nodes = self._get_downstream_nodes(
node_id=self.external_to_internal(node_id),
stop_node_ids=self._externals_to_internals(stop_node_ids),
inclusive=inclusive,
)

return self._internals_to_externals(downstream_nodes)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what way are the stop_node_ids still needed with the tmp_remove_nodes context implemented by @Thijss?
Isn't this equal to:

with graph.tmp_remove_node(stop_node_ids): 
  graph.get_downstream_nodes(node_id = node_id)

Copy link
Member

@Thijss Thijss Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionally it should be equal, but since we aren't modifying the graph here it could give significant better performance?
Perhaps it's a good idea to base this PR on #17 and add a performance comparison.

If the performance increases significantly we can merge the PR. Otherwise we can drop it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could try that, the main performance improve should be in not using get_nearest_substation_node to get_connected on the whole grid. Technically using tmp_remove_nodes can achieve a similar result

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue when we want to do this is that we do not have the information about which substation is the feeder, so I do not think the tmp_remove_nodes will work (without additional complexity)

jaapschoutenalliander and others added 5 commits January 24, 2025 13:17
Signed-off-by: jaapschoutenalliander <[email protected]>
Signed-off-by: jaapschoutenalliander <[email protected]>
Co-authored-by: jaapschoutenalliander <[email protected]>
Signed-off-by: Thijs Baaijen <[email protected]>
Co-authored-by: jaapschoutenalliander <[email protected]>
Signed-off-by: Thijs Baaijen <[email protected]>
@Thijss Thijss changed the base branch from main to feat/update-performance-tests January 29, 2025 10:16
@sonarqubecloud
Copy link

Base automatically changed from feat/update-performance-tests to main January 29, 2025 12:50
@Thijss
Copy link
Member

Thijss commented Feb 3, 2025

@jaapschoutenalliander shall we drop this PR in favor of #21 ?

@jaapschoutenalliander
Copy link
Member Author

Agreed, since this solution won't cover all cases

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

Successfully merging this pull request may close these issues.

4 participants