Skip to content

Fix SA(1.0) and SA(1) labeling mismatch between fragility and GMF files

Problem description:

The ground-motion field (to use as input to the losscalculator) is computed using the OpenQuake program. Thus we want the losscalculator to be compatible with OQ as much as possible.

There can be different ground-motion types used for computations such as: PGA, PGV, PGD, RSD, MMI and SA(0.1)...,SA(1.0)...

Just like the examples above, there can be more than one ground-motion type defined for each location in the ground-motion field file but we can assign value of only one type to each asset (the correct ground-motion type to pick from the ground-motion field file is the one that matches the ground-motion type based on which, the fragility function related to that specific asset is defined)

The header of the ground-motion field file (produced by OQ) for all the ground-motion types has the gmv_ prefix which stands for ground motion value. The number inside parentheses for SAs is a float. For example the header of ground-motion values for SA1 produced by OQ is written as gmv_SA(1.0).

But, the fragility functions (the ones by Martins and Silva), which defined based on SA1, have the header SA(1).

To find the matching ground-motion types between a fragility function and the ground-motion field file for a specific asset, I treated their headers as strings, so that in the specific case when:

fragility_function_ground_motion_type = 'SA(1)'
'gmv_SA(1.0)' != 'gmv_' + fragility_function_ground_motion_type

This problem only happens with SA cases (and only integer SAs) because they are the only ground-motion types that come with a number.

Method used:

This problem does not happen for ground-motion types that contain no number. Thus the only ground-motion type to address is SA (and only SA with full integers in the parentheses). Thus the number inside SA parentheses is extracted from both fragility functions and ground-motion field file as a float and then compared. SAs are not treated as strings.

\approve @ds @fd

Edited by Tara Evaz Zadeh

Merge request reports

Loading