Open pp-mo opened 1 year ago
I think there are some big questions over whether we really support cubes with string content at all, as this seems to have not worked for a long time : It didn't work for me at Iris 2.4.0 either (though with different error). There is also : https://github.com/SciTools/iris/issues/4412
We do support string coordinates, of course, and save them to netcdf. Because they are used for seasonal categories, e.g. here
I think there are some big questions over whether we really support cubes with string content at all, as this seems to have not worked for a long time : It didn't work for me at Iris 2.4.0 either (though with different error). There is also : #4412
UPDATE (Aug 2024, Iris 3.9). In fact, I find that Iris doesn't like the numpy fixed-width string dtypes like "S4" or "U7", because neither does netcdf4-python.
Instead, you are expected to use character arrays, dtype "S1" or "U1", containing fixed-length (padded) strings with a string-length dimension. That is standard practice for netcdf4-python and backwards-compatible with NetCDF3.
There are also variable-length strings (NetCDF "string" type). But CF does not seem to support these, and neither does Iris. That goes for all the variable-length types that were added in NetCDF4.
🐛 Bug Report
When cubes have string content (normally with dtype 'S1', and a string dimension), cube comparison fails .
How To Reproduce
Expected behaviour
Clearly, this should succeed and return
True
.Key info
Although it appears to be a failure of
dask.array.all_close
, I think this is really a numpy problemSo, perhaps we need to special-case character data so it doesn't use 'allclose' for comparison.
Environment
Latest 'main' branch Iris, Dask version '2023.5.0' Numpy version '1.24.2'