Define calclulation IMLs from vulnerability file (Classical PSHA only)

[larsbutler]

Abstract

If a job consists of hazard calculations only, the user must define their own set of IML values. However, if a Classical PSHA job consists of hazard and risk calculations, the IMLs which are defined in the generated config.gem file should be determined in a programmatic fashion by reading the vulnerability file.

Proposed solution

1) Modify the JobConfigWriter class (https://github.com/gem/openquake-server/blob/master/utils/oqrunner/config_writer.py#L211) to accept 2 additional parameters: redefine_iml_from_vuln (boolean, default=False), number_of_imls (int, default=?).

2) If redefine_iml_from_vuln is True, read lower_bound and upper_bound values from a vulnerability file. Given all of the IMLs defined in the vulnerability file, the lower_bound and upper_bound values are calculated as follows:

n = the number of hazard IMLs to be calculated Lowerbound LB = IML_1 - ((IML_2 - IML_1) / 2) Upperbound UB = IML_n + ((IML_n - IML_n-1) / 2)

NOTE: IML_1 is the min IML value in an IML set; IML_n is the max IML value in an IML set.

Important:

• A vulnerability configuration can contain multiple discreteVulnerabilitySets; thus, it can contain multiple sets of IML values.
• Lowerbound and Upperbound values must be calculated for each discreteVulnerabilitySet.
• Hazard IMLs must be calculated using the lowest Lowerbound value and the highest Upperbound value; this ensures that the new hazard IML range is valid for the entire vulnerability model.

3) Add a utility function to generate a logarithmic scale (given min, max, and n values, where n is the number of total values in the scale). We can use an algorithm equivalent to the following snippet of Java code (provided by monellid):

public static double[] getLogScale(double lowerBound, double upperBound, int numberOfValues) {   double[] logScale = new double[numberOfValues];   // compute discretization step   double delta = (1.0 / (numberOfValues - 1)) * Math.log10(upperBound / lowerBound);   // compute log scale   for(int i=0; i < numberOfValues; i++) {     logScale[i] = lowerBound * Math.pow(10, i * delta);   }   return logScale; }

Error checking

An exception should be raised if:

• A vulnerability IML set has > 2 IML values
• A vulnerability file contains IML values <= 0.0
• The IMLs in the vulnerability file are not in ascending order (i.e.: 0.1, 0.3, 0.2, 0.4, 0.5)
• The new hazard IMLs derived from the vulnerability file are <= 0.0
• The computed lower_bound is <= 0.0
• The computed upper_bound is <= 0.0
• The upper_bound is <= lower_bound

If a vulnerability IML set has less than 2 IML values, an exception should be raised. If the vulnerability file contains IML values <= 0.0, an exception should be raised. If the new hazard IMLs derived from the vulnerability file are <= 0.0, an exception should be raised. If the IMLs in the vulnerability file are not in ascending order (i.e.: 0.1, 0.3, 0.2, 0.4, 0.5), an exception should be raised.

Test data needed

• Sample vulnerability files
  • Good samples (to test general cases)
  • Bad samples (to test error cases)

    Future iterations

• Add job_mode column to uiapi.oq_job and uiapi.oq_params. The value of this column should be one of: ("hazard", "risk", "hazard_and_risk")
  • The purpose of this attribute to define which types of calculations should be performed in the job
  • The typical case is "hazard_and_risk", but we need to be able to run hazard and risk calculations separately
  • The value of this column could possibly drive the IML definition and we would no longer need the additional JobConfigWriter parameters (see above).

    See also

https://github.com/gem/openquake/issues/55

[larsbutler]

Resolved by this pull request: https://github.com/gem/openquake-server/pull/32