Add the `UseSnowCover` parameter to the AET members of the HydPy-Evap model family

[tyralla]

Having such a parameter would be comfortable for testing purposes currently, but implementing it could make sense for hydrological reasons as well.

If I am not mistaken, only HydPy-Evap-AET-HBV96 currently uses snow cover information by reducing soil evapotranspiration linearly with increasing snow cover. HydPy-Evap-AET-Minhas and HydPy-Evap-AET-MORSIM never do this. This difference is due to the original models from which we took these methods, but it has no theoretical justification. I would say one reasonable way to argue is that one should reduce soil evapotranspiration only if the snow model can calculate snow evaporation.

We have already discussed this and see two options:

1. Add the control parameter UseSnowCover. This leaves the burden of one additional decision on users but provides more flexibility, for example, regarding compatibility with older HydPy versions or other model systems.
2. Add the deroved parameter UseSnowCover. This should be technically feasible and would require only minimal additional work for model developers.

We chose option 1, but we may switch to option 2 after gaining more experience. Also, we implement UseSnowCover independently of the snow submodularisation efforts because it has some value on its own, and we are still not sure how our snow submodularisation efforts will evolve.

[tyralla]

I just realised that there is also one PET model that reduces soil evapotranspiration due to snow cover: HydPy-Evap-PET-AMBVAV-1.0. This is unfortunate because we need to rethink the matter and adjust our current work. However, it shows that introducing UseSnowCover or a similar change is useful, because currently, a combination of HydPy-Evap-AET-HBV96 and HydPy-Evap-PET-AMBVAV-1.0 would result in snow cover being considered twice. (This makes no difference if the snow routine estimates the snow cover in a yes-or-no manner, but unfortunate if it calculates a snow cover degree, which is only the case for the HydPy-H model family, if I remember correctly).

I see three options:

1. Stick to our plan and accept that HydPy-Evap-PET-AMBVAV-1.0 has the same snow reduction functionality.
2. Remove the feature from HydPy-Evap-PET-AMBVAV-1.0.
3. Move the feature from all AET to all PET models (except for MORSIM, which calculates AET in one step).

The second option sounds like the cleanest to me (in my mental model, the reduction of soil evapotranspiration is due to snow evaporation consuming the available energy. But I did not check so far if we could keep total compatibility with previous simulation results of HydPy-Evap-AET-HBV96 this way.

[tyralla]

We agreed to move all "snow cover interpretation features" into our PET models, accepting that the combination of HydPy-Evap-AET-HBV96 and HydPy-Evap-PET-HBV96 might behave slightly differently in the future.

During the discussion, we found a few more relevant usages of the SnowCover factor sequence. I hope the following list is complete:

• Calc_CurrentAlbedo_V2, used by HydPy-Evap-PET-AMBAV-1.0
• Calc_InterceptionEvaporation_V2, used by HydPy-Evap-AET-MORSIM
• Calc_SoilEvapotranspiration_V3, used by HydPy-Evap-AET-MORSIM
• Update_SoilEvapotranspiration_V2, used by HydPy-Evap-AET-HBV96 (already discussed; just for completeness)

What happens?

• HydPy-Evap-AET-HBV96 reduces actual soil evapotranspiration according to the snow cover degree.
• HydPy-Evap-PET-AMBAV-1.0 adjusts the albedo to a (normally higher) value of the snow's surface. This adjustment reduces the net shortwave radiation Calc_NetShortwaveRadiation_V2, and also reduces the net longwave radiation (I don't know why, but that's how it's implemented in Calc_NetLongwaveRadiation_V2). The effect on the shortwave radiation is much larger, and so net radiation becomes smaller. This has an effect on the soil heat flux ([Calc_SoilHeatFlux_V4) and usually reduces potential interception evaporation (Calc_PotentialInterceptionEvaporation_V2), potential soil evpotranspiration (Calc_PotentialSoilEvapotranspiration_V1), and evaporation from water areas (Calc_WaterEvaporation_V4), all calculated with the help of method Return_Evaporation_PenmanMonteith_V2.
• HydPy-Evap-AET-MORSIM reduces evapotranspiration more directly (similar to HydPy-Evap-AET-HBV96) but differentiates between interception evaporation and soil evapotranspiration and also between tree-like vegetation and other types of land covers and therefore has the additional factor sequence SnowyCanopy.
  • Interception evaporation is calculated by Calc_InterceptionEvaporation_V2. For tree-like vegetation, SnowyCanopy is relevant; for all other land cover, SnowCover is relevant. In both cases, any snow cover completely reduces interception evaporation.
  • Soil evapotranspiration is calculated by Calc_SoilEvapotranspiration_V3, which only considers SnowCover. For tree-like vegetation, the existence of snow never reduces soil evapotranspiration (which I find surprising, as evapotranspiration through the leaves could be suppressed by SnowyCanopy and direct soil evaporation could be reduced by SnowCover - but maybe this distinction complicates things unnecessarily - I assume we took this behaviour from the original MORECS/LARSIM documentation). For all other land covers, any occurence of snow on the ground (thats how SnowCover should be interpreted here in my opinion), suppresses soil evapotranspiration completely.

The two distinctions of HydPy-Evap-AET-MORSIM make sense when used in combination with snow submodels that model snow interception separately (but only for trees) and calculate snow evaporation independently. (It is most likely unfeasible to move snow evaporation to our Evap models, because the corresponding calculation of latent heat is usually part of the complete and complex energy balance calculation of some snow routines.)

For HydPy-Evap-PET-AMBAV-1.0, SnowCover is not really a turn-on/turn-off switch but merely an albedo modifier. This affects how we want to understand UseSnowCover.

I think dealing with HydPy-Evap-AET-MORSIM and HydPy-Evap-PET-AMBAV-1.0 is solvable, but it requires separate discussions (and will likely pose additional challenges when proceeding with #188). For now, I will just edit the name of this issue and continue implementing UseSnowCover for our simpler PET models.

[tyralla]

During a break, it occurred to me that the current "separation of responsibilities" between AET-HBV96 and PET-AMBAV-1.0 might be more beneficial than I thought (at least after implementing UseSnowCover).

We could argue that each PET model is always allowed to adjust evapotranspiration during snow periods for physical reasons, such as snow's influence on albedo. There is no need for UseSnowCover here, as whether to include this aspect in a model is up to the model developer.

Also, we could argue that all AET models should be able to turn off certain evaporation components, since they should be active only when the current snow model calculates them separately. The model should be informed of this via UseSnowCover (and eventually also via UseSnowyCanopy).

So, I will fall back to the original idea, which is much less work, anyhow (and adjust the title again).

The (hopefully final) question, then, is: Do we want our models to think about SnowCover and SnowyCanopy as consistently as possible? Is SnowCover always the snow on the ground? Or is it sometimes the combination of snow on the ground and stored in canopies? I mean, normally, we want to stick to the original model equations as closely as possible. But if a model's snow and evaporation routines are very finely tuned to each other, the routines of another model might not match perfectly. Finding a "HydPy consensus" on questions such as "What does the term snow pack exactly mean?" would help to keep submodels more consistent and easier to manage. At the risk of losing too much flexibility for emulating some special original model concepts precisely, of course.

[tyralla]

What combination of snow information can an evap submodel expect from different snow submodels?

I will use the terms "total snow", "ground snow", and "canopy snow" in the following. "1-layer models" only calculate "total snow"; "2-layer models" calculate "ground snow" and "canopy snow" separately for trees and only "ground snow" for other land cover types.

First, I assume that if a 2-layer snow model calculates snow evaporation, it does so both for its ground and canopy snow.

The different cases to be dealt with and possible values of ``ConsiderSnow, SnowCover and `SnowyCanopy` (I neglect possible incomplete snow covers for simplicity):

case	ConsiderSnow	SnowCover	SnowyCanopy
no snow submodel	False	nan	nan
snow model has no snow evaporation routine	False	nan	nan
1-layer model reports no snow	True	0	nan
1-layer model reports snow	True	1	nan
2-layer model reports no snow	True	0	0
2-layer model reports only ground snow	True	1	0
2-layer model reports only canopy snow	True	0	1
2-layer model reports only ground and canopy snow	True	1	1

ConsiderSnow is intended to simplify UseSnowCover and UseSnowyCanopy in the table above. This aggregation would be possible by using nan values for signalling that a snow submodel does not have two layers. However, using nan is not optimal because it typically indicates missing values or other issues in time series data.

Thinking this further, we could add a calculates_evaporation method to our new snow submodel interface. This method would be called during simulation, adding only a small overhead but ensuring the evap submodel's knowledge is up to date.

Then, why not also add a calculates_interception method to the snow interface? This method would free us from using nan as a possible SnowyCanopy value. (Alternatively, we could create two different interfaces for the 1-layer and 2-layer cases - but it feels like this complicates things both for model developers and model users.)

[tyralla]

I take up the last thoughts, but concentrate more on the interfaces.

Currently, our land models follow the SnowCoverModel_V1 and SnowyCanopyModel_V1 interfaces, allowing their evap submodels to use them as sub-submodels to query the related information.

In the future, the new snow submodels will follow the SnowModel_V1 interface (and possibly others) so that the land models can use them to trigger the relevant calculations and query the results. But should the evap submodels know the snow submodels as (1) SnowModel_V1 instances or (2) as SnowCoverModel_V1 and SnowyCanopyModel_V1 instances?

The second option would make the calculates_interception method unnecessary, because it is clear that a snow submodel that does not follow the SnowyCanopyModel_V1 interface does not calculate snow interception. Adding the calculates_evapotranspiration method to the SnowCoverModel_V1 interface is a little strange but maybe acceptable.

The first option seems worse, because it would give an evap submodel permission to change the snow submodel's state. I think we should be clear that this is only allowed for main models, not for "side models".

[tyralla]

Before proceeding with the implementation, we need to agree on the exact modifications to the AET models' internal behaviour. Due to the matter's complexity, we decided to use AET-HBV96 as our prototype when coupling to 1-layer snow models without separate snow evaporation calculations, and AET-MORSIM as our prototype when coupling to 1- or 2-layer snow models with separate snow evaporation calculations. I will work with this idea and try out whether we can implement it without changing current behaviour (too much).

A side note: What makes thinking harder is that our "SoilEvapotranspiration" is a combination of evaporation from the bare soils and transpiration through the plants. None of the models we have implemented so far cleanly distinguishes this. Only AET-MORSIM does this in some way, but only with respect to individual resistance terms, which are combined before the actual calculation of total soil evapotranspiration. Because the "path" of soil evapotranspiration is not well defined, including the effects of ground and canopy snow requires additional assumptions.