-
Notifications
You must be signed in to change notification settings - Fork 2
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
cos-lat averaging #125
cos-lat averaging #125
Conversation
This is a partial fix to #94. Fixing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments. I don't think the "cos-lat" think is compatible with curvilinear grids, but I'm not sure why it shouldn't be.
xscen/indicators.py
Outdated
if len(out.time) < 3: | ||
freq = ( | ||
ind.injected_parameters["freq"] | ||
if "freq" in ind.injected_parameters | ||
else ind.parameters["freq"]["default"] | ||
if "freq" in ind.parameters | ||
else ind.src_freq | ||
) | ||
else: | ||
freq = xr.infer_freq(out.time) | ||
else: | ||
freq = "fx" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think ii would be better to wrap this in a private function instead of having it twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two key points for the cos-lat averaging:
- No need to normalize the weights by their sum, I'm pretty sure xarray does this already.
- In agreement with what Pascal said, I believe cos-lat weighting should work fine with 2D curvilinear grids with a couple minor modifications (see comments).
Je me reprends, I found this blog : https://towardsdatascience.com/the-correct-way-to-average-the-globe-92ceecd172b7 @RondeauG your code was indeed correct. But I think curvilinear grid support is essential as one of the principal use case is with MRCC5 data. |
@RondeauG I found the challenge interesting and spent a bit too much time on this, but here are 3 ways of computing cell areas for the weighted average: We might not have However, there's another issue with |
# Conflicts: # HISTORY.rst # xscen/aggregate.py
I'll look into the links provided, though I feel like this might be another method entirely? As in, we'd have |
Also, with the changes, |
My "shapely" and "pygeos" functions are both based on the cos-lat approximation, so I would argue it's just a curvilinear-compatible version of The ESMF version is indeed another technique because it computes the cell area using other approximations. Note for shapely: the newest version (2.0) now merges the functionality of |
I updated my gist with a function that works with shapely 2.0. It is indeed the exact same as with |
# Conflicts: # HISTORY.rst
# Conflicts: # HISTORY.rst
# Conflicts: # HISTORY.rst
@aulemahal @mccrayc The first part of Pascal's code (using the
Meaning that when you multiply both, you get: ...which makes no intuitive sense to me? I would have expected weights to be curved, not linear like that? |
No I think this is ok! You are in a Oblique Mercator projection, which projects the globe unto a cylinder. The projection being centered at y = 0, in the center of your plot, it makes sense to me that the cell area decreases with https://en.wikipedia.org/wiki/Oblique_Mercator_projection Also, I found a way to compute areas (in meters) with |
# Conflicts: # HISTORY.rst # environment-dev.yml # environment.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good!
Semi-related:
As we currently have no bulletproof method, the choice makes sense. However, it seems to me that there's no reason to have such an array of methods for such a simple task. I guess that when we have a simple, light area-weighted mean method, we could remove everything else? Is there a use for a collection of imperfect algos ?
This would mean :
- fix bounds generation when crossing meridians in
cf_xarray
- generate
areacella
in m² from those bounds (usingpyproj
andshapely
)
Co-authored-by: Pascal Bourgault <bourgault.pascal@ouranos.ca>
for more information, see https://pre-commit.ci
That's why I deprecate However, I think that |
@mccrayc When you have time, a second review is needed since you "requested changes". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Co-authored-by: Pascal Bourgault <bourgault.pascal@ouranos.ca>
Pull Request Checklist:
pre-commit
hooks are installed/active in my local clone ($ pre-commit install
)number
) and pull request (:pull:number
) has been addedWhat kind of change does this PR introduce?
cos-lat
method toaggregate.spatial_mean()
mean
and added warnings toxesmf
_subset_file_coverage
to be more explicitcompute_indicators
when less than 3 timesteps were produced.Does this PR introduce a breaking change?
mean
and changes the name ofinterp_coord
tointerp_centroid
(still supportsinterp_coord
with a deprecation warning)Other information: