Currently grid node status (i.e., core, fixed_value_boundary, fixed_gradient_boundary) is implicitly used to define the base level nodes in a flow graph. This is not ideal, though.
A more explicit way to define those base level nodes would be better for clarity and also flexibility (i.e., use different boundary conditions for flow-graph based vs. grid based processes). In general, separation of concerns grid vs. flow-graph is better.
A possible solution would be to assign some label for each node of the graph. Like for grid node status, there may be multiple values available, e.g.,
land
base_level
lake
ocean
Although it wouldn't prevent flow operators (*) to define their own specific labels if needed, best would be to have general label values so that we maximize the potential of reusing them in various algorithms (this would also save some memory). I'm thinking about the Fill–Spill–Merge algorithm (paper) that might be worth implementing here as a flow operator.
There may be some pitfalls in choosing the labels, though. For example, pit may be a useful label but it is not mutually exclusive with lake while only one label is assigned for each node. Another example: are there cases where lake boundaries would need a label? This is tricky since we might not always want that lake boundaries coincide with flow graph nodes and edges, unlike land vs. ocean separated by base_level nodes would fit 99% of the cases.
For convenience, we could automatically set base_level for all grid nodes with fixed_value_boundary when creating a new flow graph, unless the user provides an alternative list of base level node indices. This wouldn't change from the current behavior.
Using those labels, I'd like to implement convenient iterators (in C++) for traversing the graph nodes (in the topological order) including (excluding) some labels.
cc @jeanbraun @hannahsophiadavies @bgailleton -- if you are interested and in case you have any thoughts or ideas about the labels, possible uses cases and implementation.
(*) More context: there has been a major refactor in #116 introducing flow operators, which allow implementing simple to advanced flow routing strategies easily and in a composable way.
Currently grid node status (i.e.,
core,fixed_value_boundary,fixed_gradient_boundary) is implicitly used to define the base level nodes in a flow graph. This is not ideal, though.A more explicit way to define those base level nodes would be better for clarity and also flexibility (i.e., use different boundary conditions for flow-graph based vs. grid based processes). In general, separation of concerns grid vs. flow-graph is better.
A possible solution would be to assign some label for each node of the graph. Like for grid node status, there may be multiple values available, e.g.,
landbase_levellakeoceanAlthough it wouldn't prevent flow operators (*) to define their own specific labels if needed, best would be to have general label values so that we maximize the potential of reusing them in various algorithms (this would also save some memory). I'm thinking about the Fill–Spill–Merge algorithm (paper) that might be worth implementing here as a flow operator.
There may be some pitfalls in choosing the labels, though. For example,
pitmay be a useful label but it is not mutually exclusive withlakewhile only one label is assigned for each node. Another example: are there cases where lake boundaries would need a label? This is tricky since we might not always want that lake boundaries coincide with flow graph nodes and edges, unlike land vs. ocean separated bybase_levelnodes would fit 99% of the cases.For convenience, we could automatically set
base_levelfor all grid nodes withfixed_value_boundarywhen creating a new flow graph, unless the user provides an alternative list of base level node indices. This wouldn't change from the current behavior.Using those labels, I'd like to implement convenient iterators (in C++) for traversing the graph nodes (in the topological order) including (excluding) some labels.
cc @jeanbraun @hannahsophiadavies @bgailleton -- if you are interested and in case you have any thoughts or ideas about the labels, possible uses cases and implementation.
(*) More context: there has been a major refactor in #116 introducing flow operators, which allow implementing simple to advanced flow routing strategies easily and in a composable way.