Found while auditing xrspatial/mcda for backend parity. Several code paths written to support cupy and dask raise instead of returning results. The numpy paths are fine.
owa fails on every dask backend. _sort_descending in combine.py calls da.sort, which does not exist in dask.array (checked against dask 2025.7.0):
AttributeError: module 'dask.array' has no attribute 'sort'
This raises at graph construction for both dask+numpy and dask+cupy. The rest of owa is written for dask (the memory guard skips dask inputs, the order weights get wrapped with da.from_array), and there is no dask test for owa, so it slipped through.
owa also fails on cupy. The reshaped order-weight array stays numpy and is multiplied against the sorted cupy stack:
TypeError: Unsupported type <class 'numpy.ndarray'>
standardize(method="piecewise") fails on cupy and dask+cupy. On cupy, xp.interp gets numpy breakpoint/value arrays, which cupy.interp rejects:
NotImplementedError: Only int or ndarray are supported for a
On dask+cupy, _interp_block calls np.asarray(block) on a cupy chunk:
TypeError: Implicit conversion to a NumPy array is not allowed. Please use `.get()` to construct a NumPy array explicitly.
The same np.asarray(block) pattern breaks standardize(method="categorical") on dask+cupy.
sensitivity(method="monte_carlo") fails on cupy and dask+cupy. _monte_carlo in sensitivity.py reads template.values and score.values. For cupy-backed inputs (including dask+cupy after the eager criteria.compute()), .values triggers the implicit-conversion TypeError above.
Environment: cupy 13.6.0, dask 2025.7.0, CUDA available.
Not included here: constrain on cupy raises AttributeError: module 'cupy' has no attribute 'astype' inside xr.where. That is the known cupy 13.6 + xarray incompatibility affecting call sites repo-wide and is handled by a dependency pin, not an mcda change.
Found while auditing
xrspatial/mcdafor backend parity. Several code paths written to support cupy and dask raise instead of returning results. The numpy paths are fine.owa fails on every dask backend.
_sort_descendingincombine.pycallsda.sort, which does not exist in dask.array (checked against dask 2025.7.0):This raises at graph construction for both dask+numpy and dask+cupy. The rest of
owais written for dask (the memory guard skips dask inputs, the order weights get wrapped withda.from_array), and there is no dask test forowa, so it slipped through.owa also fails on cupy. The reshaped order-weight array stays numpy and is multiplied against the sorted cupy stack:
standardize(method="piecewise") fails on cupy and dask+cupy. On cupy,
xp.interpgets numpy breakpoint/value arrays, whichcupy.interprejects:On dask+cupy,
_interp_blockcallsnp.asarray(block)on a cupy chunk:The same
np.asarray(block)pattern breaksstandardize(method="categorical")on dask+cupy.sensitivity(method="monte_carlo") fails on cupy and dask+cupy.
_monte_carloinsensitivity.pyreadstemplate.valuesandscore.values. For cupy-backed inputs (including dask+cupy after the eagercriteria.compute()),.valuestriggers the implicit-conversion TypeError above.Environment: cupy 13.6.0, dask 2025.7.0, CUDA available.
Not included here:
constrainon cupy raisesAttributeError: module 'cupy' has no attribute 'astype'insidexr.where. That is the known cupy 13.6 + xarray incompatibility affecting call sites repo-wide and is handled by a dependency pin, not an mcda change.