Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix map_blocks for DataArray with cftime and sdba_encode_cf (#1674)
### What kind of change does this PR introduced **tl;dr : me fix issue.** I think this issue stems from a change in recent xarray, but the case was untested by xclim. The solution was to iterate over a list that is "disconnected" from the dictionary. The issue occurs when a _DataArray_ that has a coordinate made of `cftime` objects is passed to a `map_blocks`-wrapped function and xclim's global option `sdba_encode_cf` is True. The previous encoding code was iterating over the coordinates with `coords.items()`. When it would modify a the cftime coord, this would fail as you can't modify a dictionary while it is being iterated upon. Only happens if the option to encode is activated, only happens if there is a cftime coord and only happens on `DataArray` objects. I'm not 100% sure why, but I think `Dataset.coords.items` does not map directly to a dict. We usually use `Dataset` objects in function wrapped by `map_blocks` (or `map_groups`). The culprit here was the polynomial's trend computation which uses a `DataArray`. ### Reason for the apparent dask-dependency The interesting part is that this bug does not depend on the fact that the data is using dask or not. But it led me to discover another "issue" or, rather, "edgecase" . In `xscen.adjust` we wrap the xclim call with options: ```python3 with xc.set_options(sdba_encode_cf=True, sdba_extra_output=False): out = ADJ.adjust(sim_sel, **xclim_adjust_args) ``` Here, for DQM, the `adjust` method is wrapped by `map_blocks`. When `sim_sel` uses dask, the actual adjustment is, of course, not executed here. Only when the computation is triggered will the adjustment function be run, and only then will it call the polynomial detrending. But at that moment, the `sdba_encode_cf` option is not set anymore! So the issue was not raised for the "dask" case. When `sim_sel` was not using dask, all the code was executed under the option statement and thus the issue was raised. Which is a bit dumb because the encoding is a micro-optimization made for dask, it's no use otherwise. ### Does this PR introduce a breaking change? No
- Loading branch information