Considering sub-basin (or `RANK`) values for the streamflow gauges

[kasra-keshavarz]

Reported by Zelalem Tessema,@sujata91, and myself:

It would be great if the streamflow gauges could be specified with RANK or subbasin values in the vector-based setup, rather than coordinates. The problem arises from the issue that, I guess, in the grid setup, the location of the streamflow gauges are tracked to be closest to the centroid of which grid cell. I assume this is similarly happening in the vector-based setup, which occasionally results in incorrect sub-basin locations for a gauge.

Hope I was able to articulate the problem correctly. Let me know if you need further clarification.

[sujata91]

As Zelalem suggested to use the centroid lat/lon for the gauge location to reduce any discrepancy in the drainage area. It takes some time and effort to check the gauge location in the shapefile and check that information in the drainage database file to enter the coordinates. I was just wondering if there could be a better work around for this as what Kasra suggested above.

[dprincz]

This will be accommodated by adding "structures" as a level among the model-agnostic processing. The db will optionally contain information about structures on a subbasin/grid-level, which will override location information provided by streamflow records. This is consistent with how reservoirs/reaches are already registered, for example.

Adding this to the workflow also permits it to produce the streamflow series/data file so that it would be consistent -- which was the concern with otherwise having arbitrary Rank indexing included in that file.

[kasra-keshavarz]

Thank you Dan. Is there an example of the "structures" that I can have a look and follow to include its properties in the workflows? I think this will be more of a MESH-specific step.

[dprincz]

Connecting structures to subbasins wouldn't be MESH-specific. We're exploring a step of simply adding information to say a subbasin contains a structure, be it a gauge, reservoir, diversion inlet, abstraction point, water quality inlet, stream-temperature measure, data-assimilation point, etc.., connecting the geofabric to point-based information. A subset of those items would be required by any water resource model, particularly as I see applications of the model-agnostic framework now moving beyond the designation of only "terriestrial" type subbasins/areas. Earth Systems Models already support the designation of 'non-terrestrial' land-units, and any water resource model requires inputs related to structures (i.e., regulated and/or human-introduced control measures) within the basin to be able to parameterize demands between connected elements.

However, the conversion of this information into a format recognized by MESH will be MESH specific. @fuadyassin is moving this forward in a technical capacity and I expect him to coordinate with you. @sujata91 and Zelalem will probably demonstrate and validate it further. Initially, this will focus on streamflow gauge locations but I expect it to extend to inland water bodies/lakes and reservoirs after, and finally to more complex water management features like irrigation districts, diversion outlets, abstraction points, etc.., in an effort to generalize the different approaches currently used by MESH, GEM-Hydro, etc.., and to coordinate with methods that I assume the developers of Raven will probably introduce too. I do not know if mizuRoute includes water management features, but this would extend to that too if they should be added or if they're already there.

[fuadyassin]

Hi @kasra-keshavarz As @dprincz suggested, I will reach out to provide the structure for including properties in the workflows. I will coordinate with you with the initial focus on streamflow gauge locations. We aim to extend this to inland water bodies, lakes, and reservoirs, followed by more complex water management features. Cheers, Fuad