asset_hazard_distance

[Michele Simionato]

AFFECTS: all users running risk calculations

Historically it has always been possible to set a parameter called `maximum_distance` in the job_risk.ini configuration file.

Recently the name of that parameter has been changed to `asset_hazard_distance`, to avoid confusion with a parameter

with the same name in the hazard configuration file. Starting from tomorrow you will get an error if you have an old job_risk.ini

file using the name  `maximum_distance`. The error message will clearly say that you must rename the parameter to `asset_hazard_distance`.

Sorry for the inconvenience, but it was felt that the confusion generated by the old name was just too much.

Here is the meaning of the two parameters:

`maximum_distance` (hazard): if a site is outside this range from the sources, the hazard on that site is considered zero

`asset_hazard_distance` (risk): if an asset is outside this range from the hazard sites, it is discarded in the risk computation and a warning is printed

[Clotaire Michel]

Dear Michele,

is that parameter now mandatory for the risk computation? I was not using it up to now but now that I switched to version 1.4 my computation crashes with the error:

[2015-07-07 11:22:19,943 hazard job #389 - WARNING MainProcess/15339] You are using a hazard calculation ran by openquake

Traceback (most recent call last):

  File "/usr/bin/oq-engine", line 9, in <module>

    load_entry_point('openquake.engine==1.4.1', 'console_scripts', 'oq-engine')()

  File "/usr/lib/python2.7/dist-packages/openquake/engine/bin/openquake_cli.py", line 537, in main

    hazard_calculation_id=args.hazard_calculation_id)

  File "/usr/lib/python2.7/dist-packages/openquake/engine/engine.py", line 363, in run_job

    run_calc(job, log_level, log_file, exports)

  File "/usr/lib/python2.7/dist-packages/openquake/engine/engine.py", line 182, in run_calc

    calculator = calculators(job)

  File "/usr/lib/python2.7/dist-packages/openquake/baselib/general.py", line 465, in __call__

    return self[key](obj, *args, **kw)

  File "/usr/lib/python2.7/dist-packages/openquake/engine/calculators/risk/scenario_risk/core.py", line 126, in __init__

    super(ScenarioRiskCalculator, self).__init__(job)

  File "/usr/lib/python2.7/dist-packages/openquake/engine/calculators/risk/base.py", line 171, in __init__

    dist = self.oqparam.maximum_distance

  File "/usr/lib/python2.7/dist-packages/openquake/commonlib/valid.py", line 738, in __get__

    raise AttributeError

AttributeError

thanks for your answer

[Michele Simionato]

Are you trying to run a risk calculation with OpenQuake 1.4 over a hazard calculation ran in the past with OpenQuake 1.3? This is not supported, you must repeat the hazard calculation.

[Clotaire Michel]

No, I am computing hazard and risk in the same script. It works with v1.3 not with 1.4 anymore.

[Michele Simionato]

On Tuesday, July 7, 2015 at 1:47:46 PM UTC+2, Clotaire Michel wrote:

No, I am computing hazard and risk in the same script. It works with v1.3 not with 1.4 anymore.

The maximum_distance is now mandatory. The asset_hazard_distance is optional and has a default of 5 km. 

[Clotaire Michel]

OK, so there should not be any problem. Let me summarize what I am doing:

- compute gmf using scenario calculator

- exporting the gmf modifying it externally and re-importing it to OQ

- compute risk on the imported gmf

the error occurs when computing the risk (see message above). My feeling is that the problem occurs when I load the gmf to OQ. Maybe the parameter maximum_distance is not set during this operation, which was previously not a problem, but now is.

[Michele Simionato]

I remember this bug, but it was fixed two months ago:  https://github.com/gem/oq-engine/pull/1747

Can it be that you have OpenQuake engine 1.4 and not 1.4.1?

[Michele Simionato]

We checked, and actually this fix, even if it is two months old, was not released even with version 1.4.1.

So I suggest you to upgrade to the nightly builds which are actually quite safe to use.

[Clotaire Michel]

Thanks Michele, the upgrade to the nightly builds allowed to solve the issue.