Ouranosinc / xclim / 8251089024

92%

push

github

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... (continued)

3 of 3 new or added lines in 1 file covered. (100.0%)

8648 of 9588 relevant lines covered (90.2%)

6.97 hits per line