Logic tree abGRAbsolute - combinations

[Clara Duverger]

Dear OpenQuake team,

I would like to better understand how the paths of the logic tree are explored using the option abGRAbsolute for instance in classical PSHA calculation. For that, I will try to explain a simple case :

I have only 1 source model with 5 areas and 1 gmpe. For each area source, I have 3 couples of (a,b) values. For instance, in the source_model_logic_tree file, for the area source "S1", I have :

...

        <logicTreeBranchingLevel branchingLevelID="bl1">
            <logicTreeBranchSet uncertaintyType="abGRAbsolute"
                                applyToSources="S1"
                                branchSetID="bs_S1">
                <logicTreeBranch branchID="b11">
                    <uncertaintyModel>a_11 b_11</uncertaintyModel>
                    <uncertaintyWeight>0.33</uncertaintyWeight>
                </logicTreeBranch>
                <logicTreeBranch branchID="b12">
                    <uncertaintyModel>a_12 b_12</uncertaintyModel>
                    <uncertaintyWeight>0.33</uncertaintyWeight>
                </logicTreeBranch>

                <logicTreeBranch branchID="b13">
                    <uncertaintyModel>a_13 b_13</uncertaintyModel>
                    <uncertaintyWeight>0.34</uncertaintyWeight>
                </logicTreeBranch>

           </logicTreeBranchSet>
        </logicTreeBranchingLevel>

...

How the combinations of (a,b) values play regarding the 5 area sources ? Do we have 3^(5)=243 paths, all the possible combinations, explored at the end of the computation, if the number_of_logic_tree_samples = 0 ?

Or do you use a specific optimization or calculation method behind it ?

---

Second question: if I set the number_of_logic_tree_samples = 243 (with all branches having the same weight), I know that I won't exactly have the 243 different branches explored, but do I have a chance to explore the same uncertainty range on (a,b) ? Or this number of samples is mainly driven by other parameters such as the uncertainty on the GMPE (truncation level), the depth of source hypocenters (hypodepth probability), etc. ?

My objective would be to only have 5 branches. For instance (source S, branch b):

- 1st branch: S1 with b11 + S2 with b21 + ... + S5 with b51

- 2nd branch: S1 with b12 + S2 with b22 + ... + S5 with b52

...

- 5th branch : S1 with b15 + S2 with b25 + ... + S5 with b55

to never have the same values of (a,b) for an area.

In this case, do I have to go through the artificial creation of alternative source model files and forget the option abGRAbsolute in the logic tree ?

In other terms, I need to create 5 source model files, which are exactly the same, except for the (a,b) values in the GR law for the 5 areas ?

---

Third question: in case of site-specific PSHA, generally we care more about the area where the site is. In this case, a reasonable approximation of the uncertainties would be to only modify the (a,b) values of the target area and let the other areas with a unique (a,b) couple.

But if you want to compute the hazard at many different sites (20 sites), do we have an option to enable the uncertainties on (a,b) values only for the area in which the site is ? Or the easiest way would be to reproduce the same computation for the 20 sites and create the logic tree file according to the studied site ?

I hope I was clear enough in my questions...

Many thanks in advance for your answers and patience,

Clara

[Michele Simionato]

Yes, all the paths are explored. However , the computational weight on the engine is of the order of 3*5=15 not 3^5=243 (it was that bad in years past, but not anymore). You can understand why it is so if you realize that internally

engine is creating three copies for each source, each one with a different set of parameters, therefore the calculation  involves 3*5=15 effective sources.

 

---

Second question: if I set the number_of_logic_tree_samples = 243 (with all branches having the same weight), I know that I won't exactly have the 243 different branches explored, but do I have a chance to explore the same uncertainty range on (a,b) ? Or this number of samples is mainly driven by other parameters such as the uncertainty on the GMPE (truncation level), the depth of source hypocenters (hypodepth probability), etc. ?

My objective would be to only have 5 branches. For instance (source S, branch b):

- 1st branch: S1 with b11 + S2 with b21 + ... + S5 with b51

- 2nd branch: S1 with b12 + S2 with b22 + ... + S5 with b52

...

- 5th branch : S1 with b15 + S2 with b25 + ... + S5 with b55

to never have the same values of (a,b) for an area.

In this case, do I have to go through the artificial creation of alternative source model files and forget the option abGRAbsolute in the logic tree ?

In other terms, I need to create 5 source model files, which are exactly the same, except for the (a,b) values in the GR law for the 5 areas ?

I do not understand. Since you have three branches for the fifth source you have only the possibilities b51, b52, b53, where do you get the b55? 

---

Third question: in case of site-specific PSHA, generally we care more about the area where the site is. In this case, a reasonable approximation of the uncertainties would be to only modify the (a,b) values of the target area and let the other areas with a unique (a,b) couple.

But if you want to compute the hazard at many different sites (20 sites), do we have an option to enable the uncertainties on (a,b) values only for the area in which the site is ? Or the easiest way would be to reproduce the same computation for the 20 sites and create the logic tree file according to the studied site ?

The engine does not automatically reduce the source model logic tree for sources which are distant. Notice that in practice one always uses sampling since full enumeration is computationally too expensive (it is very easy to get millions or billions of branches), then even if you use 3 branches for a source that it is distant, it does not matter. It is same effort to sample 100 branches from say 1 million branches (having reduced the logic tree from distance source) or from 3 million branches (having not done so).

If you want to understand how the engine manages source specific logic trees I have added a demo just for you: https://github.com/gem/oq-engine/tree/master/demos/hazard/LatinSamplingClassicalPSHA.

This used 4 sources with 3 variations each, so produces 3**4=81 paths from which I am sampling 12 paths. 

The demos uses latin hypercube sampling so that the space of the realizations is sampled more uniformly (see https://docs.openquake.org/oq-engine/advanced/sampling.html). The way to run it is

$ oq engine --run job.ini && oq show realizations

...

rlz_id,branch_path,weight

0,00_10_20_30_42~0,8.333334E-02

1,00_10_21_31_40~0,8.333334E-02

2,00_10_21_32_42~0,8.333334E-02

3,00_10_22_30_42~0,8.333334E-02

4,00_11_20_30_41~0,8.333334E-02

5,00_11_20_31_42~0,8.333334E-02

6,00_11_22_32_41~0,8.333334E-02

7,00_11_22_32_41~0,8.333334E-02

8,00_12_20_31_40~0,8.333334E-02

9,00_12_21_30_40~0,8.333334E-02

10,00_12_21_31_40~0,8.333334E-02

11,00_12_22_32_41~0,8.333334E-02

and you will see exactly which branches are sampled. Notice that you need to install engine from the git sources for the demo, and that engine 3.10 is buggy on this demo (yeah, I discovered the bug thanks to you).

HTH,

                       Michele

[Clara Duverger]

Dear Michele,

Many thanks for the answers and your time !

Answer 1: I do understand now the differences between the number of paths artificially created and the real computational weight.

Answer 2: My mistake, it was 3 branches with b51, b52, b53, and not 5 branches. You're totally right.

In this case, I  create 3 source model files with the same 5 areas but each area will have different GR parameters from one file to another, so 15 different area sources are implemented at the end. Are both implementations (implementation with different source model files or implementation using abGRAbsolute in the logic tree file)  equivalent in terms of computational weight or time ? I haven't tested yet, but theoretically ?

It seems that I create 3 branches (uncertaintyType: SourceModel) in one case and 243 branches (uncertaintyType: abGRAbsolute) in the other case.

Also, I find that the implementation with 'abGRAbsolute' is much more convenient than the other and also clearer at the end to analyze the realizations results.

Another point: if I set number_logic_tree_samples = 15, is it equivalent to number_logic_tree_samples = 0 in this example (assuming no other uncertainties) ? Or you may have discrepancies for the hazard curve quantiles ?

Answer 3: thank you very much Michele for this demo example, I will take a look at it soon.

Cheers,

---------------------------------------------------------

Clara DUVERGER

CEA – DIF/DASE/SLDG
Laboratoire Études Géophysiques et Aléas
91297 Arpajon cedex - FRANCE
Tel : 01 69 26 40 61

Mail : clara.d...@cea.fr

---------------------------------------------------------

--
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/QmlTNv0BIZU/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/c82ed25f-b30d-47c7-a2e9-3b1ee5777ccbn%40googlegroups.com.

[Michele Simionato]

On Monday, October 26, 2020 at 1:20:35 PM UTC+1 Clara Duverger wrote:

Dear Michele,

Many thanks for the answers and your time !

Answer 1: I do understand now the differences between the number of paths artificially created and the real computational weight.

Answer 2: My mistake, it was 3 branches with b51, b52, b53, and not 5 branches. You're totally right.

In this case, I  create 3 source model files with the same 5 areas but each area will have different GR parameters from one file to another, so 15 different area sources are implemented at the end. Are both implementations (implementation with different source model files or implementation using abGRAbsolute in the logic tree file)  equivalent in terms of computational weight or time ? I haven't tested yet, but theoretically ?

Yes, computationally they are the same, expect that the implementation with 243 realizations will require more disk storage. 

It seems that I create 3 branches (uncertaintyType: SourceModel) in one case and 243 branches (uncertaintyType: abGRAbsolute) in the other case.

Also, I find that the implementation with 'abGRAbsolute' is much more convenient than the other and also clearer at the end to analyze the realizations results.

Another point: if I set number_logic_tree_samples = 15, is it equivalent to number_logic_tree_samples = 0 in this example (assuming no other uncertainties) ? Or you may have discrepancies for the hazard curve quantiles ?

I suggest you to run the calculation and get the answers from yourself ;-) 

           Michele

[Clara Duverger]

Hello Michele or others,

My question is in the continuity of this topic.

With recent versions of OpenQuake (maybe from 3.11), I understood that we need to add the parameter "applyToBranches" with "applyToSources" when using uncertaintyType on GR, and in the case where we also have several source_model.xml files (treated with uncertainType sourceModel).

How do you efficiently set the "applyToBranches" in the demo LatinSamplingClassicalPSHA for instance (even if only one source_model is used and we do not need applyToBranches in this particular case) ? Do you create all the combinations (set the "applyToBranches" to the 3 GR branches of the previous source treated) and then set the number_of_logic_tree to 15 ? Is this the best solution or do you have any other tips ?

Ex:

...

    <logicTreeBranchSet uncertaintyType="bGRRelative"
                        branchSetID="bs1" applyToSources="A" applyToBranches="00">
      <logicTreeBranch branchID="10">
        <uncertaintyModel>+0.1</uncertaintyModel>
        <uncertaintyWeight>0.333</uncertaintyWeight>
      </logicTreeBranch>
      <logicTreeBranch branchID="11">
        <uncertaintyModel>0.0</uncertaintyModel>
        <uncertaintyWeight>0.333</uncertaintyWeight>
      </logicTreeBranch>
      <logicTreeBranch branchID="12">
        <uncertaintyModel>-0.1</uncertaintyModel>
        <uncertaintyWeight>0.334</uncertaintyWeight>
      </logicTreeBranch>
    </logicTreeBranchSet>

    <logicTreeBranchSet uncertaintyType="bGRRelative"
                        branchSetID="bs2" applyToSources="B" applyToBranches="10 11 12">
      <logicTreeBranch branchID="20">
        <uncertaintyModel>+0.1</uncertaintyModel>
        <uncertaintyWeight>0.333</uncertaintyWeight>
      </logicTreeBranch>
      <logicTreeBranch branchID="21">
        <uncertaintyModel>0.0</uncertaintyModel>
        <uncertaintyWeight>0.333</uncertaintyWeight>
      </logicTreeBranch>
      <logicTreeBranch branchID="22">
        <uncertaintyModel>-0.1</uncertaintyModel>
        <uncertaintyWeight>0.334</uncertaintyWeight>
      </logicTreeBranch>
    </logicTreeBranchSet>

...

Thank you in advance for your help,

[Michele Simionato]

applyToBranches is not necessary, simply avoid setting it and the branchset will be applied to all previous branches, which is what you want.

The engine will complain about a missing applyToBranches only if there is an ambiguity, i.e. if the same source is present in two different source models, so you need to specify where to attach the logic tree.

HTH,

                   Michele

[Clara Duverger]

Hello Michele,

Thank you for your comment, but it seems not the case for v3.12 for instance that I currently used. With this version (and probably previous ones) you need to specify applyToBranches, even if different source names are implemented in two different source models. I tested it with the LatinSamplingClassicalPSHA demo, adding a second source_model with some different sources and modifying the logic_tree.

Is "applyToBranches" not necessary from v3.13 ?

Cheers,

[Luiz Felipe Braga]

Hi everyone,

I'm reviving this thread because I ran into exactly the same situation you described, now on engine 3.23.

I want to vary the GR (a, b) of several sources within the same source model in a correlated way (the sources always moving together). Two things I confirmed on 3.23:

1. abGRAbsolute now accepts only one source id per branchset.
2. If I use applyToSources without applyToBranches in a logic tree with more than one source model, the branchset is applied to all source models, not just the one containing the source. On the models where the source id doesn't exist it's a no-op, but it still creates the branch, so the tree inflates (I get 144 realizations instead of 18). Adding applyToBranches pointing to the correct sourceModel branch fixes the count. This seems related to issue #4503 ("applyToSources for a non-existing source should be an error"), which is still not raising an error in 3.23.

The only working way I found to get correlated absolute values across several sources in the same source model is to duplicate the source model files with the (a, b) corrected.

Is there a way to apply abGRAbsolute to a source model with several area sources in a single branchset? (I calculated a and b with the Weichert (1980) method, and I have a second scenario with b = 1 for all sources.)

Thanks a lot

[Michele Simionato]

There is a plan to support correlated uncertainties, but right now we are working on the release of the Global Hazard and Global Risk models. After the GEM conference we will have some to work on that. It would be useful if you can suggest a syntax: how would you expect this feature to work at the XML level? Do you expect an applyToSources listing all the correlated sources, or something working a source group level?

        Michele Simionato

[Geremew Lamessa]

For the 2nd question, what you proposed is correct but for the last question , better to use vs30 as a gride file fir the site, including (a,b) values

With regards!

Geremew Lamessa(PhD)

Assistance professor of Geology and Geophysics

Wollega University

College of Natural  and Computational Sciences

Department of Earth Sciences, Ethiopia

Tele:+251911163404

Po.box:395,Nekemte
Email:olbir...@gmail.com

--
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 visit https://groups.google.com/d/msgid/openquake-users/f7ddf0be-dc7d-451b-b740-8971bc705d53n%40googlegroups.com.