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
rechunk() sometimes lead to arrays with non-regular chunks (dask==2025.1.0) #11713
Rechunking with 'auto' sometimes lead to arrays whose chunks are not regular, making dask.array.to_zarr() fail (the validation _check_regular_chunks() from dask.array.core fails. This is shown in the example below. Passing explicit chunk dimensions instead of 'auto' fixes the problem. Bug reproducible with dask==2025.1.0.
Related to: #11544. The bug was originally reported from @christinedien in the context of the spatialdata package. I kept the dimensionalities of the original bug report in the code example below.
Minimal Complete Verifiable Example:
importdask.arrayasdafromdask.array.coreimport_check_regular_chunksimportpytest# Function to create a lazy zero-filled dask arraydefcreate_lazy_zeros(shape, chunks, dtype='uint16'):
returnda.zeros(shape, chunks=chunks, dtype=dtype)
# Create the mock array with lazy zerosdefcreate_mock_array():
# Define the shape and chunks for scale0shape= (1, 25778, 35416)
chunks= (1, 4096, 4096)
# Create a lazy zero-filled dask arraydata=create_lazy_zeros(shape, chunks)
returndata# Create the mock arraymock_array=create_mock_array()
# Slice the arraysliced_array=mock_array[:, :13000, 15000:35000]
print('Chunks before rechunking')
print(sliced_array.chunks)
# Rechunk the array with 'auto'sliced_array_auto=sliced_array.rechunk('auto')
print('Chunks after rechunking with auto')
print(sliced_array_auto.chunks)
# Check for regular chunkswithpytest.raises(AssertionError):
assert_check_regular_chunks(sliced_array_auto.chunks)
# Rechunk the array with a fixed chunk sizeFIXED_CHUNK=4096sliced_array_fixed=sliced_array.rechunk((1, FIXED_CHUNK, FIXED_CHUNK))
print(f'Chunks after rechunking with a fixed chunk size (FIXED_CHUNK)')
print(sliced_array_fixed.chunks)
# Assert that chunks are regularassert_check_regular_chunks(sliced_array_fixed.chunks)
Hi @AAYUSH-SPIDEY-SHARMA, I am not a maintainer of dask so I do not have triaging rights. We need to wait for a maintainer. Thanks for the interest meanwhile! 😊
Deviating from regular chunks was an intentional decision to improve efficiency of computations. So that part works as expected. I agree though that the default experience when writing to zarr should be better and just work through injecting a rechunk to get the required chunking
Thank you for your comment. What I find confusing is that calling sliced_array.rechunk('auto') seems to have no effects. I think it could be made cleared that the new default behavior for 'auto' is to keep the chunks irregular.
Do you have a reproducer that is actually hitting this error?
if not _check_regular_chunks(arr.chunks):
# We almost certainly get here because auto chunking has been used
# on irregular chunks. The max will then be smaller than auto, so using
# max is a safe choice
arr = arr.rechunk(tuple(map(max, arr.chunks)))
this should protect against the problem you are seeing
I tracked this task here scverse/spatialdata#872 (not urgent). Meanwhile if you think your approach is enough, I think this issue can be closed. Thanks again!
Yeah I saw this, but do you have a unit test or something similar that explains how you got to this exception? I'd like to fix this in Dask itself so that you don't have to handle this in your library
Ah got it. The real code triggering this was case basically the one that I posted as first post, with the exception of replacing _check_regular_chunks(sliced_array_auto.chunks) with sliced_array_auto.to_zarr().
I'll make a snippet now, simplifying the code above.
This completes for me without raising because the rechunk we added in Dask hits and smoothes out the chunks. Does this raise for you? If yes, I'd be curious about the traceback
fails with 2025.1.0. Instead, the one using to_zarr() works on 2025.1.0. I could not try the real world example on 2025.1.0 because spatialdata does not support the latest dask (due to the .attrs missing).
So it seems that no further changes on the dask size for this bug are needed. Wdyt?
Activity
AAYUSH-SPIDEY-SHARMA commentedon Feb 5, 2025
hi @LucaMarconato i would like to work on this issue , please can you assign it to me.
LucaMarconato commentedon Feb 6, 2025
Hi @AAYUSH-SPIDEY-SHARMA, I am not a maintainer of
daskso I do not have triaging rights. We need to wait for a maintainer. Thanks for the interest meanwhile! 😊AAYUSH-SPIDEY-SHARMA commentedon Feb 7, 2025
@LucaMarconato thank you bro, for this information.....
phofl commentedon Feb 10, 2025
Deviating from regular chunks was an intentional decision to improve efficiency of computations. So that part works as expected. I agree though that the default experience when writing to zarr should be better and just work through injecting a rechunk to get the required chunking
LucaMarconato commentedon Feb 10, 2025
Thank you for your comment. What I find confusing is that calling
sliced_array.rechunk('auto')seems to have no effects. I think it could be made cleared that the new default behavior for'auto'is to keep the chunks irregular.phofl commentedon Feb 11, 2025
Do you have a reproducer that is actually hitting this error?
this should protect against the problem you are seeing
LucaMarconato commentedon Feb 11, 2025
Yes, I implemented a workaround here https://github.com/scverse/spatialdata/pull/861/files, I could use the code you suggest instead. In this way I don't have to hardcode (or have the user decide):
CHUNK_SIZE = 1024.LucaMarconato commentedon Feb 11, 2025
I tracked this task here scverse/spatialdata#872 (not urgent). Meanwhile if you think your approach is enough, I think this issue can be closed. Thanks again!
phofl commentedon Feb 11, 2025
Yeah I saw this, but do you have a unit test or something similar that explains how you got to this exception? I'd like to fix this in Dask itself so that you don't have to handle this in your library
LucaMarconato commentedon Feb 11, 2025
Ah got it. The real code triggering this was case basically the one that I posted as first post, with the exception of replacing
_check_regular_chunks(sliced_array_auto.chunks)withsliced_array_auto.to_zarr().I'll make a snippet now, simplifying the code above.
LucaMarconato commentedon Feb 11, 2025
Here is it:
phofl commentedon Feb 11, 2025
This completes for me without raising because the rechunk we added in Dask hits and smoothes out the chunks. Does this raise for you? If yes, I'd be curious about the traceback
phofl commentedon Feb 11, 2025
Any chance you are on 2024.11.2? I think we had one release without this automatic rechunking functionality.
LucaMarconato commentedon Feb 11, 2025
Good point! My first code snipped (the one using
fails with
2025.1.0. Instead, the one usingto_zarr()works on2025.1.0. I could not try the real world example on2025.1.0becausespatialdatadoes not support the latestdask(due to the.attrsmissing).So it seems that no further changes on the dask size for this bug are needed. Wdyt?
phofl commentedon Feb 11, 2025
Yes, correct. I think the bug has been fixed in 2024.12.0. I am closing this one