Adding OEP and AEP for event-based risk and damage calculations

[CatalinaYepes]

Extend the aggregated loss curves in event-based risk and damage calculations to include OEP and AEP

Background

For event-based damage and risk calculations, the current implementation of the engine estimates aggregated loss exceedance curves that describe the probabilities of exceedance of the total loss across the entire portfolio for a set of loss values within a given time span (or investigation interval).

The aggregated loss curves are derived, for each realization and specified statistics, by estimating the exceedance probability (EP), and corresponding return period, of each event capable of generating a loss (above the minimum_asset_loss threshold) present in the event-loss table.

These curves can be generated for all loss types indicated in the configuration file ( structural, nonstructural, contents, occupants, or business_interruption, and more recently, it’s possible to include area, number, and residents), as well as the tags specified in the aggregate_by, if any.

What is needed

The catastrophe modelling industry might require loss curves that consider only the maximum loss in a year, commonly referred to as Occurrence Exceedance Probability (OEP), and loss curves that consider the sum of losses in a year, commonly referred to as Aggregate Exceedance Probability (AEP).

When the calculation includes reinsurance treaties, the reinsurance curves (aggregated loss curves for retention, claim, cession per treaty and overspills) must also be estimated for OEP and AEP.

Implementation

The engine should provide three types of aggregated loss curves:

• ep: aggregated loss curves considering each event individually (EP). Currently implemented in the engine.
• oep: aggregated loss curves that consider only the maximum loss in a year (OEP).
• aep: aggregated loss curves that consider the sum of losses in a year (AEP).

This will require adding to the configuration file the parameter

aggregate_loss_curves_type = ep, oep, aep

By default, all event-based damage and risk calculations have aggregate_loss_curves_type = ep.

Note:
The aggregation of losses coming from the event-loss table should consider the year and the ses

Outputs

The same output files can be generated, Aggregate Risk Curves (aggcurves) and Aggregate Risk Curves Statistics (aggcurves-stats), but with a column for each aggregate_loss_curves_type indicated.
The headers could be named risk_value_ep, risk_value_oep and risk_value_aep respectively.

To maintain consistency across outputs, some refactoring is recommended:

Event-Bases Risk

The image below shows an example of the outputs in the current demo:

For this type of calculator:

• The headers loss_value and loss_ratio can be adjusted to ep_risk_value and ep_risk_ratio respectively,
• The header loss can be adjusted to ep_risk_value (for some reason the loss_ratio is not included in the aggcurves-stats),

Event-Based Damage

The image below shows an example of the aggcurves output in the current demo when including an additional consequence type (in this case, injured).

For this type of calculator:

• A column for the consequence_type (injured, losses) can be created for the aggcurves and aggcurves-stats outputs
• Report the values similar to the event-based risk, as two columns for ep_risk_value and ep_risk_ratio.

Reinsurance

When event-based risk calculations include reinsurance schemes, the output Reinsurance curves produces the aggregated loss curves for the retention, claim, cession per treaty and overspills. Considering that this output can include several columns, when users includes different aggregate_loss_curves_type, an file can be exported for each type: reinsurance-aggcurves-ep, reinsurance-aggcurves-oep, and reinsurance-aggcurves-aep.

[ptormene]

As requested by @CatalinaYepes, I am listing here the deviations and missing details in the current implementation, with respect to the above specifications:

• the new ini parameter is called aggregate_loss_curves_types and its value is ,_oep,_aep by default, meaning that loss, loss_aep and loss_oep will be computed, unless otherwise specified. It is a fast operation, so it's worth computing everything by default. The reason of the seemingly strange format of the parameter is because it is convenient for the sake of the implementation of this feature;
• in order to keep consistency with the past, the field that was called loss before will not be renamed into loss_ep;
• consequences other than loss are still unchanged
• also reinsurance-related functionalities are not implemented yet

[CatalinaYepes]

LGTM to produce by default the 3 types of curves. However, I don’t like the way the new parameter was introduced, it does not follow the OQ job.ini standards.

aggregate_loss_curves_type = ,_oep ,_aep

• The comma is part of the parameter instead of the field separator (super confusing). Right now the separator is the space.

• If the user wants only EP curves, then the parameter should be set to aggregate_loss_curves_type = . It is ambiguous, but it works with the current implementation.

• The user can not get only OEP or AEP curves. if the parameter is set to `aggregate_loss_curves_type = ,_aep , the output includes EP and AEP. Any reason why we need to produce EP by default?

My recommendation is to implement the job.ini parameter as initially suggested
aggregate_loss_curves_type = ep, oep, aep
Where the comma is used to separate the fields. Internally, OQ can have a dictionary to name the functions as required:
{'ep':'', 'oep':'_oep', 'aep':'_aep'}

[ptormene]

The points discussed above have been addressed, so now the format for the aggregate_loss_curves_types parameter is as suggested, the EP curves are optional and also reinsurance curves are computed.
Please @CatalinaYepes, can you check if everything is in place or if you see anything missing?