Snow indices

[huard]

Description

• [x] DJF (or cold season) Rain Approximation (Based on Precipitation and Temperature): Total precip. when Tmax > 0C 
• [x] Snowfall Approximation (Based on Precipitation and Temperature): Total precip. when Tmin < -0.5 C 
• [x] Timing of First Snowfall: First day that SN > 0.5 mm/day; threshold suggested from studies related to snowfalls in the context of winter road maintenance 
• [x] Timing of Last Snowfall: Last day that SN > 0.5 mm/day; threshold suggested from studies related to snowfalls in the context of winter road maintenance 

[tlogan2000]

• [ ] DJF (or cold season) Rain Approximation (Based on Precipitation and Temperature): Total precip. when Tmax > 0C
• [ ] Snowfall Approximation (Based on Precipitation and Temperature): Total precip. when Tmin < -0.5 C

We sort of have these in precipaccumulation() but using tas and a hard coded 0 degC. The zero degree could easily be a default but how set in stone is using tmax, tmin?

Is there any documentation that this is the best methodology? I would argue tmax of around 0 to ~-4 deg isn't likely to give a full day of rain.. I think there exists methods of a sloped percentage of rain/snow for days with tavg between something like -3 to plus 3 degrees as well.

Anyways it might be worth trying to find some documentation or doing some simple tests on station data with the various options to find the most appropriate estimation method

[sbiner]

Ça m'intéresse, il manque souvent prsn dans les simulations.

Je pense aussi qu'il faut probablement tenir compte de tasmin et tasmax et que la relation est linéaire entre 2 valeurs près de 0 degC mais il faudrait voir la littérature.

Encore là ça serait bien d'avoir une idée de la littérature qui donne des détaille les besoin liés à ces indices.

Je me demande un peu pourquoi ce n'est pas jumelé avec l'issue #604 (winter indices)

[tlogan2000]

Emilia from the CCCS did some digging on this :

"Switzerland is using a binary method based on Tmean = 2°C (see paper here: https://hpfx.collab.science.gc.ca/~epd001/snowfall1.pdf) . For Canada, I found a study for CLASS scheme (see paper here: https://hpfx.collab.science.gc.ca/~epd001/Modified_Snow_Algorithms_in_the_Canadian_Land_Surf.pdf ). Extract from the Canadian paper:

‘’ In CLASS 2.7 precipitation is diagnosed as rain or snow based on air temperature (Ta ) using a simple threshold at 0°C. Precipitation is diagnosed as snow when Ta < 0°C, and as rain when Ta > 0°C. Observations have shown that snow can fall when Ta > 0°C, and that mixed precipitation, consisting of rain and snow, occurs at temperatures near 0°C. C3.1 includes the option of using a polynomial (Auer, 1974), to represent the fraction of precipitation that is snow (fsnow ), allowing for a range of mixed precipitation between 0° and 6°C. … we decided to adopt the polynomial as the standard for future model runs with CLASS 3.1’’

The figure 1 from the Canadian paper is showing that at Tmean = 2°C there is a probability of 50% to have snow and a probability of 50% to have rain. .."

What I proposed as a potential way forward (can be discussed):

1. First (short-term) Adapt the current implementation in xclim (currently has a hardcoded tas==0 degC threshold) to become a user input parameter (user decides the threshold for snow vs rain). Default should probably remain 0 degC to keep consistent with previous xclim behaviour
2. Explore implementing the CLASS polynomial behaviour as an option as well. function call could have a ‘estimation_method’ parameter with ‘simple’ and ‘polynomial’ options

[huard]

Les deux issues sont séparées parce qu'il y en a une prioritaire.

[aulemahal]

I started some work on this. As noted by Travis, the 2 first indicators are almost already in xclim, but I haven't seen comments by @huard .

• Rain Approximation is the same as liquid_precip_accumulation, but passing tas=tasmin.
• Snow Approximation is the same as solid_precip_accumulation, but passing tas=tasmax + changing the threshold.

As the Pr and PrTas indicators do not implement cf checks, there is absolutely no problem in passing tas=tasmin or tas=tasmax. Should we

1. create 2 new indicators when the input variable name is changed, to reflect the difference.
2. simply make the possibility more explicit in the doc strings.

Also, I believe the cold-season-extraction part is left to the user, no? What we provide is a rain approximation indicator that the user can call with freq='QS-DEC'.

[tlogan2000]

2. simply make the possibility more explicit in the doc strings.

My vote would be to keep a more generic function and simply make it clear in the docs that users can choose any type of temperature variable (min, max, mean).

[huard]

Agreed.

[tlogan2000]

Also, I believe the cold-season-extraction part is left to the user, no? What we provide is a rain approximation indicator that the user can call with freq='QS-DEC'.

Agree with this as well... Pretty simple for users to filter/select season=='DJF'

[aulemahal]

Just realized a caveat of the "let-the-user-decide" approach : in automated processes, where xclim's indices are parsed , the input variable name "tas" signifies mean temperature,. Thus the proper indicator will not be made available there. AFAIK, this is currently only a problem in the "Portraits Climatiques intéractifs", but maybe also in Finch?

[tlogan2000]

Just realized a caveat of the "let-the-user-decide" approach : in automated processes, where xclim's indices are parsed , the input variable name "tas" signifies mean temperature,. Thus the proper indicator will not be made available there. AFAIK, this is currently only a problem in the "Portraits Climatiques intéractifs", but maybe also in Finch?

ok noted... I think this is likely getting pretty advanced for the Portraits Climatiques target user... Option will still be there to shift the threshold even if 'tas' ends up being hardcoded (in a virtual sense) right? So there could some flexibility there but in all likelihood true users of this tool will simply use the default.

Not sure how this affects finch... I think users could possibly substitute 'tasmax' or 'tasmin' for the 'tas' input? @huard can you confirm?