You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rechunking error when saving a queried raster element #478
I ran into this error just now, trying to save a spatial query.
I chunked the image before parsing at the dask image object type.
any clues on how to deal with this?
I ran into this error just now, trying to save a spatial query. I chunked the image before parsing at the dask image object type. any clues on how to deal with this?
You can manually rechunk the images before you save. @LucaMarconato had this in an issue somewhere I just can't find it to reference now. Make sure you have the newest version of dask.
def rechunk(msi):
for scale in msi.keys();
msi[scale]['image'] = msi[scale]['image'].chunk('auto')
sdata_query = spatialdata.polygon_query(...)
rechunk(sdata_query['morphology_mip'])
rechunk(sdata_query['morphology_focus'])
sdata_query.write('query.zarr')
Thanks for reporting. I have tried reproducing this bug in the latest main (incoming release) but I could not and the saving worked without problems. Please let me know if the bug is still open for you with the latest main (or please let me know after we make the new release).
If it is still open, it would be very helpful if you could share a minimal working example as a reproducible script. In doing that, it would be ideal if you could use the blobs() dataset:
0.3.0
/opt/homebrew/Caskroom/mambaforge/base/envs/sdata_v3/lib/python3.12/site-packages/anndata/_core/anndata.py:401: FutureWarning: The dtype argument is deprecated and will be removed in late 2024.
warnings.warn(
/opt/homebrew/Caskroom/mambaforge/base/envs/sdata_v3/lib/python3.12/site-packages/spatialdata/models/models.py:1053: UserWarning: Converting `region_key: region` to categorical dtype.
return convert_region_column_to_categorical(adata)
0.3.0
INFO The Zarr backing store has been changed from None the new file path: /Users/jnimoca/Desktop/test.zarr
/opt/homebrew/Caskroom/mambaforge/base/envs/sdata_v3/lib/python3.12/site-packages/anndata/_core/anndata.py:401: FutureWarning: The dtype argument is deprecated and will be removed in late 2024.
warnings.warn(
/opt/homebrew/Caskroom/mambaforge/base/envs/sdata_v3/lib/python3.12/site-packages/spatialdata/models/models.py:1053: UserWarning: Converting `region_key: region` to categorical dtype.
return convert_region_column_to_categorical(adata)
I am not sure why, but the issue of writing to an external drive is blocking the sdata.write()
I am now trying to write my data as sdata into my desktop 🙃
EDIT: it failed
EDIT2:
somehow writing to SSD is working after a couple of kernel restarts...
this worked as expected
Hi @josenimo, the chunk('auto') bug is now fixed, the solution is already in main, but you can also manually rechunk with the code used in the PR linked to this issue #821. Basically passing the chunks directly instead of 'auto'. The reason why this occurred is discussed here: dask/dask#11713. So, the bug is fixed with 2024.12.0, but we do not support it yet.
Regarding the problem that you had while writing to the SSD, it would be great if you could share more info on it (in a separate issue). It doesn't seem to be caused by spatialdata. It could be a problem of zarr or something in between (anndata). I'd try to reproduce it with spatialdata, and if you can, then with anndata, and finally try to reproduce it with zarr. In this way the best repository to discuss it is identified.
I will now close the current issue as it is addressed as detailed in the previous comment.
Activity
josenimo commentedon Dec 1, 2024
Hey @LucaMarconato
I ran into this error just now, trying to save a spatial query.
I chunked the image before parsing at the dask image object type.
any clues on how to deal with this?
versions:
Details
wakelin-g commentedon Dec 22, 2024
You can manually rechunk the images before you save. @LucaMarconato had this in an issue somewhere I just can't find it to reference now. Make sure you have the newest version of
dask.LucaMarconato commentedon Jan 5, 2025
Thanks for reporting. I have tried reproducing this bug in the latest
main(incoming release) but I could not and the saving worked without problems. Please let me know if the bug is still open for you with the latest main (or please let me know after we make the new release).If it is still open, it would be very helpful if you could share a minimal working example as a reproducible script. In doing that, it would be ideal if you could use the
blobs()dataset:Thank you!
josenimo commentedon Feb 11, 2025
Hello friends,
So I tried doing what I was doing with the blobs dataset, and there seems to be an issue writing.
Traceback
I ran the same code, but writing to my desktop:
I am not sure why, but the issue of writing to an external drive is blocking the sdata.write()
I am now trying to write my data as sdata into my desktop 🙃
EDIT: it failed
EDIT2:
somehow writing to SSD is working after a couple of kernel restarts...
this worked as expected
josenimo commentedon Feb 11, 2025
I tried out rechunking with the approach that @wakelin-g recommends.
It runs into this Value Error:
josenimo commentedon Feb 11, 2025
I see many issues with dask so I am just letting you know what Dask I am using:
LucaMarconato commentedon Feb 11, 2025
Hi @josenimo, the
chunk('auto')bug is now fixed, the solution is already in main, but you can also manually rechunk with the code used in the PR linked to this issue #821. Basically passing the chunks directly instead of'auto'. The reason why this occurred is discussed here: dask/dask#11713. So, the bug is fixed with2024.12.0, but we do not support it yet.LucaMarconato commentedon Feb 11, 2025
Regarding the problem that you had while writing to the SSD, it would be great if you could share more info on it (in a separate issue). It doesn't seem to be caused by
spatialdata. It could be a problem ofzarror something in between (anndata). I'd try to reproduce it withspatialdata, and if you can, then withanndata, and finally try to reproduce it withzarr. In this way the best repository to discuss it is identified.I will now close the current issue as it is addressed as detailed in the previous comment.