Source Specific Logic Trees

There are situations in which the hazard model is comprised by a small number of sources, and for each source there is an individual logic tree managing the uncertainty of a few parameters. In such situations we say that we have a Source Specific Logic Tree.

Such situation is esemplified by the demo that you can find in the directory demos/hazard/LogicTreeCase2ClassicalPSHA, which has the following logic tree, in XML form:

As you can see, each branchset has an applyToSources attribute, pointing to one of the two sources in the hazard model, therefore we have a source specific logic tree.

In compact form we can represent the logic tree as the composition of two source specific logic trees with the following branchsets:

src "1": [<abGRAbsolute(3)>, <maxMagGRAbsolute(3)>]
src "2": [<abGRAbsolute(3)>, <maxMagGRAbsolute(3)>]

The (X) notation denotes the number of branches for each branchset and multiplying such numbers we can deduce the size of the full logic tree (ignoring the gsim logic tree for sake of simplificity):

(3 x 3 for src "1") x (3 x 3 for src "2") = 81 realizations

It is possible to see the full logic tree as the product of two source specific logic trees each one with 9 realizations. The interesting thing it that the engine will require storage and computational power proportional to 9 + 9 = 18 basic components and not to the 9 * 9 = 81 final realizations. In general if there are N source specific logic trees, each one generating R_i realizations with i in the range 0..N-1, the number of basic components and final realizations are respectively:

C = sum(R_i)
R = prod(R_i)

In the demo the storage is over 4 times less (18 vs 81); in more complex cases the gain than can be much more impressive. For instance the ZAF model in our mosaic (the national model for South Africa) contains a source specific logic tree with 22 sources that can be decomposed as follows:

In other words, by storing only 186 components we can save enough information to build 24_959_374_950_829_916_160 realizations, with a gain of over 10^17!

Extracting the hazard curves

While it is impossible to compute the hazard curves for 24_959_374_950_829_916_160 realizations, it is quite possible to get the source-specific hazard curves. To this end the engine provides a class HcurvesGetter with a method .get_hcurves which is able to retrieve all the curves associated to the realizations of the logic tree associated to a specific source. Here is the usage:

from openquake.commonlib.datastore import read
from openquake.calculators.getters import HcurvesGetter

getter = HcurvesGetter(read(-1))
print(getter.get_hcurves('1', 'PGA'))  # array of shape (Rs, L)

Looking at the source-specific realizations is useful to assess if the logic tree can be collapsed.