Multi-Hazard impacts and Hazard TimeSeries class and a method to generate a time series from a probabilistic event set

[ValentinGebhart]

As discussed with @chahank and @spjuhel, we think about creating a hazard time series class. This could be instantiated ideally with data from a time series (e.g., from climate simulations), or can be generated by sampling from a probabilistic event set.

Uses

• The time series can be the basis for a story line (worst-case event, successive events, ...).
• It can be used to create an impact time series (ideally using some model of recovery).
• At some future point, such (hazard or impact) time series objects can be the basis of multi-hazard risk assessments.

Implementation suggestion
class: Hazard objects would in principle be sufficient to store all information of such time series. To store several time series in a single object, one could add a "time_series_id" attribute. If we want to use the current date storing of CLIMADA, the time step of the series would have to be at least one day. For clarity, we suggest creating a new class, e.g. HazardTimeSeries, that inherits from the Hazard class, to clearly separate that the object is a time series.

sampling: When sampling from a probabilistic event set, the users have to input a parameter indicating the time step of the time series. Then, for each time step of the series, the number of events is sampled. Then events are drawn (weighted by the frequencies/probabilities). In this way, the HazardTimeSeries object can include time steps with no events and time steps with several events, so the date attribute could look like [2030, 2030, 2031, 2034]

Questions

• Does it make sense to implement this in a new class? Does it make sense that this class inherits from the Hazard class?
• For the time when we want to do multi-hazard analysis, is it enough to have "single hazard" time series? The time series of different hazards can be combined in later processing (on impact side?).

[chahank]

As discussed, this is a great idea!

I am not yet sure whether making a specific Hazard class is the way to go. You could already do all the book-keeping using the name and date fields of the existing class.

As a concrete question: What would be a use of a time_series_id attribute that cannot already be done with the existing name attribute?

[ValentinGebhart]

Yes, I agree that there would be enough space for book-keeping in the standard attributes of the Hazard class (even though e.g. the name attribute would then generally be ambigious, it would sometimes be a time series id and sometimes simply a name?).

I think the general reason to either have a new class or a new attribute is to be able to tell directly from an object instance if it represents a time series or merely a "classic Hazard object". If there are downsides to this though, I'd be ok to just encode it in the name attribute for instance.

[chahank]

Good point!

At the moment the philosophy was more of having a few general classes, rather than several specific ones. We might revise this. For hazard, one could think of a time-hazard, a single-event-hazard, a forecast-hazard, a probabilistic-hazard, ... Not sure what is the best course of action.

[ValentinGebhart]

Here are two possible user journeys about what to do with the Hazard time series object. It goes beyond merely the hazard time series (impact time series and multi-hazard impact time series) but might highlight what features or structure would be appropriate here.

Happy for your thoughts!

[chahank]

Great!

Implementation-wise, it looks to me that the first part can also be split into two parts to make the implementation more manageable. Going from a probabilistic set to a time-series is somehow a separate task (as shown in the graphic by it being a loop at the beginning).

I also see a lot of overlaps with existing or partially existing features, which is great. For bookkeeping:

• The Multi-impact time series is in parts in the util for yearsets and the code from the publication by Zelie and Carmen
• The hazard time-series is the natural complement to the interpolated RiskTrajectory

With which one of the three features do you think we should start with?

[ValentinGebhart]

I think it would make sense to

• First implement the hazard time series (together with the sampling method, and compatible with the hazard part of the risk trajectory), because all the rest relies on this one?
• Second would be the impact time series (potentially coupled to the risk cube, i.e. changing exposure and vulnerability)
• Third would be the multi-impact time series (potentially recycling code from the paper by Zelie and Carmen)