Save intermediate hazard curves to DB in UHS calculations

Bug #932941 reported by Lars Butler
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenQuake (deprecated)
Won't Fix
Medium
Lars Butler

Bug Description

[et=8h]
[at=]

Requested by Laurentiu Danciu:

In the Disagg and UHS calculators, we're generating hazard curves as intermediate artifacts. It would be useful for the users to save those intermediate results and output them from the calculation.

----------

To implement this, the following needs to be done.

Java side:
- Refactor the way the UHS Calculator (on the java side) constructs and returns results (see: https://github.com/gem/openquake/blob/ce4dbc1f83bca744df6bd66a2ecd946f807414ba/java/org/gem/calc/UHSCalculator.java#L121, https://github.com/gem/openquake/blob/ce4dbc1f83bca744df6bd66a2ecd946f807414ba/java/org/gem/calc/UHSResult.java). The result object needs to store the uhs (array) and poe pairs, as well as all of the hazard curves for the site.

Python side:
- Grab the hazard curves from the java result object and save them to the db. This new functionality should probably added to this method: https://github.com/gem/openquake/blob/ce4dbc1f83bca744df6bd66a2ecd946f807414ba/openquake/calculators/hazard/uhs/core.py#L163
- Add QA test coverage

DB:
- Include an optional sa_period attribute for each hazard curve node.
- Add `imt` and `imls` fields to the hzrdr.hazard_curve table. This information is available in the uiapi.oq_job_profile, but we have to do several joins to get this information. It would be more efficient (especially for export hazard curves from the DB) if we denormalized a bit and just stored a copy of this data in the hzrdr.hazard_curve table.

NRML:
- Include an optional sa_period attribute for each hazard curve node.

description: updated
summary: - Save intermediate hazard curves to DB in Disagg and UHS calculators
+ Save intermediate hazard curves to DB in UHS calculations
tags: added: hazard uhs
Changed in openquake:
importance: Undecided → Medium
Changed in openquake:
assignee: nobody → Lars Butler (lars-butler)
milestone: none → 0.6.0
Changed in openquake:
status: New → In Progress
Changed in openquake:
status: In Progress → Confirmed
Revision history for this message
Damiano Monelli (monelli) wrote :

This is also useful because with a single UHS calculation, we can compute hazard curves at different periods with a single OpenQuake run (and so deriving hazard maps for different periods too), while with the classical PSHA calculator (as it stands now) we can compute hazard curves for only one period at the time.

description: updated
description: updated
Revision history for this message
Lars Butler (lars-butler) wrote :

@Damiano:

For each site of interest, we compute 1 hazard curve per SA period. When we store the hazard curves in the database/NRML, do we need the associated period as well? I would think that the answer is 'yes'; otherwise, there really isn't enough information to interpret the results.

Changed in openquake:
status: Confirmed → In Progress
Revision history for this message
Damiano Monelli (monelli) wrote :

@lars-butler:
Yes I think it's a good idea. For each curve we should also give the corresponding period.

John Tarter (toh2)
Changed in openquake:
milestone: 0.6.0 → 0.6.1
Changed in openquake:
status: In Progress → Confirmed
description: updated
tags: added: database nrml
description: updated
Changed in openquake:
status: Confirmed → In Progress
Changed in openquake:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.