per-gridcell heat wave indice calculations?

[JeremyFyke]

Addressing a Problem?

Hi there,

I'm enjoying using xclim's heat wave indices (heat_wave_index, heat_wave_frequency; heat_wave_max_length). However, it seems like the current implementation only accepts a scalar value of the heat wave threshold (codified in a string, e.g. '25 degC'). In reality, many heatwaves are location dependent - for example, what would be considered a heat wave in Arctic Canada would be a mild day in southern Canada. In other words, heat wave thresholds for gridded analyses are arguably best defined on a per-grid cell basis (e.g. 99th percentile of gridpoint summer temperatures or similar). Is there a way to implement this in xclim, to update it to accept both scalar definition of a heatwave threshold, and also a gridded definition?

Thanks!

Jeremy

Potential Solution

No response

Additional context

No response

Contribution

• I would be willing/able to open a Pull Request to contribute this feature.

Code of Conduct

• I agree to follow this project's Code of Conduct

[bzah]

Hi Jeremy, as a suggestion, you could use warm_spell_duration_index (WSDI) which is based on percentiles. The 90th percentile is supposed to be used but in reality you can compute tasmax_per on any percentile.

Beware, until #1050 is merged the metadata might be wrong if you use percentiles others than the 90th.

[aulemahal]

Indeed, this is something we discussed in the past, but the need was never strong enough for us to move.
I believe it would be relatively easy to modify the definition of the "Quantity" input kind to include DataArrays that have no time dimension. "relatively" in the sense that most indices would work with minimal modifications, will others might not.

One of the "problems" I foresee is the metadata formatting. Accepting those new PercentileDataArrays required tuning the attribute machinery and so will this proposed change. For example, using heat_wave_frequency, the current description is:

{freq} number of heat wave events over a given period. An event occurs when the minimum and maximum daily temperature both exceeds specific thresholds : (Tmin > {thresh_tasmin} and Tmax > {thresh_tasmax}) over a minimum number of days ({window}).

I'm unsure of how to rewrite this to catch all cases (fixed and variable thresholds). I would be happy to hear suggestions!

(This string is formatted after the computation of the indice. thresh_tasmin and thresh_tasmax are given to the formatting function directly as passed to the indicator, but there could be some preprocessing added. )

[JeremyFyke]

Pascal,

Thanks a ton for considering this. I'd be happy to be a guinea pig if/when this development proceeds!

Jeremy

[Tocquer]

I work at Météo-France for the French climate service DRIAS (http://www.drias-climat.fr) which provides climate indicators. We are working to change the chain of calculation of indicators and we would be very interested in the implementation of this type of indicator.
Currently we propose the following indicators:

• Number of unusually hot days (maximum temperature more than 5°C above normal)
• Number of unusually hot nights (minimum temperature more than 5°C above normal)
• Number of unusually cold days (minimum temperature more than 5°C below normal)
  It is hoped that these developments can be incorporated
  Thanks
  Flore

[bzah]

@aulemahal

One of the "problems" I foresee is the metadata formatting. Accepting those new PercentileDataArrays required tuning the attribute machinery and so will this proposed change. For example, using heat_wave_frequency, the current description is [...]:

Would it help to render the description as a jinja template ?
We could then do something like:

description = "
{{freq}} number of heat wave events over a given period. 
An event occurs when the minimum and maximum daily temperature both exceeds specific thresholds : 
{% if np.isscalar(thresh_tasmin) and np.isscalar(thresh_tasmax) %}
   (Tmin > {{thresh_tasmin}} and Tmax > {{thresh_tasmax}})
{% else %}
   (Tmin > per_gridcell_tmin_thresholds and Tmax > per_gridcell_tmax_thresholds) # Not sure how to phrase it
{% end if %}"

With jinja enabled, I think it could also be used to group together multiple indices that are very similar (e.g. tx90p, tg90p, tn90p) and help with #714 I guess.

[aulemahal]

Wow fancy! I like this jinja idea, better than my "callback" version.

On the other hand, this specific case could be simpler : it could all live in Indicator.format which would detect if the InputKind.QUANTITY input is a scalar or not. Simpler (no large breaking change), but stricter, as the string wouldn't be modifiable for different indicators.

Seeing the interest from many different places, I'm increasing priority on this and planning an implementation this summer.

[bzah]

I don't think adding jinja within Indicator.format would cause many breaking changes.
edit: it breaks a few things: translations, frequency formatting and maybe others
edit(bis): AFAIK, it does not break anything when we combine the 2 formatters (AttrFormatter and jinja)
I made a small pr, limited to _temperature.py module, just to see how it would work: #1120