Impact read hdf5 fails if hazard event name is not a string

[chahank]

Similarly to issue #789 , saving an impact to hdf5 if the hazard name is not a list of strings causes issues when the data is read again.

Precisely, the attribute impact.event_name must be a list of strings at the moment of saving to hdf5 impact.to_hdf5, or the reading method impact.from_hdf5 should be able to handle non-numerical values.

[peanutfun]

This is not an issue with writing, but with reading:

climada_python/climada/engine/impact.py

Line 1246 in e412222

kwargs["event_name"] = list(file["event_name"].asstr()[:])

Because "event_name" was always specified as a list of strings, I wrote code that only reads it as such. We could adapt that, too.

[chahank]

Well, the fact is that we do not enforce type on the impact objects. So, either we need to change that or update the over-restrictive read method.

[peanutfun]

How to continue here? Do we want to read other values than strings or do we want a better error message if the values are not strings? What do we do in this case? Continue by setting "default" event names or only throw an error?

[peanutfun]

@chahank @sarah-hlsn

[sarah-hlsn]

Thanks, @peanutfun for the reminder. To be honest I don't think I understand enough about to implications of any of the options you guys mentioned to give an educated opinion on this. I'd be happy to make a PR for any option you think is best though!

[peanutfun]

Do we want to read other values than strings or do we want a better error message if the values are not strings? What do we do in this case? Continue by setting "default" event names or only throw an error?

@chahank This does not seem to be a pressing issue so I would like us to take a pragmatic decision here and resolve it.

[chahank]

Agreed!

[peanutfun]

#894 proposes a solution that reads other data types, but issues a warning that event_name cannot be decoded

[peanutfun]

Decision from discussion in #894:

• We only write an Impact object if event_name contains strings exclusively. If it does not, we throw an error instead of writing.
• When reading, we expect strings stored in event_name. If they are not, we throw a warning and all str() on each element, potentially ending up with nonsensible values. But event_name is ensured to be strings after reading.

[emanuel-schmid]

solved by #894