General support for multi-peril damage and loss calculations #10162

raoanirudh · 2024-11-26T08:53:04Z

Objectives

The objectives of this issue are (1) to document in a single issue some of the changes that have been introduced in the engine to support damage and loss calculations due to the earthquake related sub-perils of landslide and liquefaction, and the volcanic sub-perils of tephra or ash fall, lahars, lava flow, and pyroclastic flow, (2) to propose a workflow that can manage these new types of damage and loss calculations uniformly, as well as make it more convenient for users to extend the risklib to other perils and sub-perils, and (3) to provide initial proposals regarding methods to combine the damage or loss contributions from individual sub-perils for a given peril.

Background

Historically, the OpenQuake engine calculated building and infrastructure damage and losses based solely due to earthquake ground shaking.

In #4519, scenario damage and loss calculation support was added for volcanic hazards including tephra or ash fall, lahars, lava flow, and pyroclastic flow. This was implemented through the addition of a new calculation mode in #4577 named multi_risk. The hazard footprints are generated externally and imported into the engine for running the damage and loss calculations.

A module for computing hazard from earthquake-triggered “secondary perils” was added in #6048, and initial work to estimate damage and losses due to earthquake-triggered secondary perils was undertaken in #6081. Several additional geospatial liquefaction models were added in #8982 and a geospatial landslide model was added in #9906.

The engine has thus grown two separate strategies to calculate damage and losses due to hazards other than earthquake ground shaking as described above – the ‘multi_risk’ mode and the “secondary perils” approach.

In addition, exploratory work is being done by @naveenragur to import externally generated tsunami hazard footprints into the OpenQuake engine to run damage and loss calculations for both scenarios and stochastic event sets. Support for fault-displacement hazard, when added to the engine, will make it possible to run probabilistic fault displacement risk analyses starting from co-seismic surface‐fault displacement.

While the work done for #6081 made it possible to run damage and loss calculations for liquefaction (and for any "secondary peril" in general), it was not possible to run the risk calculations for multiple secondary perils simultaneously, or even along with the risk calculations for ground shaking, and neither was it possible to combine the damage/loss contributions from each factor in a meaningful way. A feature request to support simultaneous risk calculations for multiple sub-perils associated with an earthquake event was thus made in #9746, with a view to using the multi-sub-peril risk results for downstream applications in infrastructure connectivity loss assessment.

Proposal

To address the limitations in the current implementation and facilitate the engine’s ability to calculate damage and losses across multiple interconnected hazards, we propose the introduction of a “Peril” and “Sub-Peril” hierarchy. In this hierarchy, a “Peril” represents a primary hazard event, such as an earthquake or volcanic activity, while “Sub-Perils” denote specific phenomena triggered by the primary hazard, such as ground shaking, liquefaction, landslides, surface‐fault displacement, tsunami, or fire-following in the case of an earthquake, and tephra, lahars, lava flows, or pyroclastic flows in the case of volcanic activity. The user should be able to provide sub-peril-specific fragility and consequence models for the scenario_damage and event_based_damage calculators, or sub-peril-specific vulnerability models for the scenario_risk and event_based_risk calculators. The engine would then compute the damage and consequences separately for each sub-peril in the same calculation. This structure would allow for a clear grouping of related phenomena under a single main peril event, facilitating more coherent risk analyses and enabling the integration of all relevant sub-peril impacts given the main peril event.

The two existing approaches described in the background section—the “multi_risk” calculation mode and the “secondary perils” approach—could be unified and brought under this proposed structure. This unification will streamline the engine’s capabilities, eliminating the need for maintaining separate workflows, and enabling simultaneous risk calculations for multiple sub-perils which is not possible currently. By consolidating these approaches, the engine will be better equipped to combine and aggregate damage and loss contributions from all relevant sub-perils of a given event. The introduction of the "Peril" and "Sub-Peril" hierarchy and a clear structure for managing the ensuing risk calculation workflows should also help make risklib more amenable to adoption for multi-hazard risk applications. While explicit support for additional perils and sub-perils (e.g., Tropical Cyclone with sub-perils like Wind, Precipitation Flood, and Storm Surge) will require implementation by interested users, the changes proposed in this issue should make the process straightforward.

Figure 1 below illustrates the proposed workflow for scenario and event-based damage and consequence calculations involving earthquake and its sub-perils, and Figure 2 for scenario and event-based risk calculations for earthquakes.

Figure 1. Workflow for scenario and event-based damage and consequence calculations involving earthquake and its sub-perils

Figure 2. Workflow for scenario and event-based risk calculations involving earthquake and its sub-perils

Key Considerations

New job parameters `peril` and `subperil`

Proposal to introduce two new parameters peril and subperil in the job file, with the following permitted options:

peril = earthquake
subperil = ground_shaking, landslide, liquefaction, surface_rupture, tsunami, fire_following

or

peril = volcano
subperil = tephra, lahar, lava, pyroclastic_flow

where the subperil parameter can accept one or more of the permitted options available for the specified peril.

To maintain backward compatibility, for cases where the job file does not contain these two parameters, the default choices would be:

peril = earthquake
subperil = ground_shaking

Intensity measures

Currently, as of engine-3.21, the intensity measure types associated with earthquake-triggered landslides and liquefaction hazard calculations are all listed in hazardlib/imt.py. Three common intensity measure types associated with tsunami could be added: inundation depth, flow velocity, and momentum flux.

Amongst the intensity measures associated with volcanic hazards, only ASH (ash load) is currently listed in hazardlib/imt.py. Ideally, the intensity measure types associated with the other three volcanic hazards should also be formally declared in imt.py, for instance, flow thickness for lava flow, peak dynamic pressure for pyroclastic density currents, and impact pressure for lahars, in addition to the binary presence/absence IMT.

Subperil models or footprints

First, let's take stock of the different ways in which a subperil hazard is either calculated by the engine, or imported into the engine, as of engine-3.21.

Ground shaking

For ground shaking, three different options are available for calculating the ground motion fields with the engine, or for bringing in externally generated ground motion footprints using a csv or hdf5 file —

Job parameter gsim: for calculations where a single ground motion model is to be used (particularly in scenario calculations)
Job parameter gsim_logic_tree_file: for calculations where a ground motion logic tree is to be used
Job parameter gmfs_file: for calculations where externally computed ground motion fields are to be imported into the engine in csv or hdf5 format. gmfs_csv used to be the old name of this parameter and is still supported for legacy reasons.

Landslide and liquefaction

For landslide and liquefaction, the engine can compute the hazard footprints using the models specified through the secondary_perils parameter, for the IMTs supported by those models; for instance —

[secondary_perils]
secondary_perils = NowickiJessee2018Landslides, Bozzoni2021LiquefactionEurope, TodorovicSilva2022NonParametric

While it appears that the user is able to specify multiple models for a given subperil - two liquefaction models in the above example, in reality at present, the engine silently overwrites the results from the first liquefaction model with the results from the second liquefaction model. This issue will hopefully be corrected with the solution proposed later in this section.

Volcanic subperils

For the volcanic subperils, the engine does not support hazard calculations, and the hazard footprints need to be imported (in csv format) in order to run risk calculations. This import is done through the multi_peril_file parameter, for instance:

[volcano_hazard]
multi_peril_file = {
  'ASH': "ash_fall.csv",
  'LAVA': "lava_flow.csv",
  'LAHAR': "lahar.csv",
  'PYRO': "pyroclastic_flow.csv"
}

Other earthquake-related subperils

Models for surface rupture might be implemented in the engine in the near future, making this case similar to landslide and liquefaction. On the other hand, tsunami hazard footprints would have to be generated externally and imported into the engine, making this case similar to the volcanic subperils.

Other non-earthquake subperils

Hazard footprints for all non-earthquake subperils will be generated externally and will need to be imported into the engine for risk calculations, similar to the volcanic subperils.

Main considerations

The current workflow for ground shaking should not be changed
For all other subperils, the current implementation involving multi_peril_file and secondary_perils should be ideally replaced by a unified approach that will be able to accept for each subperil involved in the job:
1. the name of a single model which will be used to compute the hazard footprint within the engine (akin to gsim =), or
2. the path to a csv or hdf5 file containing the hazard footprint which should be imported into the engine (akin to gmfs_file = ), or
3. the path to a logic tree xml file containing the model names and weights, if multiple models are to be used for the hazard footprint computation (akin to gsim_logic_tree_file =) (forward looking, and can be pushed to a later issue as it will involve extending logic tree support to all subperils)

Eg., for liquefaction, the user would be able to specify either liquefaction_model, or liquefaction_footprint_file, or liquefaction_model_logic_tree_file.

Fragility models, consequence models, and vulnerability models

Fragility models

Currently, the damage calculators allow the user to provide three fragility model files using the parameters structural_fragility_file, nonstructural_fragility_file, and contents_fragility_file, eg.

oq-engine/openquake/qa_tests_data/scenario_damage/case_7/job_r.ini

Lines 12 to 15 in 7ff9a69

    
           [fragility] 
        
           structural_fragility_file = structural_fragility_model.xml 
        
           nonstructural_fragility_file = nonstructural_fragility_model.xml 
        
           contents_fragility_file = contents_fragility_model.xml

Now, in order to be able to run damage calculations for multiple sub-perils simultaneously, the user should be able to provide at least one and up to three fragility model files for each sub-peril of interest (i.e., the sub-perils declared using the parameter subperil). A dictionary approach is proposed using the syntax
subperil0_fragility_file = {"component0": subperil1_component0_fragility_filepath, "component1": ...}. For instance:

ground_shaking_fragility_file = {"structural": "ground_shaking_structural_fragility.xml", "nonstructural": "ground_shaking_nonstructural_fragility.xml", "contents": "ground_shaking_contents_fragility.xml"}
liquefaction_fragility_file = {"structural": "liquefaction_structural_fragility.xml", "nonstructural": "liquefaction_nonstructural_fragility.xml", "contents": "liquefaction_contents_fragility.xml"}
landslide_fragility_file = {"structural": "landslide_structural_fragility.xml", "nonstructural": "landslide_nonstructural_fragility.xml", "contents": "landslide_contents_fragility.xml"}
tsunami_fragility_file = {"structural": "tsunami_structural_fragility.xml", "nonstructural": "tsunami_nonstructural_fragility.xml", "contents": "tsunami_contents_fragility.xml"}

While fragility functions for nonstructural or contents damage due to landslides and liquefaction are scarce in the literature, for the purposes of uniformity of implementation, it would be cleaner and beneficial to maintain the same structure across all sub perils.

Amongst the four volcanic sub-perils currently supported by the OpenQuake engine, the user is able to provide fragility functions only for ash fall (see Figure 3 below). The other three volcanic sub-perils are assumed to be highly destructive and simply the presence of lahars, lava, or pyroclastic flow at the location of an asset is assumed to cause complete damage or 100% loss. However, it would be beneficial to harmonize the workflow for these three sub-perils and use the same workflow as proposed above for all sub-perils, i.e., permit the user to provide fragility functions conditioned on the IMTs available for these sub-perils (see Figure 4 below).

Figure 3. Current workflow for scenario damage calculations involving volcano and its sub-perils

Figure 4. Proposed workflow for damage calculations involving volcano and its sub-perils

Consequence models

Similar to fragility functions, the user should be able to provide separate consequence models for each sub-peril. Given the more compact format of consequence functions in the csv format, a single csv file can be used to provide the consequence functions for all sub-perils. This will require the addition of a subperil column in the consequence input file.

[Note 1]: The old NRML format for consequence models was deprecated three years ago and should be removed. (Done in #10039).
[Note 2]: Some proposals for making the consequence module more general and flexible are listed in #7162, but in this issue, the changes requested are limited to making the consequence module work with multiple sub-perils.

Vulnerability models

Originally, the risk calculators allowed the user to provide up to five vulnerability model files using the parameters structural_vulnerability_file, nonstructural_vulnerability_file, contents_vulnerability_file, business_interruption_vulnerability_file, and , occupants_vulnerability_file. area_vulnerability_file and number_vulnerability_file were added in #8724, and residents_vulnerability_file was added in #8788. Current syntax to provide the file paths for these vulnerability files is as below:

structural_vulnerability_file = vulnerability_structural.xml
nonstructural_vulnerability_file = vulnerability_nonstructural.xml
contents_vulnerability_file = vulnerability_contents.xml
area_vulnerability_file = vulnerability_area.xml
number_vulnerability_file = vulnerability_number.xml
occupants_vulnerability_file = vulnerability_fatalities.xml
residents_vulnerability_file = vulnerability_residents.xml

Now, in order to be able to run risk calculations for multiple sub-perils simultaneously, the user should be able to provide at least one and up to eight vulnerability model files for each sub-peril of interest (i.e., the sub-perils declared using the parameter subperil). Similar to the fragility functions, a dictionary approach is proposed using the syntax
subperil0_vulnerability_file = {"component0": subperil1_component0_vulnerability_filepath, "component1": ...}. For instance:

ground_shaking_vulnerability_file = {"structural": "ground_shaking_structural_vulnerability.xml", "nonstructural": "ground_shaking_nonstructural_vulnerability.xml", "contents": "ground_shaking_contents_vulnerability.xml", "area": "ground_shaking_area_vulnerability.xml", "number": "ground_shaking_number_vulnerability.xml", "occupants": "ground_shaking_occupants_vulnerability.xml", "residents": "ground_shaking_residents_vulnerability.xml", "business_interruption": "ground_shaking_business_interruption_vulnerability.xml"}
liquefaction_vulnerability_file = {"structural": "liquefaction_structural_vulnerability.xml", "nonstructural": "liquefaction_nonstructural_vulnerability.xml", "contents": "liquefaction_contents_vulnerability.xml", "area": "liquefaction_area_vulnerability.xml", "number": "liquefaction_number_vulnerability.xml", "occupants": "liquefaction_occupants_vulnerability.xml", "residents": "liquefaction_residents_vulnerability.xml", "business_interruption": "liquefaction_business_interruption_vulnerability.xml"}
landslide_vulnerability_file = {"structural": "landslide_structural_vulnerability.xml", "nonstructural": "landslide_nonstructural_vulnerability.xml", "contents": "landslide_contents_vulnerability.xml", "area": "landslide_area_vulnerability.xml", "number": "landslide_number_vulnerability.xml", "occupants": "landslide_occupants_vulnerability.xml", "residents": "landslide_residents_vulnerability.xml", "business_interruption": "landslide_business_interruption_vulnerability.xml"}
tsunami_vulnerability_file = {"structural": "tsunami_structural_vulnerability.xml", "nonstructural": "tsunami_nonstructural_vulnerability.xml", "contents": "tsunami_contents_vulnerability.xml", "area": "tsunami_area_vulnerability.xml", "number": "tsunami_number_vulnerability.xml", "occupants": "tsunami_occupants_vulnerability.xml", "residents": "tsunami_residents_vulnerability.xml", "business_interruption": "tsunami_business_interruption_vulnerability.xml"}
...

Bringing the volcanic sub-perils under the same workflow should enable users to also run scenario and event based risk analyses for volcanoes by providing the appropriate vulnerability functions. (Currently, users can only run damage calculations for the volcanic sub-perils)

Combined damage due to all triggered sub-perils

In addition to estimating damage to buildings or infrastructure elements due to all sub-perils associated with a given event, it would also be useful for downstream applications such as connectivity loss analysis or business interruption analysis to be able to combine the damage contributions from all sub-perils to assign a "combined damage state" for each asset. Bird et al. (2006)¹ looked at combining damage from liquefaction and ground shaking, proposing different approaches depending on whether or not there is assumed to be interaction between the two hazards. De Risi et al. (2018)² propose evaluating the maximum permanent ground deformation (PGD) due to all ground failure phenomena and then then evaluate the overall damage as a weighted combination of the expected contributions from ground failure and ground shaking. HAZUS³ proposes to first evaluate the damage state exceedance probability for ground failure as the maximum of the damage state probabilities for three types of ground failure (liquefaction-induced settlement, liquefaction-induced lateral spread, and landsliding); the damage state exceedance probabilities for ground failure are then combined with the damage state exceedance probabilities for ground shaking, using the equations shown below in Figure 5. Kwong and Jaiswal (2023)⁴ propose a method for estimating the number of repairs required for a buried pipeline network due to a combination of ground failure (surface faulting, liquefaction, and landslide) and ground shaking. Goda and De Risi (2018)⁵ propose evaluating the damage ratio for a building subjected to the combined effects of ground shaking and tsunami as the maximum of the damage ratio due to ground shaking alone and the damage ratio due to tsunami alone.

Figure 5. Hazus approach for combining damage due to ground shaking and ground failure. In these equations, DS is damage state, and S, M, E, and C represent Slight, Moderate, Extensive, and Complete damage, respectively. Source: Hazus 5.1 Earthquake Model Technical Manual.

To be able to obtain the "combined" damage distribution for an asset, we propose to use a formulation akin to that used by Hazus and combine the damage state exceedance probabilities for each sub-peril before sampling the damage state labels for the combined damage state.
P_comb[DS ≥ Complete] = P[⋃_subperil_i(DS ≥ Complete)]
P_comb[DS ≥ Complete] = 1 – P[⋂_subperil_i(DS < Complete)]
P_comb[DS ≥ Complete] = 1 – ∏(1 – P_subperil_i[DS ≥ Complete])
P_comb[DS ≥ Extensive] = 1 – ∏(1 – P_subperil_i[DS ≥ Extensive])
and so on. This formulation is the same as the expanded form in Figure 5, but easier to manage with multiple sub-perils.

[Note 1]: Combining damage state contributions from individual sub-perils implicitly assumes that the damage state definitions for each sub-peril are comparable (and thus combinable) in a meaningful way.
[Note 2]: The formulation proposed here ignores any potential interaction between the sub-perils (eg., early onset liquefaction leading to a 'base isolation' effect and reducing the damage that would otherwise have been caused due to strong ground shaking), and it also does not account for damage accumulation (eg. ground shaking leading to initial damage and reduced capacity of a structure which is then subjected to tsunami loading).
[Note 3]: More sophisticated approaches for combining the downstream consequences due to damage arising from each sub-peril can be managed by permitting user-defined consequence functions or scripts as proposed in #7162.

Combined losses or consequences due to all triggered sub-perils

A similar "combined loss" and "combined loss ratio" for each asset can be provided in the scenario risk and event based risk calculators as a convenience output. For the risk calculators, we propose to follow the approach of Goda and De Risi (2018) and evaluate the combined loss ratio as simply the maximum of the loss ratio due to any of the individual sub-perils, since the composition of non-exceedance probabilities approach adopted for the damage calculators does not work for the risk calculators.

Outputs

For both the damage and risk calculators, we propose to retain the filenames and file formats of the existing outputs. However, an additional column would have to be included in the csv files to account for the additional dimension of the sub-peril type. Note that the damage or loss results for each individual sub-peril will be available to the users, in addition to the convenience output for the "combined" damage or loss, so that interested users can adopt their own preferred approach for combining or summing up the contributions from the individual sub-perils.

References

Bird, J. F., Bommer, J. J., Crowley, H. M., & Pinho, R. (2006). Modelling liquefaction-induced building damage in earthquake loss estimation. Soil Dynamics and Earthquake Engineering, 26(1), 15–30. https://doi.org/10.1016/j.soildyn.2005.10.002 ↩
De Risi, R., De Luca, F., Kwon, O.-S., & Sextos, A. (2018). Scenario-Based Seismic Risk Assessment for Buried Transmission Gas Pipelines at Regional Scale. Journal of Pipeline Systems Engineering and Practice, 9(4), 1–12. https://doi.org/10.1061/(asce)ps.1949-1204.0000330 ↩
Federal Emergency Management Agency. (2022). Hazus 5.1 Earthquake Model Technical Manual. https://www.fema.gov/sites/default/files/documents/fema_hazus-earthquake-model-technical-manual-5-1.pdf. Washington, D.C., United States. ↩
Kwong, N. S., & Jaiswal, K. S. (2023). A Methodology to Combine Shaking and Ground Failure Models for Forecasting Seismic Damage to Buried Pipeline Networks. Bulletin of the Seismological Society of America, 113(6), 2574–2595. https://doi.org/10.1785/0120220132 ↩
Goda, K., & De Risi, R. (2018). Multi-hazard loss estimation for shaking and tsunami using stochastic rupture sources. International Journal of Disaster Risk Reduction, 28(December 2017), 539–554. https://doi.org/10.1016/j.ijdrr.2018.01.002 ↩

The text was updated successfully, but these errors were encountered:

raoanirudh added the proposal label Nov 26, 2024

micheles modified the milestones: Engine 3.22.0, Engine 3.23.0 Nov 27, 2024

micheles mentioned this issue Jan 21, 2025

Calculate consequences from multiple perils (ground shaking and sep) for each asset #9746

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

General support for multi-peril damage and loss calculations #10162

General support for multi-peril damage and loss calculations #10162

raoanirudh commented Nov 26, 2024 •

edited

Loading

General support for multi-peril damage and loss calculations #10162

General support for multi-peril damage and loss calculations #10162

Comments

raoanirudh commented Nov 26, 2024 • edited Loading

Objectives

Background

Proposal

Key Considerations

New job parameters peril and subperil

Intensity measures

Subperil models or footprints

Ground shaking

Landslide and liquefaction

Volcanic subperils

Other earthquake-related subperils

Other non-earthquake subperils

Main considerations

Fragility models, consequence models, and vulnerability models

Fragility models

Consequence models

Vulnerability models

Combined damage due to all triggered sub-perils

Combined losses or consequences due to all triggered sub-perils

Outputs

References

Footnotes

raoanirudh commented Nov 26, 2024 •

edited

Loading

New job parameters `peril` and `subperil`