Canada 6th generation hazard model

[bahar r]

Dear all,

I have a question regarding the use of Canada SHM6 for probabilistic and deterministic hazard calculation in Openquake. Specifically, I am wondering if it is possible to use SHM6 in Openquake without writing a Python code, or if a Python code is necessary to implement Canada SHM6 in Openquake.

If anyone has experience with this or has any information that could be helpful, I would greatly appreciate your input. Thank you in advance for your help.

Best regards,

Bahareh

[bahar r]

I should mention that I want to use SHM6 for South East Canada

[Peter Pažák]

Hi,

it is possible to run SHM6 in OpenQuake, GMPEs are available in v3.11, there I was able to run.

It seems like in the current master (3.17 but not 3.16?) they are present too, I will test it later.

What error are you getting?

Peter 

Dátum: utorok 25. apríla 2023, čas: 4:35:49 UTC+2, odosielateľ: bahar r

[Peter Pažák]

I am able to run OQ files from NRCan OF8924 using the current OQ master (says v3.17).

I just needed to update ini file to include also these lines:

# z1.0 and z2.5 only used for western model
reference_depth_to_2pt5km_per_sec = 2  
reference_depth_to_1pt0km_per_sec = 300  

despite the fact they are not used in east Canada, probably the OQ check got more strict as it did not complain in v3.11.

Peter

Dátum: utorok 25. apríla 2023, čas: 6:26:18 UTC+2, odosielateľ: Peter Pažák

[bahar r]

Thank you, Peter, for your comprehensive response. I appreciate your assistance in this matter.

 

 I would like to inform you I have used OQ 3.16.1 and NRCan OF8924 for my calculations. I have attached the input file to this email for your review. 

 I encountered the following errors: 

Traceback (most recent call last):
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\server\views.py", line 546, in calc_run
    job_id = submit_job(request.FILES, ini, user, hazard_job_id)
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\server\views.py", line 619, in submit_job
    job.oqparam = oq = readinput.get_oqparam(
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\commonlib\readinput.py", line 319, in get_oqparam
    job_ini = get_params(os.path.join(basedir, job_ini), kw)
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\commonlib\readinput.py", line 290, in get_params
    _update(params, items, base_path)
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\commonlib\readinput.py", line 213, in _update
    input_type, fnames = normalize(key, [value], base_path)
  File "C:\Program Files\OpenQuake Engine\python3\lib\site-packages\openquake\commonlib\readinput.py", line 196, in normalize
    raise OSError('No such file: %s' % val)
OSError: No such file: C:\Users\bahareh\AppData\Local\Temp\tmpq1axnazl\calc_165\GMMs\CanadaSHM6-GMM-LT.xml
No such file: C:\Users\bahareh\AppData\Local\Temp\tmpq1axnazl\calc_165\GMMs\CanadaSHM6-GMM-LT.xml

Best,

Bahareh

--
You received this message because you are subscribed to a topic in the Google Groups "OpenQuake Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openquake-users/Ijy5t4dfeas/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openquake-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/a9aeddcf-099f-48b2-8752-dccf14831886n%40googlegroups.com.

[Peter Pažák]

You need to modify the ini file line:

gsim_logic_tree_file = ../GMMs/CanadaSHM6-GMM-LT.xml

to

gsim_logic_tree_file = CanadaSHM6-GMM-LT.xml

when running a zip, as now GMM-LT it is in the same directory (not on the NRCan path...).

It is just a scenario calculation, so you do not need to specify the whole GMM logic tree, maybe just leave those Stable Shallow Crust branch GMPEs - others are not used in east...

What remains as a problem is I believe the Canada SHM6 (2020) GMMs are not present in OQ v3.16 so it will probably fail, I recommend upgrading to OQ 3.17 - current master.

Peter

Dátum: utorok 25. apríla 2023, čas: 18:29:55 UTC+2, odosielateľ: bahar r

[Jamal Assaf]

Hello,

I was able to run the CanadaSHM6 model using 3.16.2 version by manually adding the "...\hazardlib\can20" files into the openquake local files as Peter rightly pointed out. I used the  .ini files, the source and gmm logic trees provided by Open File 8924, https://doi.org/10.4095/331387 to check the results provided in the same file. I attach the .ini file i used for checking the results below.

I noted that z1pt0 is currently a required input for CanadaSHM6_Interface_AtkinsonMacias2009, however CanadaSHM6 does not use z1pt0 as indicated in Open File 8924. So i had to assign z1pt0 in the .ini file to avoid the error, assuming this does not affect the results. 

The 2 % in 50 yr UHS at 10 spectral periods i obtained for a Vancouver site (Vs30= 450 m/s) site are up to 8 % different than the official NBCC values provided in Open File 8924 and the online tool (https://earthquakescanada.nrcan.gc.ca/hazard-alea/interpolat/nbc2020-cnb2020-en.php). Comparison provided in the table below.

 I'm wondering if anyone had compared OQ 3.16 results to the official NBC2020 results or had a similar results.  

Thank you.

Jamal Assaf

### .ini file Western Canada Example (modified from Open FIle 8924) below

description = OF 8924 CanadaSHM6 NBCC 2020 Model Example (Western Canada, Vs30 = 450m/s)
calculation_mode = classical
random_seed = 23
optimize_same_id_sources = True

[geometry]

sites = -123.12    49.25

[logic_tree]

number_of_logic_tree_samples = 0

[erf]

rupture_mesh_spacing = 5.0
width_of_mfd_bin = 0.1
area_source_discretization = 10.0

[site_params]
reference_vs30_type = measured
reference_vs30_value = 450.0
reference_depth_to_1pt0km_per_sec=1.0 ## added to avoid error
[calculation]

source_model_logic_tree_file = ssms/simplifiedCollapsed/logicTree/CanadaSHM6_NBCC2020_WesternCanada-LT.xml
gsim_logic_tree_file = gmms/logicTree/CanadaSHM6-GMM-LT.xml

intensity_measure_types_and_levels = {"PGV":  logscale(0.01,1000.0, 40),
                                      "PGA":  logscale(0.001,6.0, 40),
                                      "SA(0.05)":  logscale(0.001,6.0, 40),
                                      "SA(0.1)":  logscale(0.001,6.0, 40),
                                      "SA(0.2)":  logscale(0.001,6.0, 40),
                                      "SA(0.3)":  logscale(0.001,6.0, 40),
                                      "SA(0.5)":  logscale(0.001,6.0, 40),
                                      "SA(1.0)":  logscale(0.001,4.0, 40),
                                      "SA(2.0)":  logscale(0.001,4.0, 40),
                                      "SA(5.0)":  logscale(0.0001,4.0, 40),
                                      "SA(10.0)":  logscale(0.0001,4.0, 40)}

truncation_level = 5
investigation_time = 50.0
maximum_distance = {"Active Shallow Crust": 400.0, "Stable Shallow Crust": 600.0, "Subduction IntraSlab30": 400.0, "Subduction IntraSlab55": 400.0, "Subduction Interface": 1000.0}

[output]

export_dir = /tmp
poes = 0.02
uniform_hazard_spectra = true

[Peter Pažák]

I believe you should not put depth to 1km/s to 1m. In the older files NRCan had for vs30 = 450 m/s these values (so actually 300m) can you please try this:

# z1.0 and z2.5 only used for western model
reference_depth_to_2pt5km_per_sec = 2  
reference_depth_to_1pt0km_per_sec = 300  

I did a run with v3.11 and v3.17 and my difference was below 1% despite NRCan have their values rounded

Peter

Dátum: pondelok 1. mája 2023, čas: 20:49:46 UTC+2, odosielateľ: Jamal Assaf

[Peter Pažák]

Hi, I found out you are right that the z1pt0 value is discarded in the GMPE implementation,

probably the requirement of specifying it will be dropped from CanadaSHM6_Interface_AtkinsonMacias2009.

That means I am not sure why you are getting such discrepancies in the output.

Peter

Dátum: utorok 2. mája 2023, čas: 13:16:05 UTC+2, odosielateľ: Peter Pažák

[Jamal Assaf]

Hi Peter,

Thank you for your response. 

I installed v3.17 and re-run the hazard for the same site and got the same results i got with v3.16.2 above (i.e., discrepancy is still there). I did a run with v.3.11 and the values are matching with NBCC2020 with less than 2-3 %.

Were your runs in v3.17 and v3.11 for the same site (Vs30) i provided the input info for above? 

I'm wondering if there is any testing case for the CanadaSHM6 products in v3.17 (e.g., UHS) that users can check? I tried to reproduce classical case_76 for CanadaSHM6, but my resulting hazard curves results were named differently than the expected outputs in the file. Maybe we can use this site above as another testing case for CanadaSHM6 since it is part of the official NBCC2020 Open File 8924 OpenQuake model inputs.

Thank you.

Jamal Assaf

[Peter Pažák]

Hi,

I would like to ask Michele or someone from GEM to comment on this.

OQ v3.17 is still under development, so better stay with v3.11 for now.

I used your input where for simplicity I left only SA(0.2) and SA(0.3) and got very good match with v3.11.

However, when using exactly your input, I got the numbers you are showing with discrepancies up to 8% from v3.11.

It is a bit strange that just changing the required outputs changes the results.

I was thinking about effect of random sampling, however changing random_seed from 23 to e.g. 24 did not have any effect on results in v3.11.

By running two IMTs at one time I got below 1% error for SA(0.2)-SA(5.0), 2% error for SA(0.05) and SA(0.1) PGA and SA(10.0) did not change.

So there is definitely something happening with the code...

Peter

Dátum: streda 3. mája 2023, čas: 2:56:20 UTC+2, odosielateľ: Jamal Assaf

[Michele Simionato]

I need a job.zip file to investigate the issue.

               Michele

[Jamal Assaf]

Thanks Peter for investigating this further. 

- Michele, please find the "WesternCanada-Example.zip" file attached. The .ini file, the source model and gmm logic tree files are taken from Open File 8924, https://doi.org/10.4095/331387 for Vancouver (City Hall) site. I also included the expected UHS output for that site in an excel file from the mentioned Open File. Those are the official NBC2020 values obtained using v.3.3.2.

Thank you.

Jamal 

You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/455a8975-0a49-405f-9dfa-faffc8cafcb5n%40googlegroups.com.

[Michele Simionato]

The GMPEs for the 6th generation model have not been included in engine 3.16 because we were still in the process of checking them. Given that they are rather complex and tricky, some bugs could slip in and indeed there was a bug in current master, which has been fixed here: https://github.com/gem/oq-engine/pull/8716

There could be other issues, so please check if now the results you get are consistent or not.

Thanks for your help,

                                         

      Michele Simionato

[Peter Pažák]

Hi Michele,

thank you very much for pointing out the bug.

I have replaced my can_shm6_inslab.py file with the corrected version but there was no impact on the above mentioned results.

Nevertheless I believe we will identify the problem in near future.

Maybe if possible, we could remove z1pt0 from  CanadaSHM6_Interface_AtkinsonMacias2009   REQUIRES_SITES_PARAMETERS , we believe it is not necessary there...

Thank you again

Peter

Dátum: utorok 9. mája 2023, čas: 9:16:24 UTC+2, odosielateľ: michele....@globalquakemodel.org

[Michele Simionato]

On Wed, May 10, 2023 at 3:59 PM Peter Pažák <peter...@gmail.com> wrote:

Hi Michele,

thank you very much for pointing out the bug.

I have replaced my can_shm6_inslab.py file with the corrected version but there was no impact on the above mentioned results.

Nevertheless I believe we will identify the problem in near future.

Maybe if possible, we could remove z1pt0 from  CanadaSHM6_Interface_AtkinsonMacias2009   REQUIRES_SITES_PARAMETERS , we believe it is not necessary there...

Actually you are mistaken, z1pt0 is required, if I remove it I get an error in

  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_interface.py", line 286, in compute
    mean[m] += _site_term_am09(ctx, imt)
  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_interface.py", line 249, in _site_term_am09
    F = CanadaSHM6_ASC._get_site_scaling_ba14(

  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_active_crust.py", line 89, in _get_site_scaling_ba14
    fbd = BA14._get_basin_depth_term(region, C, sites, period)  # returns 0
  File "/home/michele/oq-engine/openquake/hazardlib/gsim/boore_2014.py", line 53, in _get_basin_depth_term
    dz1 = (ctx.z1pt0 / 1000.0) - model

which is using the z1pt0 site parameter. Also, the fix definitely has an effect: if I run the WesternCanada example provided

by  Jamal with current master or with the code before the fix (commit 5de46d7656b14bb60dc8827be2dc55e94e6b6ece) I

get very different results:

$ oq compare hmaps PGA -1 -2
| site_id | calc_id | 0.02    |
|---------+---------+---------|
| 0       | 38_666  | 0.48456 |  # old
| 0       | 38_665  | 0.45132 |  # new

Copying the files is error prone, please do your checks from a development installation using the right commit.

        Michele

[Jamal Assaf]

Thank you very much Michele and the team for finding and fixing the bug. I have updated "can_shm6_inslab.py" from the github folder and re-ran the analysis. I got the exact PGA Michele reported (table below with results rounded to 3 significant figures to be consistent with NBC2020 official values). The OQ 3.16.2 results are now closer to the official NBC2020 results with differences up to 3.4 % at 10 seconds. I don't have v3.11 version installed to re-run a check, but would appreciate if Peter can maybe run that to compare v3.11 results with the new results. Just to make sure of the differences between the 2 implementations.

Regarding, z1pt0, basin terms in NBC2020 are turned off. CanadaSHM6_Interface_AtkinsonMacias2009 does not have a native site term, it simply uses the site term of CanadaSHM6_ActiveCrust_BooreEtAl2014 (below). So since the latter does not require z1pt0, i believe CanadaSHM6_Interface_AtkinsonMacias2009 also should not require z1pt0. I'm not sure why only one of them is raising the error since both have the same site term (with basin term fbd=0).

Thank you.

Jamal

*** script from "Can_shm6_interface.py"
class CanadaSHM6_Interface_AtkinsonMacias2009(AtkinsonMacias2009):
    """
    Atkinson and Macias, 2009 Interface GMM with an added site term following
    a modified version of BSSA14 (SS14) as implemented for CanadaSHM6.

    See also header in CanadaSHM6_Interface.py
    """

***

The  does not have an amplification factor, GSC assigned BSSA14 site amplification model. Since BSSA14 does not require Z1pt5 

[Michele Simionato]

On Friday, May 12, 2023 at 8:44:03 AM UTC+2 Jamal Assaf wrote:

Regarding, z1pt0, basin terms in NBC2020 are turned off. CanadaSHM6_Interface_AtkinsonMacias2009 does not have a native site term, it simply uses the site term of CanadaSHM6_ActiveCrust_BooreEtAl2014 (below). So since the latter does not require z1pt0, i believe CanadaSHM6_Interface_AtkinsonMacias2009 also should not require z1pt0. I'm not sure why only one of them is raising the error since both have the same site term (with basin term fbd=0).

I am not the author of the GMM, so perhaps it is implemented incorrectly, you tell me, but with the current implementation the  z1pt0 dependence comes via the _site_term09:

https://github.com/gem/oq-engine/blob/master/openquake/hazardlib/gsim/can20/can_shm6_interface.py#L286

Please read again the traceback I posted yesterday:

  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_interface.py", line 286, in compute
    mean[m] += _site_term_am09(ctx, imt)
  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_interface.py", line 249, in _site_term_am09
    F = CanadaSHM6_ASC._get_site_scaling_ba14(

  File "/home/michele/oq-engine/openquake/hazardlib/gsim/can20/can_shm6_active_crust.py", line 89, in _get_site_scaling_ba14
    fbd = BA14._get_basin_depth_term(region, C, sites, period)  # returns 0
  File "/home/michele/oq-engine/openquake/hazardlib/gsim/boore_2014.py", line 53, in _get_basin_depth_term

    dz1 = (ctx.z1pt0 / 1000.0) - model 

 Michele

[Peter Pažák]

Hi Michele, Jamal,

only now I had time to return to this topic.

In the v3.11 implementation the basin term is always set to 0. I have tested now to do the same for v3.17:

can_shm6_active_crust.py: comment out the line 89 (below the fbd value is indeed set to 0)

then we can safely do

can_shm6_interface.py line 263: REQUIRES_SITES_PARAMETERS = set(('vs30',))

With this I am getting exactly the numbers of Jamal (labelled as 3.16.2), with 3.11 they were slightly different, but difference below 2%.

I am not the author of the GMPEs, not sure who is implementing, but I can consult also with Michal Kolaj.

Thank you

Peter

Dátum: piatok 12. mája 2023, čas: 9:11:22 UTC+2, odosielateľ: michele....@globalquakemodel.org

[bahar r]

Hello Peter,

The Canadian Geological Survey has released an update aimed at reducing the running time of OQ. As part of this update, they have made some simplifications.

I guess these changes may cause these slight changes you mentioned. 


Best regards,
Bahar

--

You received this message because you are subscribed to a topic in the Google Groups "OpenQuake Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openquake-users/Ijy5t4dfeas/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openquake-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/ac8549c2-dfbd-4118-ac17-b003f6e1ffbdn%40googlegroups.com.

[jamal assaf]

Hello,

Thanks all for the continuous efforts on this topic.

I had a chance to check the differences between the CanadaSHM6 crustal GMMs in OQ.3.11.5 (https://github.com/gem/oq-engine/blob/engine-3.11/openquake/hazardlib/gsim/CanadaSHM6_ActiveCrust.py) and OQ3.16.2 (https://github.com/gem/oq-engine/tree/master/openquake/hazardlib/gsim/can20/can_shm6_active_crust.py) implementations.

I did a quick check for all four crustal GMMs assuming a single scenario (parameters below). I found the mean response of GMMs matching from both implementations (3.11.5 and 3.16) for all crustal GMMs except CanadaSHM6_ActiveCrust_ChiouYoungs2014 (which is the most complex code presumably). The difference occurs for low Vs30 values only (results table attached for two Vs30 and 2 spectral periods).

This probably means the difference is coming from the implementation of the site amplification term in this GMM (CanadaSHM6_ActiveCrust_ChiouYoungs2014). Would someone be able to verify this?

Thank you again.

Jamal

mag
6.5
rake
90
dip
60
ztor
10
rrup (km)
20
rjb
15
rx
15
vs30measured=True

[Michele Simionato]

Did you also check with the latest 3.16, i.e. 3.16.6? There were additional bug fixes compared to the 3.16.2.

   Michele

[jamal assaf]

Yes, im using the latest version of Can20 files added manually to local gsim folder in my installed oq v3.16.2.

--

You received this message because you are subscribed to a topic in the Google Groups "OpenQuake Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openquake-users/Ijy5t4dfeas/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openquake-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/2785e14e-b09c-4223-8d1c-1864b4e87eadn%40googlegroups.com.

[Michele Simionato]

On Thursday, September 7, 2023 at 5:26:44 PM UTC+2 jimmya...@gmail.com wrote:

Yes, im using the latest version of Can20 files added manually to local gsim folder in my installed oq v3.16.2.

There were bugs fixed not in the Can20 files but in other parts of hazardlib still affecting the results for Canada, this is why I said that it is worth checking with v3.16.6.

         Michele

[jamal assaf]

Thanks Michele for pointing that out, I did the check again with v3.17.2 and got the same results from v3.16.2 meaning that the discrepancy is still there. 

Jamal

[jamal assaf]

Hello again Michele,

Checking openquake/hazardlib/gsim/can20/can_shm6_active_crust.py (https://github.com/gem/oq-engine/blob/master/openquake/hazardlib/gsim/can20/can_shm6_active_crust.py) file in v3.17, i can see the nonlinear site amplification (f_nl) in CY14 GMM is turned off (f_nl=0) for some reason (shown in red in the snippet below). This leads CY14 GMM to only have linear amplification, unlike its intended implementation in v3.11. When I remove this line, this GMM provides similar values to that implemented in v3.11.

def get_mean_stddevs_cy14(name, C, ctx):
    """
    Return mean and standard deviation values
    """
    # Get ground motion on reference rock
    ln_y_ref = CY14.get_ln_y_ref(name, C, ctx)
    y_ref = np.exp(ln_y_ref)

    # Set basin depth to 0
    f_z1pt0 = 0.0

    # Get linear amplification term
    f_lin = CY14.get_linear_site_term(name, C, ctx)

    # Get nonlinear amplification term
    f_nl, f_nl_scaling = CY14.get_nonlinear_site_term(C, ctx, y_ref)
    f_nl = 0.0

    # Add on the site amplification
    mean = ln_y_ref + (f_lin + f_nl + f_z1pt0)

    # Get standard deviations
    sig, tau, phi = CY14.get_stddevs(
        name, C, ctx, ctx.mag, y_ref, f_nl_scaling)

    return mean, sig, tau, phi

[Michele Simionato]

This is fixed in engine-3.18 that will be released very soon. Thank you for pointing this out,

           Michele SImionato

[Prajakta Jadhav]

Hi OQ team,

For SHM6 model, I performed OQ analyses (for Vancouver with Vs = 140-200 m/s range) using version 3.18.0-1; and compared with the values provided by the NRCan hazard calculator. The deviation in the values is upto 15%. This deviation is typically more for lower periods (including PGA). 

Further, the values from analyses match quite well for Vs=450 m/s with that of NRCan calculator. 

Would appreciate any help in this regard. 

Thanks,

Prajakta

On Mon, Apr 24, 2023 at 7:13 PM bahar r <bahar...@gmail.com> wrote:

Dear all,

I have a question regarding the use of Canada SHM6 for probabilistic and deterministic hazard calculation in Openquake. Specifically, I am wondering if it is possible to use SHM6 in Openquake without writing a Python code, or if a Python code is necessary to implement Canada SHM6 in Openquake.

If anyone has experience with this or has any information that could be helpful, I would greatly appreciate your input. Thank you in advance for your help.

Best regards,

Bahareh

--

You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/5ffba0fc-5ee1-4380-a174-8199b401e2c8n%40googlegroups.com.

[Marco Pagani]

Thanks. Without seeing the input files used it’s impossible for us to provide any sensible feedback.

Regards

Marco

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/CAO0mx-ZNoj0RDckaBno3TNgnRopS-PXuW-xBH5%2B2PX_AFziOHA%40mail.gmail.com.

[Prajakta Jadhav]

Hi Marco,

Sure.  PFA the zip folder of input files. 

Note: The input files were downloaded from the open file  8924 from NRCan weblink (https://earthquakescanada.nrcan.gc.ca/hazard-alea/interpolat/index-en.php) and analyses was performed altering the values for Vs from 450 m/s to 200 m/s. 

Thanks,

Prajakta

[Prajakta Jadhav]

Hi Marco and team,

Just checking if you got a chance to run these files. 

Thanks,

Prajakta

[Victor Tran]

Hi Prajakta,

I think the answer you need was already provided in previous discussions in this thread.

Regards,

Victor

[Prajakta Jadhav]

Hi Victor,

Thanks for your response. Although, in the previous thread similar problem is mentioned to be addressed, I am still getting ~15% deviation at low Vs (~200 m/s) values when I am comparing the results with Earthquakes Canada calculator. I wonder if there is some other bug which is leading to this discrepancy. 

Can you or anyone please run the analyses and verify it?

Thanks, 

Prajakta

[Victor Tran]

Have you tried adding reference_depth_to_2pt5km_per_sec and reference_depth_to_1pt0km_per_sec?

[Prajakta Jadhav]

Yes I did. 

These were the values I used, based on the messages in thread.

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/7470a82d-b034-4b21-8e07-1101d32651e8n%40googlegroups.com.

[Victor Tran]

Looks like I have PGA of 0.48g and the NRC website gives 0.516 g. Note the amplification function is really sensitive for small Vs values, so I think a small variation between Openquake and NRC's engine can cause those difference?

[Prajakta Jadhav]

Thanks for confirming the variation Victor. 

I am not able to comment on it. Could there be some error or variation in the implementation of amplification function in OQ engine? As I recall from messages in previous threads, 3.11 version was able to produce results closer to NRCan for lower Vs values. So, I wonder if something induced a bug when the OQ versions were upgraded, other than the one already addressed. Can you try once with 3.11 version? I am also trying to run a simulation in 3.11, but struggling with some 'Operational error'. 

Regards,

Prajakta 

[Prajakta Jadhav]

  Hi Peter and OQ team. 

The tabular GMPEs are corresponding to SHM5 based NBCC 2015 model. I am not sure if the SHM6 based 2020 model was also implemented as tables in previous versions. However, in the present NBCC 2020 model, as you mentioned, the GMPEs are implemented as formulae. I am at the moment interested in the recent NBCC 2020 model, and I am a bit concerned about the deviation in values for low Vs, as I need to run OQ analyses for lower Vs values for the project, and so I have following qns:

1) Although, there is deviation in the hazard values at lower Vs values generated from OQ in comparison with NRCan, is it still okay to confide in these values and use the same input files moving forward for the next analyses, as this deviation is due to upgraded Engine and the values generated by current engine cannot be deemed erroneous.

2) If not, kindly advise, what version of OQ should I use to generate hazard curves for the NBCC 2020 model for low Vs values, as 3.11.5 continues to give operational error. 

Thanks,

Prajakta

On Mon, Mar 25, 2024 at 12:41 PM Peter Pažák <peter...@gmail.com> wrote:

Hi, yes, up to OQ v3.11 NRCan used tabular GMPEs meaning pre-calculated for a set of distances, magnitudes and vs30 values.

In the latest versions the GMPEs are re-implemented as formulae. I checked with the "CanadaSHM6trial" version at that time

and the discrepancies were not dramatic, one bug was hopefully eliminated.

I am not sure which version was used for the web interface. If the older one, for sure such differences could appear.

Peter

Dátum: streda 20. marca 2024, čas: 19:09:53 UTC+1, odosielateľ: prajakta.ra...@phd2013.iitgn.ac.in

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/0e2d037f-dc13-420b-b3a5-a0db56942a8fn%40googlegroups.com.

[Peter Pažák]

Hi,

I do have OQ v3.11.5 on my machine, I can confirm there are discrepancies:

When I am running 3.11 it even gives these warnings:

ExperimentalWarning: CanadaSHM6_InSlab_AbrahamsonEtAl2015SSlab55 is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_InSlab_AbrahamsonEtAl2015SSlab30 is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_Interface_AbrahamsonEtAl2015SInter is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_ActiveCrust_BooreEtAl2014 is experimental and may change in future versions - the user is liable for their application

As I said, between OQ 3.11 and OQ 3.12 the implementation changed and GEM team worked on improved implementation of GMPEs, so it obviously led to some changes.

I am also mainly an user of NRCan data, so I am not able to comment in detail and comparing code is time consuming, from the communication with NRCan it seemed they will

adopt newer versions of the OQ engine at some point but I do not have an information when this should happen. Maybe someone else could comment, but I guess the newer implementation is an improvement of the older and should be used, differences are hopefully not too large.

Peter

 

Dátum: pondelok 25. marca 2024, čas: 22:51:47 UTC+1, odosielateľ: prajakta.ra...@phd2013.iitgn.ac.in

[Michele Simionato]

On Tuesday, March 26, 2024 at 7:40:40 AM UTC+1 peter...@gmail.com wrote:

Hi,

I do have OQ v3.11.5 on my machine, I can confirm there are discrepancies:

When I am running 3.11 it even gives these warnings:

ExperimentalWarning: CanadaSHM6_InSlab_AbrahamsonEtAl2015SSlab55 is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_InSlab_AbrahamsonEtAl2015SSlab30 is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_Interface_AbrahamsonEtAl2015SInter is experimental and may change in future versions - the user is liable for their application
ExperimentalWarning: CanadaSHM6_ActiveCrust_BooreEtAl2014 is experimental and may change in future versions - the user is liable for their application

As I said, between OQ 3.11 and OQ 3.12 the implementation changed and GEM team worked on improved implementation of GMPEs, so it obviously led to some changes.

I am also mainly an user of NRCan data, so I am not able to comment in detail and comparing code is time consuming, from the communication with NRCan it seemed they will

adopt newer versions of the OQ engine at some point but I do not have an information when this should happen. Maybe someone else could comment, but I guess the newer implementation is an improvement of the older and should be used, differences are hopefully not too large.

We investigated similar discrepancies months ago and they were caused by a bug that we fixed. There could be another bug. The issue is that investigating such problems is hard and takes a lot of time

that we don't have, since we have deadlines for other projects. What you can do Peter is to send me the job.zip file corresponding to the calculation above and perhaps after Easter I will

have the time to look at it.

Thanks,

             Michele

 

[Peter Pažák]

Hi Michele, I perfectly understand that, my time is also limited, but this is a great place to learn :)

I have run the exact same input Prajakta has shared above - will be from NRCan website, attaching it again.

It is interesting that although the input files are the same, the checksum is different in 3.11 and 3.19, but that may have other reasons...

Anyways, thank you very much Michele!

Peter

Dátum: utorok 26. marca 2024, čas: 7:55:30 UTC+1, odosielateľ: michele....@globalquakemodel.org

[Michele Simionato]

On Mon, Mar 25, 2024 at 10:51 PM 'Prajakta Jadhav' via OpenQuake Users <openqua...@googlegroups.com> wrote:

  Hi Peter and OQ team. 

The tabular GMPEs are corresponding to SHM5 based NBCC 2015 model. I am not sure if the SHM6 based 2020 model was also implemented as tables in previous versions. However, in the present NBCC 2020 model, as you mentioned, the GMPEs are implemented as formulae. I am at the moment interested in the recent NBCC 2020 model, and I am a bit concerned about the deviation in values for low Vs, as I need to run OQ analyses for lower Vs values for the project, and so I have following qns:

1) Although, there is deviation in the hazard values at lower Vs values generated from OQ in comparison with NRCan, is it still okay to confide in these values and use the same input files moving forward for the next analyses, as this deviation is due to upgraded Engine and the values generated by current engine cannot be deemed erroneous.

2) If not, kindly advise, what version of OQ should I use to generate hazard curves for the NBCC 2020 model for low Vs values, as 3.11.5 continues to give operational error. 

What is the operation error you have? Something like the following?

sqlite3.OperationalError: table job has no column named host:
INSERT INTO job (is_running, description, user_name, calculation_mode, ds_calc_dir, hazard_calculation_id, host)
VALUES (?, ?, ?, ?, ?, ?, ?) (1, 'test', 'michele', 'scenario_risk', '/home/michele/oqdata', None, 'fedora')

This happens sometimes when changing versions. The solution (assuming you have the command sqlite3 installed)

is to run

$ echo 'ALTER TABLE job ADD COLUMN host;' | sqlite3 `oq db get_dbpath`

Alternatively, if you don't need to keep track of the old calculations you can just delete the database

and it will be recreated automatically.

HTH,

                                           Michele

[Michele Simionato]

Good news!

Michal Kolaj from NRCan contributed a couple of fixes (https://github.com/gem/oq-engine/pull/9548/files) and now the engine gives the same numbers as in version 3.11 :-)

The fix has been backported to engine-3.19, so you can just reinstall.

Thanks to everybody involved,

       Michele Simionato

[Prajakta Jadhav]

This is great!  Thanks OQ team and Michal Kolaj (NRCan) for working on this query :)

Although the user version of OQ-3.19 on this link (https://downloads.openquake.org/pkgs/windows/oq-engine/), shows last updated on Mar 5th, 2024; after installing it will still have the updated files, right? 

Michele- Thanks for suggesting solution for the operational error. Please find the operational error screen-shot, that I am getting at the moment. I used to get the error you mentioned; but yes if I delete every bit of previous versions then I don't get the same operational error but the one attached in the snapshot. Probably, I can try modifying the syntax you have shared above by replacing 'host'. But, I would want to get rid of such error messages, altogether if I can. 

[Michele Simionato]

On Wed, Mar 27, 2024 at 3:15 AM 'Prajakta Jadhav' via OpenQuake Users <openqua...@googlegroups.com> wrote:

This is great!  Thanks OQ team and Michal Kolaj (NRCan) for working on this query :)

Although the user version of OQ-3.19 on this link (https://downloads.openquake.org/pkgs/windows/oq-engine/), shows last updated on Mar 5th, 2024; after installing it will still have the updated files, right? 

Wrong, we have not regenerated the Windows installer yet.

 

Michele- Thanks for suggesting solution for the operational error. Please find the operational error screen-shot, that I am getting at the moment. I used to get the error you mentioned; but yes if I delete every bit of previous versions then I don't get the same operational error but the one attached in the snapshot. Probably, I can try modifying the syntax you have shared above by replacing 'host'. But, I would want to get rid of such error messages, altogether if I can. 

Same solution:  $ echo 'ALTER TABLE job ADD COLUMN size_mb;' | sqlite3 `oq db get_dbpath`

This command is meant to work on linux and macos or the windows linux subsystem.

[Michele Simionato]

Here is the new installer with the fix: https://downloads.openquake.org/pkgs/windows/oq-engine/OpenQuake_Engine_3.19.0-2.exe

[Prajakta Jadhav]

Thanks very much, Michele! It was super helpful. The hazard values at low Vs values match well with that of NRCan. :)

Just FYI, there is deviation up to 4% for higher periods, Sa (10.0), corresponding to 2% in 50 years Eq, as shown in snapshot here.

Cheers,

Prajakta

[Sujan Raj Adhikari]

Do we have a Qgis plugin for this new version?

   Best Regards

Sujan Raj Adhikari

a: University of Western Ontario | London On, Canada

Don’t print everything.....please do protect trees...GO GREEN...save energy

--

You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/f0ca1ac3-41ba-408e-b11c-c1209f3b99a2n%40googlegroups.com.

[Owen Jiang]

Hi team,

I am using OQ V3.19.1 with the CanadaSHM6 downloaded from OpenFile 8924. The following error has been encoutered. Could you please have a look and let me know if you have any comments. Thank you.

2024-05-16T21:26:36.68,INFO,SpawnProcess-2/21584,Using engine version 3.19.1

2024-05-16T21:26:37.36,WARNING,SpawnProcess-2/21584,Using 20 processpool workers

2024-05-16T21:26:37.37,INFO,SpawnProcess-2/21584,Checksum of the inputs: 3737387176 (total size 214.73 KB)

2024-05-16T21:26:37.38,INFO,SpawnProcess-2/21584,Running PreClassicalCalculator with concurrent_tasks = 40

2024-05-16T21:26:37.39,INFO,SpawnProcess-2/21584,Extracting the hazard sites from the site model

2024-05-16T21:26:37.42,CRITICAL,SpawnProcess-2/21584,Traceback (most recent call last):

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\engine\engine.py", line 281, in run_calc

calc.run(shutdown=True)

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 255, in run

raise exc from None

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 243, in run

self.pre_execute()

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 643, in pre_execute

calc.run(remove=False)

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 255, in run

raise exc from None

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 243, in run

self.pre_execute()

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 653, in pre_execute

self.read_inputs()

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 491, in read_inputs

self._read_risk_data()

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\calculators\base.py", line 807, in _read_risk_data

haz_sitecol = readinput.get_site_collection(

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\commonlib\readinput.py", line 598, in get_site_collection

mesh = get_mesh(oqparam, h5)

^^^^^^^^^^^^^^^^^^^^^

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\commonlib\readinput.py", line 423, in get_mesh

sm = get_site_model(oqparam)

^^^^^^^^^^^^^^^^^^^^^^^

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\commonlib\readinput.py", line 487, in get_site_model

sm = hdf5.read_csv(fname, site.site_param_dt).array

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\baselib\hdf5.py", line 964, in read_csv

dt = build_dt(dtypedict, header, fname)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "C:\Users\ojiang\AppData\Local\Programs\OpenQuake Engine\python3\Lib\site-packages\openquake\baselib\hdf5.py", line 854, in build_dt

raise InvalidFile('%s: missing dtype for field %r' %

openquake.baselib.InvalidFile: C:\Users\ojiang\AppData\Local\Temp\tmp5qozhi02\calc_50\CanadaSHM6_NBCC2020\OpenQuakeModel\INI\WesternCities.csv: missing dtype for field 'location'

[bahar r]

Hello OQ Group,

I am using OQ version 3.18 and am conducting a scenario-based hazard assessment utilizing the 2020 GSC ground motion models for stable crust. When performing calculations, each intensity_measure_type provides 16 event_id values. I suspect these correspond to the 13 NGA East ground motion models and three AA13 models.

As my goal is to perform a deterministic calculation for just one scenario, I am puzzled as to why OQ does not yield a single value for each site. Instead, it provides 16 values for each point. Could you please clarify this behavior and advise on how to obtain a single deterministic value for each site?

Thank you for your assistance.

Best regards,

Bahar

[bahar r]

Hello OQ Group,

I am using OQ version 3.18 and am conducting a scenario-based hazard assessment utilizing the 2020 GSC ground motion models for stable crust. When performing calculations, each intensity_measure_type provides 16 event_id values. I suspect these correspond to the 13 NGA East ground motion models and three AA13 models.

As my goal is to perform a deterministic calculation for just one scenario, I am puzzled as to why OQ does not yield a single value for each site. Instead, it provides 16 values for each point. Could you please clarify this behavior and advise on how to obtain a single deterministic value for each site?

Thank you for your assistance.

Best regards,

Bahar

On Thursday, May 16, 2024 at 5:48:02 p.m. UTC-4 uvicwen...@gmail.com wrote:

[Peter Pažák]

Hi, maybe avg_gmf would help you: https://groups.google.com/g/openquake-users/c/XO6Uf_gxBPM

oq export avg_gmf <calc_id>

if the comments are still true, it should be geometric mean.

It is not so difficult to load gmf_data into a pandas dataframe and do mean gmf if that would suit you better...

Peter

Dátum: utorok 28. mája 2024, čas: 7:58:44 UTC+2, odosielateľ: bahar...@gmail.com

[bahar r]

Hello Peter,

Thank you for your response.

I understand that each of the ground motion models has a specific weight and that the NGA-East weights depend on the Vs30 and IM periods. Given this, I am unsure how to validate my results with the geomean you mentioned. It seems this could be another issue arising from using GSC 2020 within the OQ framework for scenario base assessment.

I would appreciate any further guidance or recommendations you may have regarding this matter.

Thank you for your assistance.

Bahar

[Peter Pažák]

So even the weighting of the ground motion values can be done if you load the ground motion fields into pandas array

(also possible directly from the hdf5 file) then multiply by weights and sum. You just need to know which GMPE corresponds to which realization.

Peter

Dátum: utorok 28. mája 2024, čas: 19:22:06 UTC+2, odosielateľ: bahar...@gmail.com