Closed JoranAngevaare closed 2 months ago
I am also encountering some of the issues described here (and similar once related to coordinates). For some models the longitude fixing seems to screw the data, as also experienced by @Quentin-Bourgeois. Is a fix for this issue in the pipeline @jbusecke?
Hi @JoranAngevaare and @bguillod. Very sorry for the long radio silence here. Trying to catch up with a lot of maintenance after working on the new Pangeo/ESGF CMIP6 Zarr data ingestion.
First of all, thanks a lot for the carefully crafted report here @JoranAngevaare. And even more for putting in a fix for this. Ill reopen the PR and continue discussion over there?
Thanks a lot for this great tool that comes in super handy for harmonizing CMIP data
The bug
When using data with more than 360 lon coordinates, the
replace_x_y_nominal_lat_lon
will not work as a 360 periodicity is assumed in_interp_nominal_lon
. I noticed this behavior inEC-Earth-Consortium EC-Earth3 ssp585 r1i1p1f1 Amon tas gr v20200310
, which has this subdegree gridding (lon
being 512 datapoints long).Expected behavior
Don't suffle the data when interpolating with sub-degree longitude gridding. This can be solved by not assuming a 360 periodicity.
Underlying cause:
numpy.interp
takes the period argument, but this is in thex-coordinate
, however, in_interp_nominal_lon
, the period is set to 360, this causes funky behavior in this function when you feed it an array with >360 entries, as they are sorted by their arg index.MWE:
Maybe a small example might be helpful here:
This second imagine is clearly not what we'd hoped for.
Versions
Related PRs/Issues
I believe https://github.com/jbusecke/xMIP/issues/93 is also related to this and https://github.com/jbusecke/xMIP/pull/79 might be where the bug was introduced.
One way this might be solved is by replacing the above mentioned line as is done in this PR: https://github.com/jbusecke/xMIP/pull/296