Calculation of loss maps using the deterministic event based method about oq-engine

[acerisara]

To compute the mean loss map we need the mean loss for each asset. To compute the mean loss, given a ground motion fields set (related to the location where the asset is defined) and the asset (that has a location and a vulnerability function), we have to:

• compute the loss ratios using the probabilistic event based approach
• compute the losses, by multiplying each loss ratio for the asset value
• compute the mean with numpy.mean()

The story https://www.pivotaltracker.com/story/show/5163233 just takes into account these steps. The integration with the inputs provided by the hazard subsystem will be done in this story https://www.pivotaltracker.com/story/show/10958017

To compute the stddev loss maps we need to use numpy.std in the last step instead of numpy.mean(). The integration with the inputs provided by the hazard subsystem will be done in this story https://www.pivotaltracker.com/story/show/10958017

The proposed change is to add an openquake.risk.deterministic_event_based module with two public functions:

• compute_mean_loss(vuln_function, ground_motion_field_set, epsilon_provider, asset)
• compute_stddev_loss(vuln_function, ground_motion_field_set, epsilon_provider, asset)

Update:

Since an asset is defined on a site (as well as the ground motion field set), and it has a vulnerability function associated, we could think of have something like:

• compute_mean_loss(asset, epsilon_provider)
• compute_stddev_loss(asset, epsilon_provider)

And then inside the functions:

vuln_function = asset.vuln_function
ground_motion_field_set = asset.site.ground_motion_fields

But this implies creating an object model that we don't have right now (we use just plain dictionaries). Comments on this?

[acerisara]

Computing the mean/stddev loss per ground motion field is more difficult. Per ground motion field means that we collect the same ground motion field for all the sites defined in the region. Right now we have the opposite, we have sets of ground motion field per site. So, we could think of:

• Keep the slicing this way, collect the sets for all the sites and do the computation (using probably a numpy matrix). This requires lots of memory if we use big regions, but it is quite easy to implement.
• Add the slicing per ground motion field, and use the same logic we use to compute the mean/stddev loss per site with the slicing we have right now.

Since I don't know yet how much it costs (and if it's possible) to slice per ground motion field, I'm going to implement the hazard side and then come back to this story.