Edge cases in the "regine" hierarchy (Task 2.2)

[JamesSample]

There are a number of "edge cases" in assigning the regine hierarchy that were not well handled by the original model. This issue documents these cases and resolves them where possible.

NVE's description of the regine hierarchy is here. A basic algorithm for identifying the next regine downstream of any other based on the regine code is described in notebook T2-2. Note the following edge cases/complications:

1. Partial fields at the same level are considered sequentially

Terrestrial subcatchments are often divided either side of the main river stem (simple examples include "randfelt" and "delområde in sentralfelt", but the same thing occurs much deeper in the hierarchy too). As an illustration, consider 250.C4 and 250.C3 in the image below

Similarly, "kystfelt" are numbered sequentially (see below)

In the original model, 250.C4 flows into 250.C3 into 250.C2 into 250.C1, while 250.4 flows into 250.3 into 250.2 into 250.1. Neither of these arrangements are accurate.

For the terrestrial catchments, I haven't yet thought of a good way of resolving this problem based on the regine codes. However, I don't think it's a huge issue, as long as users take care to choose an appropriate "outflow regine" for their work. For example, it does not make much sense to consider inputs upstream of 250.C4, without also including 250.C3 (which, as far as TEOTIL is concerned, is the next catchment downstream).

For the kystfelt, the numbering does not imply any dominant hierarchy in terms of flow direction. One option is therefore to simply assign all kystfelt directly to the parent vassdragsområde (i.e. ignore all sequential routing for kystfelt). To allow for this, I have included an optional kwarg named order_coastal in the function assign_regine_hierarchy, which makes it possible to switch easily between ordering kystfelt numerically (like the original model) and assigning them directly to the vassdragsområde.

2. River outflows are assigned to the highest-ranking coastal field (of those considered "downstream")

In the original model, the furthest downstream part of each terrestrial catchment was linked to the highest-ranking kystfelt (out of those considered "downstream"). Note, however, that in many cases this is not the kystfelt that the river actually flows into. As an example, consider regine 028.A3. In the original model, the downstream flow path from this regine begins like this

and then continues through another 13 sequentially ordered kystfelt before being assigned to vassdragsområde 028.. The sequential ordering of the kystfelt is unrealistic, which can be resolved by setting order_coastal=False (see point [1] above). With this change, the new routing looks like this

Note that the downstream-most terrestrial catchment (028.A1) still links to the highest-ranking kystfelt (028.72; the same as before), but the kystfelt is then assigned directly to 028., instead of "flowing" through all the kystfelt in turn. However, in reality, 028.72 is a long way from the outflow of 028.A1. The map below shows the entire catchment upstream of 028.72 (according to the original TEOTIL model). The terrestrial catchment is broadly correct, but it is clear that 028.72 is not an appropriate kystfelt for linking with 028.A1, because it lies too far to the north.

There does not appear to be any way to identify the most appropriate downstream kystfelt based on the regine code alone. One possible solution is to assign each river outflow directly to the parent vassdragsområde, instead of linking to the kystfelt. To allow for this, I have included an optional kwarg named land_to_vass in the function assign_regine_hierarchy, which makes it possible to switch easily between linking river outflows to the highest-ranking kystfelt (like in the original model) and assigning them directly to the vassdragsområde. Note that this is not an ideal solution, since in some situations we might be interested in the total inputs to a particular kystfelt. However, given that most kystfelt have "diffuse" boundaries with other kystfelt, it does not make much sense to consider them in isolation anyway (at least, not within TEOTIL).

Summary

• The function assign_regine_hierarchy implements an algorithm for hydrologically ordering (sub-)catchments based on their regine codes

• To reproduce the behaviour of the original model, choose order_coastal=True and land_to_vass=False. Note that this results in unrealistic flow routing between kystfelt (see section 2.1 of the notebook T2-2 for further details), as well as incorrectly assigning some river inputs to kystfelt that may be far away from the true outlet

• An alternative is to set order_coastal=False and land_to_vass=True. This will assign fluxes from kystfelt and river outflows directly to the parent vassdragsområde, essentially ignoring any flow routing in the coastal zone. Since TEOTIL is not capable of routing fluxes across "diffuse" boundaries (such as between kystfelt), this approach is considered more sensible in most cases. However, the implication is that each kystfelt is treated in isolation i.e. without any upstream inputs. Within the structure of TEOTIL, kystfelt nodes will therefore only have local inputs (and the accum attributes will either be missing altogether or identical to local). This has implications for interpretation of the model output at spatial scales finer than the level of vassdragsområder

• Setting order_coastal=True and land_to_vass=True does not make much sense, since if you're willing to route fluxes through the coastal catchments you should probably also be consistent with the rivers. This combination will therefore raise an error

• Setting order_coastal=False and land_to_vass=False is permitted for the moment (but perhaps not very sensible?)

[JamesSample]

ff2aad9 adds an additional test to the end of Notebook 2.2, which applies the new algorithm to the old regine dataset from TEOTIL2.

When run using "legacy" parameters and the old regine data, the new algorithm can exactly reproduce the hierarchy from TEOTIL2. This confirms that the new algorithm is an improvement over the old one, because it can duplicate the old hierarchy if desired, but also includes several improvements (see above).

I am closing this, as I think the new algorithm meets the requirements of TEOTIL3. Nevertheless, there are still some limitations - mostly related to limited information in some of the regine codes (see above).