Rewrite TestRPmatrix::test_local_exceedance_imp_pass to not rely on loading data

[riley-brady]

Describe the bug
Following the simple installation guide, the base unit tests currently fail (for a single test). This is a simple roundoff error failure for test_local_exceedance_imp_pass.

FAILED test_impact.py::TestRPmatrix::test_local_exceedance_imp_pass - AssertionError: 2916964966.388227 != 2916964966.388219 within 5 places (8.106231689453125e-06 difference)

To Reproduce
Steps to reproduce the behavior/error:

1. mamba create -n climada_env -c conda-forge climada
2. mamba activate climada_env
3. python -m unittest climada.engine.test.test_impact

Expected behavior
Tests should pass!

Climada Version: 4.1.0

System Information (please complete the following information):

• Operating system and version: MacOS 14.5. M3 Max chip.
• Python version: 3.9.18

Additional context

• This issue shows up with the most barebones install of just climada. It persists with climada-petals installed.
• I tried uninstalling bottleneck but this didn't do the trick. I've found in the past that bottleneck can lead to roundoff level issues (bottleneck : Wrong mean for float32 array pydata/xarray#1346, Disable bottleneck by default? pydata/xarray#7344).
• Likely has to do with updates in versioning of numpy, xarray, bottleneck, etc.

[peanutfun]

@riley-brady Thank you for your report. We do not observe this issue in our testing pipeline. As the test loads data from Excel and HDF5 files, the issue might be related to particularities of the involved libraries on your system.

Nonetheless, the test can be considered legacy because it does not follow our new unit test standards. I will therefore transform this issue into a task to rewrite the test, such that it does not rely on reading data.

[peanutfun]

@riley-brady What I forgot to mention: If this is the only failing test in your installation, I think you can safely ignore it for now ✌️

[riley-brady]

Thank you! Yes, agreed it does not impact use of climada. I agree that it's likely library-dependent. I tried with and without bottleneck installed, which didn't change anything. But I think it's a roundoff/precision issue related to something like that. Thanks!