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

Growing Season operators #1796

Merged
merged 6 commits into from
Jun 27, 2024
Merged

Growing Season operators #1796

merged 6 commits into from
Jun 27, 2024

Conversation

Zeitsperre
Copy link
Collaborator

@Zeitsperre Zeitsperre commented Jun 25, 2024

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)
    • (If applicable) Documentation has been added / updated (for bug fixes / features)
  • CHANGES.rst has been updated (with summary of main changes)
    • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

  • Adds the op keyword to growing_season_{start | end} indices and indicators, allowing for customizable threshold operators using indices.generic.compare().
  • Added the op operator to the indicator docstrings in English and French.
  • Clarifies a docstring typo in xclim.indices.growing_season_length

Does this PR introduce a breaking change?

Not really. The call signature has changed, but default behaviour is unchanged.

@github-actions github-actions bot added the indicators Climate indices and indicators label Jun 25, 2024
@Zeitsperre Zeitsperre changed the title Growing-season-operators Growing Season operators Jun 26, 2024
@Zeitsperre Zeitsperre marked this pull request as ready for review June 26, 2024 19:58
@Zeitsperre Zeitsperre self-assigned this Jun 26, 2024
Copy link
Collaborator

@aulemahal aulemahal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice thanks!

My comment can be addressed in a subsequent PR.

tests/test_indicators.py Show resolved Hide resolved
@github-actions github-actions bot added the approved Approved for additional tests label Jun 26, 2024
@coveralls
Copy link

Coverage Status

coverage: 90.595% (+0.01%) from 90.584%
when pulling 8e1e57b on growing-season-operators
into 98c251c on main.

@Zeitsperre Zeitsperre merged commit 307cfa3 into main Jun 27, 2024
32 checks passed
@Zeitsperre Zeitsperre deleted the growing-season-operators branch June 27, 2024 13:25
aulemahal added a commit that referenced this pull request Aug 1, 2024
<!--Please ensure the PR fulfills the following requirements! -->
<!-- If this is your first PR, make sure to add your details to the
AUTHORS.rst! -->
### Pull Request Checklist:
- [ ] This PR addresses an already opened issue (for bug fixes /
features)
    - This PR fixes #xyz
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGELOG.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added

### What kind of change does this PR introduce?

* Implements `generic.season`, a generic index function for computing
the start/end/length of seasons. Based on `run_length.season` but with
units management and the comparison.
* Divide `run_length.season` into `season_start`, `season_end`, plus the
existing `season_length`. The idea of grouping code together was good,
but it added a lot of unnecessary computations when only one facet is
needed (i.e. most cases). I think I was able to divide it elegantly,
using only one magic fast path.
* Rewrite `frost_free_season_start` and `frost_free_season_end`. Those
were not respecting the "season" definition. Now they do.

### Does this PR introduce a breaking change?
`frost_free_season_start` and `frost_free_season_end` have changed.
Their notion of "season" is not more strict. I think the difference not
significative for most cases. No tests needed a change, but again our
tests are very simple.

All season length indicators will now return 0 when no season is found
(no start). Previously, when no start was found we returned 0 when an
end was found and `nan` otherwise. I think the idea was to assume that
neither end nor start meant the data was probably wrong. But that's the
job of the missing checks, not the `run_length` helper. Thus I applied
the more logical rule : no season == 0 length.

I have reverted some changes of #1796, I'm sorry. I'm trying to
generalize the indicators and it made more sense that all aspects of the
same "growing season" were using the same exact arguments.

### Other information:
This allows indices to use run length function that return a DataArray
after being called with a DataArray. This "type preservation" will be
quite handy in my next PR, stay tuned!

Sadly, this branch is based off #1838 because I need both for PC.


### Ugh
The amount of copied docstring text and signatures is ridiculous. I
really want to remove all those one-liner indices and only keep the
indicators. But I fear this would be too breaking of a change as it
would remove elements from the API.
Right now, we have inconsistent indicators with inconsistent
documentation because everything was copy-pasted by hand with
incremental changes that were not always ported back to the other
indices.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Approved for additional tests indicators Climate indices and indicators
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ability to choose operator for Indicators growing_season_start/end
3 participants