Closed Mikejmnez closed 1 year ago
FYI the current Oceanography image on Sciserver has xarray = 2023.2
, for which there is no trouble.
More context on the erro (see utils.py
lines 767 + ):
maskH = _xr.ones_like(ds["YG"])
maskH = maskH.where( _np.logical_and(ds["YG"] >= YRange[0], ds["YG"] <= YRange[-1]), 0)
maskH = maskH.assign_coords(Yp1=_np.arange(len(maskH["Yp1"])), Xp1=_np.arange(len(maskH["Xp1"])))
dmaskH = maskH.where(maskH, drop=True)
The last line is being flagged as error in xarray 2023.3
. In order to have tests passing, we have to:
dmaskH = maskH.where(maskH.compute(), drop=True)
PR #334 introduces a workaround to this issue.
I am keeping this issue open, as we need to investigate whether mask.compute()
is a good idea or not in terms of performance (perhaps there isn't much loss). Or, perhaps we need to rethink how to mask the coordinates.
I think compute is OK here. drop=True
silently does compute (or at least used to), as it needs to evaluate which data can be dropped.
That is reassuring. I was a little bit worried that .compute()
would be costly in terms of performance for grids like LLC4320 (in the case a cutout region is close to the entire domain). I am looking into this. It may lead to O(1-3) minutes at worst (although that may depend on the current Sciserver usage). More on this to come
Description
xarray version 2023.3.
Simplest example to reproduce the error: Live demo notebook in binder:
The last line fails to run. The (relevant) traceback:
the error being:
Quick fix for now,
pin
xarray
to version <= 2023.2.This might be a good opportunity to see if we can start using
xoak
to find indexes instead .