Expanding the risk calculators to another two loss types

[VSilva]

The current risk metrics supported by OpenQuake are insufficient for several use cases. It is fundamental to expand the current list of loss types to the following two parameters:

**1. - Damaged buildings

2. • Area lost**

For the first metric, we simply use a vulnerability function per building class, and the number of buildings. Note that this parameter is already in the exposure models and it is already digested by OpenQuake (e.g., <field oq="number" input="BUILDINGS" />). I propose the following parameter for the job.ini file.

damage_vulnerability_file = example_vulnerability.xml

For the second parameter, we need to add another parameter in the <exposureFields> in the following manner:

  <exposureFields>
    <field oq="id" input="ASSET_ID" />
    <field oq="lon" input="LONGITUDE" />
    <field oq="lat" input="LATITUDE" />
    <field oq="taxonomy" input="TAXONOMY" />
    <field oq="number" input="BUILDINGS" />
    <field oq="area" input="TOTAL_AREA_SQM" />
    <field oq="structural" input="TOTAL_REPL_COST_USD" />
    <field oq="night" input="OCCUPANTS_PER_ASSET_DAY" />
  </exposureFields>

Note the new field "area". OpenQuake should take this value, and use a dedicated vulnerability functions to compute the area lost. I propose the following parameter:

area_vulnerability_file = example_vulnerability.xml

For both these parameters we should have the typical risk outputs (e.g., average annual losses and loss curves)

[micheles]

Looks clear enough, but let me notice that we already have an "area" parameter in the exposure, already digested, just like the "number" parameter.

[VSilva]

ok nice Michele, thank you. I know that one of the methods to estimate the cost was through the area, but since we never use that, I was afraid that it had been deprecated.

[micheles]

No, but I am willing to remove that cost type if it is not used, while at the same time keeping the 'area' column in the exposure.

[CatalinaYepes]

Thinking of a wider spectrum of applications, we could explore the possibility of adjusting the way the vulnerability is handled inside the engine to move from specific vulnerability files to a dictionary-based vulnerability, in which the user will indicate the vulnerability file plus the exposure field to apply the loss ratios.

We could define an exposureField="TOTAL_AREA_SQM" inside the vulnerability xml to indicate the field to be used from the exposure. Then the job.ini could be

vulnerability_files = {
  "structural": structural_vulnerability_model.xml,
  "nonstructural": nonstructural_vulnerability_model.xml,
  "loss_area": area_vulnerability_model.xml,
  "homeless": homeless_vulnerability_model.xml,
}

[nicolepaul]

I agree with Cata that it would be good to generalize how we specify the vulnerability XML files. The point she mentions about the exposure field is important -- for example, although 'fatalities' and 'homeless' loss types both may involve occupants, they use different exposure fields (i.e., the day/night/transit or time-averaged occupants for the fatalities calculation and the total population for the homeless calculation). If we cannot specify the relevant exposure field for each vulnerability XML, then we must run two calculations to get both metrics.

[micheles]

@CatalinaYepes says

I think for the metric Vitor is asking for, you will have also the same 2 cases as for cost: area = area, if area type="aggregated" area = area*number, if area type="per_asset"

Is that true or there is a single case to consider?

[micheles]

I have implemented an initial version of the feature. Notice that I am using the name number_vulnerability_file and not damage_vulnerability_file since it is easier, otherwise I will need to implement an alias mechanism. The files are here: https://github.com/gem/oq-engine/tree/master/openquake/qa_tests_data/event_based_risk/case_8

I am getting slightly different results that the ones you sent me, for aggrisk.csv I get

loss_type   loss_value  loss_ratio
structural  2.79090E+03 3.05786E-05
area    6.87559E+01 1.00944E-03
number  4.73263E+01 5.73652E-04

instead of

loss_type,loss_value,loss_ratio
structural,2.79E+03,3.06E-05
area,6.82E+01,1.00E-03
damage,4.67E+01,5.67E-04

Perhaps you made some approximations?

[VSilva]

I was imposing a minimum loss value. Without that, I get exactly:

loss_type loss_value loss_ratio structural 2.79090E+03 3.05786E-05 area 6.88E+01 1.00E-03 number 4.73E+01 5.74E-04

So the same as you!