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.
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):
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).
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:
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:
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
Future iterations
See also
https://github.com/gem/openquake/issues/55