Feature request: faster localization search for stream flow networks

[hkershaw-brown]

Use case

DART-WRF-hydro uses along the stream localization. The current implementation does a naive search across the whole stream network on each processor. This is prohibitively slow for the full CONUS case.

Is your feature request related to a problem?

Speed! And memory.

Describe your preferred solution

Precompute the distances on the stream network. The network is USGS gauges which are fixed locations forever(~).

We need upstream nodes with a certain distance from a given node.

• convert network to binary tree (add zero length nodes where needed)
• create a node | binary path | length | distance lookup table for USGS gauges
• nodes are connected if they share the same path, e.g. 11 is upstream off 1100 (see slides)
• distance between the two nodes can be found be subtracting the lengths

Each processor needs only the parts of the table for states it owns. All obs are at node locations.

jla's slides: binary path

For node identifier, we may use the USGS gauge number. example routelink file: /glade/work/gharamti/wrfhydro_dart/conus/RouteLink_NWMv3.0_fromVars_gw.nc

Describe any alternatives you have considered

Offline localization calculation.

[hkershaw-brown]

just on note on file reads on Derecho. Getting a order of magnitude difference between reads from home or work vs scratch

[mgharamti]

That's interesting! After our last meeting, I quickly checked the read from scratch and didn't notice any big difference in performance. Not sure if I did anything wrong. I think a confirmation from Marlee's profiling is helpful here.