Real risk logic trees

[micheles]

This was requested by @danciul and would be useful for @mjourneay and many others too. The goal is to propagate the epistemic uncertainty in the fragility / vulnerability models to the risk. For instance, a user could provide three sets of vulnerability functions with names like VFUpper, VFLower, VFMid for each building class, with weights that sum to unity. This situation is managed partly by the taxonomy mapping feature (#4720), which however, currently only computes weighted mean losses for the asset based on the specified vulnerability functions and does not propagate the epistemic uncertainty forward by generating explicit risk branches in the logic tree expansion.

In this context "real risk logic tree" means to save in the datastore the individual outputs per risk branch. Also, if sampling is enabled, the engine should sample at the same time: source model logic tree branches, GSIM logic tree branches, and risk logic tree branches. This is completely missing at the moment and requires integration between the hazard and the risk part of a calculation (i.e. even before starting the hazard calculation, the engine should have read and processed the taxonomy mapping file).

[CINievas]

Hi Michele! This is, indeed, very useful! In consultation with @danciul and @thpap we agreed that the following could be an additional desired feature. What you are describing seems to refer mostly to uncertainty in the fragility/vulnerability, but we are wondering if it would be possible to make it also cover exposure. What we mean by this is the possibility of having multiple exposure models, in the same way it is possible to have multiple source models in the hazard. The topics we are trying to address are two:

• Propagation of the uncertainty in the exposure model throughout all the risk calculations.
• Definition of exposure uncertainty at the building-by-building level.

The associated (complementary) features that would be very useful to us are:

1. The user defines an exposure model via a CSV file as is currently done, but there is an additional “exposure mapping feature” (equivalent to the vulnerability mapping feature) that allows to define different weights to different building classes associated with a particular building. The need for this arises from doing building-by-building exposure and having uncertainty in the class each building belongs to. Each class may have not only different vulnerability but also different replacement cost and number of occupants. The way we are currently dealing with this is by treating the probabilities associated with each class as fractions of a building (that add up to 1 for each building) in the exposure CSV file, but we understand that in the near future it will only be possible to define integer numbers of buildings in there, which would render our current approach unfeasible. The existing vulnerability mapping feature only allows us to use different vulnerability models for any particular building, but not to define different replacement costs or number of occupants, which is what we would like to have as well. The proposal is then to define 1 building in a main exposure CSV file, assign it a mapping label (e.g. Bdg_A), and then have a separate file in which we specify that Bdg_A is associated with building classes 1 and 2, each with their replacement costs and number of occupants. Additionally, each building class (1 and 2) may be associated with different vulnerability models VFUpper, VFLower, VFMid, as you have described, but this is handled at a separate branching level. A full probabilistic description of all the possible combinations of building classes and individual buildings would become unmanageable quite fast. However, what could be done is that the user defines a number of exposure samples and in each realization of the exposure sampling OQ assigns Bdg_A one of its associated classes (sampled from its distribution), and does the same with each building. Clearly the total number of samples will be much smaller than all possible existing combinations, but in a way this is similar to what OQ currently does with the number of ground motion fields considered for a scenario calculation: clearly not every possible combination of ground motion at site A and site B is sampled. It would be basically like treating the epistemic uncertainty of not knowing exactly what Bdg_A is as aleatory uncertainty instead.
2. At the full exposure model scale, the user is able to define different exposure input models by means of different CSV files (just as it is currently done for one model), and an exposure logic tree assigns weights to these models. This would allow to propagate uncertainty in the exposure model (treated as a whole, no longer thinking at what happens with each individual building) all the way.

The attached figure might help to illustrate the different branching levels that these features imply. The first branching level corresponds to having different exposure models defined by different input CSV files (as described in point 2 above). The second branching level corresponds to the uncertainty in the building class of any individual building (as described in point 1 above): each building has its own mini-logic tree, each class has its own replacement cost and number of people. The third branching level would finally correspond to the vulnerability models associated with each building class.

[thpap]

Hi Michele and OQ team. It appears that for the Swiss Seismic Risk model we would also be interested in propagating the uncertainty in the site condition model throughout the risk calculations. More precisely, we will have alternative soil amplification maps representing epistemic uncertainty, hence they should be treated in a consistent manner. A logic tree structure on the site_model file, for instance, would enable propagation of this uncertainty to risk metrics by defining alternative site csv/xml files with e.g. different ‘siteclass’ parameters for each site.