Add an HBV96-like lake model to HydPy-Dam

[tyralla]

So far (HydPy-Version 4.0), all implemented lake, retention basin, and reservoir models follow LARSIM concepts or are at least thought to be used within LARSIM type applications. Next, we implement an HBV96-like reservoir model into our HydPy-Dam model family.

This issue serves as a notebook to record our design decisions and open questions.

[tyralla]

HBV96 allows defining individual relationships between the water level and discharge for each day of the year (regmath.par). We can emulate this with our usual interpolation approach, which relies on nonlinear interpolation functions for arbitrary times of the year and linear interpolation in between (see method Calc_FloddDischarge_V1). At worst, this word require to fit 365 interpolation functions for each reservoir instance, but this seems quite unlikely.

[tyralla]

HBV96 allows for a variable surface area that depends on the water level. I think this is relevant for evaporation only. However, if we, for example, assume the water area to increase, we should also assume the land area to decrease. Model instances of, for example, H-Land are not aware (and should not be aware) of the water level of a Dam model instance. So, if we actually want to support variable surface areas, our new lake application model should somehow also model the evapotranspiration from an area around the water surface itself. But a lake model instance does not calculate soil moisture itself and does not know about the internal states of the surrounding "land models". Hence, we would need some simplifying assumptions, raising the question of modelling variable surfaces areas is worth the effort.

[tyralla]

In addition to the comment above: So far, HydPy-Dam does not calculate actual evaporation on its own (see issue #51). This seems to be the occasion to change this.

As mentioned in issue #51, we could either implement complete internal calculations or modify externally calculated potential evaporation values. If I understand correctly, HBV96 supports both approaches. Internally, it uses a simplified Thornswaite equation parameterised for Scandinavian conditions. This looks a little special, holds for monthly values only, and I do not know all the details. So I prefer the external potential evaporation approach.

When calculating evaporation externally, one has to take the thermal inertia of the water body into account. At best, one would do so in the external calculations. To deal with cases where we do not do this (for example, because we apply application model evap_v001), we should implement some delay function. One example would be the one implemented in the method Calc_ET0_WET0_V1 of HydPy-L-Land. (Though I am not sure if HBV96 is doing this. Its documentation states only that it calculates the water temperature based on the air temperature similarly.)

Also, we have to keep in mind that HBV96 suppresses evaporation if there is an ice layer on the water body (but precipitation always reaches the water body).

[tyralla]

If two lakes are within the same subbasin, HBV96 allows to connect them. Between these two lakes, water can flow in both directions. This is a functionality HydPy-Dam does not provide yet. Application models dam_v004 and dam_v005 aim to achieve similar things but are limited to unidirectional controlled water release for flood and drought protection.

We first need to decide whether we prefer to support bidirectional links between individual model instances or to represent different "parts" of a lake within one model instance.

Regarding numerical accuracy, the "one model instance" approach is better. However, given that we are dealing with slowly responding lakes, the difference should be irrelevant in most applications.

Regarding configuration, the "multiple model instances" approach would introduce the demand for remote nodes, making network files a little harder to understand (and can complicate parallelisation, which we might support later).

Regarding flexibility/modularity, the "multiple model instances" approach offers more advantages. We could separate the complete functionality into a standard lake model and a bidirectional exchange model. A possible solution:

1. Allow, for example, application model dam_v006 to inform a remote node about its current water level (little effort).
2. Additionally, allow for exchanging water through an "exchange node" (I am not sure if we should use one of the available node types for this, so possibly this requires extending the framework; see remark below).
3. Implement an "exchange model", which calculates the water flow between two lake model instances based on the difference of their water levels (also not very complicated).

The process order:

1. Send water levels at time t0 to the exchange model.
2. Let the exchange model calculate the average flux between t0 and t1.
3. Use the constant flux (positive for one model and negative for the other one) to update the water level for t1.

One nice aspect of this solution would be that we could quickly transfer it to other models. Adding two additional nodes to all other HydPy-Dam models is much less effort than introducing the "sub-lakes" concept to all of them. A different use-case, interesting for HydPy-W, for example, would be to allow for bidirectional groundwater exchange between adjacent sub-catchments. However, we have to keep in mind that this approach is only accurate for processes reacting slowly compared to the given simulation step size (as long as we solve the ODEs of individual model instances separately, which will not change in the foreseeable future).

Regarding the process order defined by the list deviceorder: We would need to place an exchange model calculating the value of an exchange node before the model requiring this value. So, for technical reasons, we do not need to define an "exchange node" type. For the exchange model, the "exchange node" is an outlet node. For the lake models, the "exchange node" is an inlet node.

[tyralla]

Regarding evaporation: we finally decided to use externally calculated potential evaporation and combine it with a delay and damping mechanism as suggested above. Also, we decided to not suppress evaporation during cold periods with a possible ice layer on the water body. From our perspective, this is an unnecessary complication, as the externally specified values should reflect the reduction of evaporation during cold periods already.