Open bjarthur opened 3 months ago
julia> versioninfo()
Julia Version 1.10.2
Commit bd47eca2c8a (2024-03-01 10:14 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: macOS (arm64-apple-darwin22.4.0)
CPU: 12 × Apple M2 Max
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)
Environment:
JULIA_PROJECT = @.
JULIA_EDITOR = vi
(jl_a3hv6U) pkg> st
Status `/private/var/folders/s5/8d629n5d7nsf37f60_91wzr40000gq/T/jl_a3hv6U/Project.toml`
[0703355e] DimensionalData v0.26.3
⌅ [3c3547ce] DiskArrays v0.3.23
[90b8fcef] YAXArrayBase v0.6.1
[c21b50f5] YAXArrays v0.5.4
[0a941bbe] Zarr v0.9.2
Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated`
(jl_a3hv6U) pkg> st --outdated
Status `/private/var/folders/s5/8d629n5d7nsf37f60_91wzr40000gq/T/jl_a3hv6U/Project.toml`
⌅ [3c3547ce] DiskArrays v0.3.23 (<v0.4.1): DiskArrayTools, Zarr
DD doesnt know anything about chunks...
If you cant reproduce a bug with a basic DimArray
or other objects defined here, take the issue to the extending package first, in this case YAXArrays.jl.
The problem is in the internal object, not DD
I guess the only way will be to bring the data into memory first:
E = DimArray(D.data[:,:,:], dims(D))
This is not a YAXArray issue, because YAXArrays is only used to construct the data and to open the underlying Zarr data. The object that is failing is a normal DimArray with a DiskArray as data.
This seems to rather be an issue with calling copyto!
on a DiskArray but I am wondering why this is not a problem on NetCDF or GDAL files. This call happens in the print_matrix function of DD.
It might be that YAXArrays is constructing a slightly broken zarr file here.
Do you also run into this problem on actual data that you get from somewhere else or is it only a problem when you save the data with YAXArrays?
Either DiskArrays.jl not working with some base method that works on normal arrays, or YAX constructing something broken. But I assumed it was YAX making a broken disk array.
I looked into it a bit more and it seems to be an issue DiskArrays not handling the copyto! case when one of the indices is length zero. This happens when the size of the terminal is too small to show something but it still tries to retrieve some data. I will open a DiskArrays.jl issue.
i'm getting a "ERROR: ArgumentError: Chunk sizes must be strictly positive" error, yet the chunk sizes seem to be positive.