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

Improve Growing Season Length and fix rle1d #349

Merged
merged 3 commits into from
Jan 20, 2020

Conversation

aulemahal
Copy link
Collaborator

@aulemahal aulemahal commented Jan 17, 2020

Pull Request Checklist:

  • This PR addresses an already opened issue (for bug fixes / features)
  • Tests for the changes have been added (for bug fixes / features)
  • Documentation has been added / updated (for bug fixes / features)
  • HISTORY.rst has been updated (with summary of main changes)
  • bumpversion (minor / major / patch) has been called on this branch
  • Tags have been pushed (git push --tags)
  • What kind of change does this PR introduce?

This PR changes the way xc.indices.growing_season_length is computed. The definition stays the same, but the new method uses two calls to xc.run_length.first_run. The computation can be slower, but the memory use is stable with large datasets and dask. See Ouranosinc/xclim-benchmark#3.

Doing so, I also added an input argument to the indicator so that it can run in the southern hemipshere. Supplying mid_date = '01-01' and freq='AS-Jul' performs the calculation with a 6 months offset.

But here is a question. Right now, we define the start date as the first day with N consecutive days above a threshold, anywhere in the year, but the end date has to happen after the 1st of July. But couldn't there be an edge case where the growing season length starts after the 1st of July?
May be @Paattrriicckk has an opinion?

While implementing the tests, I stumbled upon a bug in xc.run_length.first_run_ufunc and xc.run_length.windowed_run_*_ufunc. It appears that when getting a dask array, xr.apply_ufunc first throws an empty array in. But xc.run_length.rle1d returns None in that case, which made other numpy operation fail further down. I modified the output for this edge case in a way that fixed the problem.

  • Does this PR introduce a breaking change?

No.

@aulemahal aulemahal added bug Something isn't working enhancement New feature or request standards / conventions Suggestions on ways forward labels Jan 17, 2020
@aulemahal aulemahal self-assigned this Jan 17, 2020
@Zeitsperre Zeitsperre requested a review from huard January 17, 2020 21:31
@coveralls
Copy link

Pull Request Test Coverage Report for Build 1489

  • 19 of 19 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.3%) to 91.183%

Totals Coverage Status
Change from base Build 1486: 0.3%
Covered Lines: 1696
Relevant Lines: 1860

💛 - Coveralls

@coveralls
Copy link

coveralls commented Jan 17, 2020

Pull Request Test Coverage Report for Build 1490

  • 19 of 19 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.3%) to 91.183%

Totals Coverage Status
Change from base Build 1486: 0.3%
Covered Lines: 1696
Relevant Lines: 1860

💛 - Coveralls

@aulemahal aulemahal merged commit 28db637 into master Jan 20, 2020
@aulemahal aulemahal deleted the improve-growing-season-length branch January 20, 2020 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request standards / conventions Suggestions on ways forward
Projects
None yet
Development

Successfully merging this pull request may close these issues.

growing season length memory use
3 participants