Unupdated type check against `csr_matrix` leads to a bug in `Hazard.write_hdf5()`

[spjuhel]

Describe the bug
Trying to write a Hazard with Hazard.write_hdf5() raises the following warning and does not write the intensity matrix:

2026-03-09 11:24:28,337 - climada.hazard.io - WARNING - write_hdf5: the class member intensity is skipped, due to its type, csr_array, for which writing to hdf5 is not implemented. Reading this H5 file will probably lead to intensity being set to its default value.

This is related to #1255, and #5a6d536

Expected behavior

Hazard.write_hdf5() should not raise a warning and correctly write the object.

Suggested way forward

1. We can enforce a csr_matrix type here (probably preferred as this is the real type we use):

return sparse_coo.tocsr() # Convert sparse.COO to scipy.sparse.csr_matrix
to
return csr_matrix(sparse_coo.tocsr()) # Convert sparse.COO to scipy.sparse.csr_matrix

5a6d536#diff-3175d04f0013b63b2662d6ced577cceeb7d458cc2a41d4711bbfff7f8577f0cbR61

or

2. Change the type check in the hdf5 writer here:

climada_python/climada/hazard/io.py

Line 920 in bb95959

elif isinstance(var_val, sparse.csr_matrix):

(probably other writers too)

[peanutfun]

After #1261, the type of the matrix should always be csr_matrix, and not csr_array. We could support csr_array but I don't see a clear use case. If a user modified the object and inserted an array, it's likely that the code breaks elsewhere, see https://docs.scipy.org/doc/scipy/reference/sparse.migration_to_sparray.html. So although the writer might simply work with csr_array, I am fine with the warning and not supporting it for now.

[spjuhel]

Indeed, I found and wrote this issue before #1261, this issue should no longer be relevant.