Stream: dask

Topic: unexpected result when multiplying two dask arrays


view this post on Zulip Mira Berdahl (May 07 2022 at 01:38):

Hi,
I'm running into a strange issue when I multiply two dask arrays who have the same dimensions. Each array has dimension z_t=60, but when I multiply them together the resultant array has only 16 z_t levels. When I manually compute the first 16 entries element by element, they do appear to be correct. I've added screenshots of the arrays, and the results of a very simple example of this issue. I cannot seem to understand what is going on here. Any help appreciated. Screen-Shot-2022-05-06-at-6.36.10-PM.png Screen-Shot-2022-05-06-at-6.36.18-PM.png

view this post on Zulip Keith Lindsay (May 07 2022 at 13:26):

@Mira Berdahl , z_t in the variable temp_converted has type float32, while z_t in the variable delta_level has type float64. This mismatch in types might be throwing off xarray's coordinate alignment code.
Please check out the thread in the ESDS General Interest stream from Oct 11, 2021, where Alice got tripped up by this sort of mismatch, and describes a workaround.

@Matt Long and @Deepak Cherian , this seems to be occurring because pop-tools is creating z_t as float64, while model output has z_t as float32 by default. Should pop-tools be changed so that the z_t that it generates is consistent with default model output?

view this post on Zulip Mira Berdahl (May 07 2022 at 22:00):

Thanks @Keith Lindsay , I would have never guessed this could be the problem. I used Alice's fix and it seems to be working now! Many thanks for the prompt reply.

view this post on Zulip Matt Long (May 10 2022 at 22:37):

I would support this change in pop-tools, perhaps even with a "precision" flag to enable either double or single precision.

view this post on Zulip Deepak Cherian (May 11 2022 at 15:02):

Opened an issue

view this post on Zulip Keith Lindsay (May 11 2022 at 15:14):

Thanks @Deepak Cherian . I'll work on a PR.


Last updated: May 16 2025 at 17:14 UTC