Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Snow redistribution in H-Land #70

Closed
tyralla opened this issue May 4, 2021 · 3 comments
Closed

Snow redistribution in H-Land #70

tyralla opened this issue May 4, 2021 · 3 comments

Comments

@tyralla
Copy link
Member

tyralla commented May 4, 2021

So far (HydPy-Version 4.0), the application model hland_v1 (and all the other application of the HydPy-H-Land model family we are developing at the moment, see issues #67 and #68) simulates snow processes for each zone (hydrological response unit) separately. There is no redistribution of snow lying on the ground due to gravitational or wind forcing.

To improve simulations in high mountainous regions (namely in the alps), we plan to incorporate snow redistribution processes into H-Land in two ways:

  1. Redistribution from higher zones to lower zones within the same subbasin.
  2. Redistribution from higher subbasin to lower, adjacent subbasins.

The first way makes sense for huge subbasins where zones are defined based on elevation. The second way seems preferable for small subbasins with "unnatural" shapes (for example, following a grid pattern).

This issue serves as a notebook to collect and discuss ideas on how to implement these approaches.

@tyralla
Copy link
Member Author

tyralla commented May 4, 2021

This is more of a side note: I am not aware of any detailed discussions, but it seems that HBV96 allows for dividing zones into snow classes. There is a figure in Lindström et al. (1997), indicating that one can define several snow classes. The snowfall (SF) reaching the first snow class calculates to SF_1 = SF * (1 - SFDIST). The snowfall (SF) reaching the last snow class calculates to SF_n = SF * (1 + SFDIST). For all snow classes in between, snowfall increases constantly from "left" to "right". I assume, besides modifying the snowfall distribution, all snow classes function equally.

So far, hland_v1 does not provide such a feature. I encountered this when reading about snow redistribution in the COSERO model (Frey and Holzmann, 2015), which simulates differences in the snowfall distribution similarly but relies on the lognormal distribution instead.

@tyralla
Copy link
Member Author

tyralla commented May 5, 2021

A short comparison between the snow redistribution approaches implemented in other models.

The LARSIM approach is relatively simple. Snow exceeding a certain threshold moves directly downhill. This threshold only depends on the terrain slope. LARSIM neglects time variable influences as snow density and wind speed. If I understand correctly, one has to define the "connections" between individual snow classes manually. The lowest snow class passes its snow to the downstream subbasin (I do not know to which snow class(es) of the downstream subbasin exactly). In contrast to HBV96 and COSERO, LARSIM allows defining snow classes independent from land-use types (zones).

Following the paper of Frey and Holzmann (2015), COSERO passes snow from grid cell to grid cell. In my understanding, each grid corresponds to a subbasin (or, in HydPy terms, to an Element instance). I cannot find a hint about the definition of multiple zones for each grid cell, but each cell seems to consist of five snow classes. There is no snow redistribution within a cell. Each cell passes its snow to the lowest adjacent cell. Comparable to LARSIM, there is a threshold defining when snow movement starts, but this movement is not infinitely fast and depends on the current density of the snowpack. COSERO does not consider wind speed. An "acceptor cell" distributes the snow passed by its "donor cells" on its snow classes like it were fresh snowfall. According to Frey and Holzmann (2015), the approach implemented in COSERO is unique in that it targets coarser spatial resolutions than other available approaches.

WaSiM allows both wind-driven and gravitational snow redistribution. The first one is an input data correction approach based on wind field analysis, which does not prevent the generation of artificial "snow towers". Thus, I only discuss the second approach. Snow can slide from one cell to the four adjacent cells. I suppose the division into the four directions is freely definable. Snow movement does neither depend on snow density nor on wind speed, only on the local slope of the cell. Of the snow that slides into a cell, a certain amount is deposited, while the rest continues to slide downhill directly into the next cells. Of the already deposited snow, a certain fraction "erodes" at least for sufficiently steep slopes. That means some cells do not redistribute "their own" snow at all, and others do it in a linear storage manner. The underlying algorithm was initially developed for a spatial resolution of 10 to 50 meters.

@tyralla
Copy link
Member Author

tyralla commented May 6, 2021

An additional remark regarding COSERO's snow redistribution. There is also a strongly simplified approach, which does not even require information about terrain slopes or the connections between different spatial units. Here, one defines three parameters:

  1. a threshold elevation
  2. a threshold snow amount
  3. a temperature gradient

If there is a spatial unit with an elevation above the first threshold, COSERO checks if its snow amount exceeds the second threshold. If so, it applies an increased air temperature on the snow fraction exceeding the threshold. The higher the elevation, the higher the air temperature increase (following the third parameter) and the higher the snow melt.

To me, this seems somewhat counterintuitive. It prevents snow towers but does not transport the snow downhill. However, it is extremely simple to parameterise and one has not be afraid that certain spatial units receive too much snow from above so that they themselves build up unrealistic snow towers.

tyralla added a commit that referenced this issue Jun 11, 2021
…`hland` to vary seasonally according to the annual cycle of radiation ((supplements issue #70).
tyralla added a commit that referenced this issue Jun 11, 2021
…`hland` to vary seasonally according to the annual cycle of radiation ((supplements issue #70).
tyralla added a commit that referenced this issue Jun 11, 2021
…`hland` to vary seasonally according to the annual cycle of radiation ((supplements issue #70).
tyralla added a commit that referenced this issue Jun 25, 2021
…rcing to base model `hland` and all its application models (closes #70).
tyralla added a commit that referenced this issue Jun 25, 2021
…rcing to base model `hland` and all its application models (closes #70).
tyralla added a commit that referenced this issue Jun 25, 2021
…rcing to base model `hland` and all its application models (closes #70).
@tyralla tyralla closed this as completed in b9d94e4 Aug 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant