Closed VSilva closed 1 year ago
Looks clear enough, but let me notice that we already have an "area" parameter in the exposure, already digested, just like the "number" parameter.
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.
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.
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,
}
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.
@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?
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?
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!
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
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 thejob.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: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)