Test Regressions early 2025

[keflavich]

This is mostly a record of test fixes I've put into #929, though there are some open questions embedded here. This should be closed by #929 .

Many tests have started failing without apparent reason. From the bottom:

np.testing.assert_equal(spec.value, data.mean(axis=(1,2,3)))
E       AssertionError: 
E       Arrays are not equal
E       
E       Mismatched elements: 1 / 4 (25%)
E       Max absolute difference among violations: 1.11022302e-16
E       Max relative difference among violations: 2.06620925e-16
E        ACTUAL: array([0.494653, 0.537324, 0.373168, 0.355505])
E        DESIRED: array([0.494653, 0.537324, 0.373168, 0.355505])

So some numerical error has crept in from some subpackage? This seems to hit all python versions.

This seems to be caused by a difference between nanmean and mean, so we'll compare to nanmean - but holy crap that's scary.

Above is addressed in commit 63d9227 in #929

E AttributeError: 'DaskSpectralCube' object has no attribute '_warn_slow' is actually on master. What the hell? How is this even possible? Did we just merge a failing PR? ....no.... this was added 5 years ago. Has class inheritance completely changed in python!? I'm losing my mind. #929 will try to fix this, but I have no clue what is happening.

test_arithmetic_warning[True]
>       with pytest.warns(UserWarning, match='requires loading the entire'):
E       Failed: DID NOT WARN. No warnings of type (<class 'UserWarning'>,) were emitted.
E        Emitted warnings: [ FITSFixedWarning("'datfix' made the change 'Set MJD-OBS to 50982.687794 from DATE-OBS'.")].

I fixed this by removing the dask warning check. Dask shouldn't warn about this.

This one seems major:

__________________________________________________________________________________________________________ test_statistics_withnans ___________________________________________________________________________________________________________

data_adv = PosixPath('/private/var/folders/k_/7qh4l0nn72b7qgq15pkd4hw40000gt/T/pytest-of-adam/pytest-30/test_statistics_withnans0/adv.fits')

    def test_statistics_withnans(data_adv):
        cube = DaskSpectralCube.read(data_adv).rechunk(chunks=(1, 2, 3))
        # shape is 2, 3, 4
        cube._data[:,:,:2] = np.nan
        # ensure some chunks are all nan
        cube.rechunk((1,2,2))
        stats = cube.statistics()
        for key in ('min', 'max', 'sum'):
>           assert stats[key] == getattr(cube, key)()
E           AssertionError: assert <Quantity nan K> == <Quantity nan K>
E            +  where <Quantity nan K> = min()
E            +    where min = getattr(DaskSpectralCube with shape=(4, 3, 2) and unit=K and chunk size (1, 2, 2):\n n_x:      2  type_x: RA---SIN  unit_x: deg...094 deg:   29.935209 deg\n n_s:      4  type_s: VOPT      unit_s: km / s  range:     -321.215 km / s:    -317.350 km / s, 'min')

spectral_cube/tests/test_dask.py:115: AssertionError

simple bug: the shape is not 2,3,4 for adv, it is 4,3,2. Fixed in bb9417c

When I run test_casafuncs.py tests in my environment, they pass, but in the tox environment, they fail:

FAILED ../../spectral_cube/tests/test_casafuncs.py::test_casa_read_basic[False-False] - ValueError: Unable to avoid copy while creating an array as requested.
FAILED ../../spectral_cube/tests/test_casafuncs.py::test_casa_read_basic[False-True] - ValueError: Unable to avoid copy while creating an array as requested.
FAILED ../../spectral_cube/tests/test_casafuncs.py::test_casa_read_basic[True-False] - ValueError: Unable to avoid copy while creating an array as requested.
FAILED ../../spectral_cube/tests/test_casafuncs.py::test_casa_read_basic[True-True] - ValueError: Unable to avoid copy while creating an array as requested.
FAILED ../../spectral_cube/tests/test_casafuncs.py::test_casa_read_basic_nomask - ValueError: Unable to avoid copy while creating an array as requested.

[cjwatson]

In case it's helpful, Debian CI indicates that the first issue here (nanmean vs. mean) was due to a change somewhere between dask 2024.5.2 and 2024.12.1.

[keflavich]

Thanks @cjwatson. I hadn't thought it was dask-related, but you're right to point that out.