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

Heatwave identification misses negative temperature exceedances #30

Closed
dkreg opened this issue Nov 29, 2023 · 2 comments · Fixed by #31
Closed

Heatwave identification misses negative temperature exceedances #30

dkreg opened this issue Nov 29, 2023 · 2 comments · Fixed by #31
Assignees
Labels

Comments

@dkreg
Copy link

dkreg commented Nov 29, 2023

Hi Tammas,

Per my email a while ago, the first line of both the identify_hw(ehfs:np.ndarray) and identify_semi_hw() functions identifies days and locations for which a heat event occurs. That is,

events = (ehfs>0.).astype(int)

. The ehfs > 0 condition is correct when ehfs is a view into the excess heat factor array, since EHF values are non-negative. However, when ehfs is instead a view into either the tmax or tmin exceedance arrays, the condition ehfs > 0 causes negative exceedances to be ignored. (Naturally, exceedances are temperature values, e.g., the 90th percentiles, and could, in principle, be negative). This issue might not matter a great deal in practice, since, presumably, exceedances are usually positive.

A simple fix would be to use np.nan values to mask-off values that are to be ignored during heatwave calculations, namely, non-positive ehfs values and values of tmax and tmin that are below the cutoff percentile. The condition ehfs > 0 would then be replaced with ehfs != np.nan.

@tammasloughran tammasloughran self-assigned this Mar 3, 2024
@tammasloughran
Copy link
Owner

There are two steps of changes that need to be made here:

  • Ensure that tmax or tmin exceedance values contain nan when not exceeding the threshold
  • Apply the correct identification operation to the two versions of identify_hw

As an aside, it's supposed to be bad practice in Python to say ehf != np.nan, and instead we should use np.logical_not(np.isnan(ehf)).

@tammasloughran
Copy link
Owner

Many thanks for this @dkreg! It's great to have another set of eyes on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants