Open micheles opened 4 years ago
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:
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.
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.
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).