Let site regions specify logic trees of GMMs
It turns out, using GmmFlag
region IDs doesn't work well as the number of specialized regions grows within a tectonic setting, which controls the makeup of gmm-tree.json
. It would be better to have in site-data/gmm-region
files:
{
"type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [[
[-119.66000, 34.28000],
[-119.97172, 34.43575],
...
[-118.17976, 33.49368],
[-119.66000, 34.28000]
]]
},
"properties": {
"name": "Los Angeles, CyberShake",
"id": "LA_CYBERSHAKE"
"gmm-trees": {
"active-crust": {
"all": [
{ "id": "ASK_14_BASIN", "weight": 0.1875 },
{ "id": "ASK_14_CYBERSHAKE", "weight": 0.0625 },
...
{ "id": "CY_14_BASIN", "weight": 0.1875 },
{ "id": "CY_14_CYBERSHAKE", "weight": 0.0625 }
]
}
}
}
}
Doing so has the added benefit of reducing the GMM logic tree to something smaller outside specialized basins or zones. I think we should also support being able to define the gmm-tree
in the basin
geojsons.
Need to figure out how to manage site dependent GmmSet
overrides. Probably replace flag set in Site with gmm logic tree. May have to carry reference to gmm tree used in classes like HazardResultSet
because GMMs are referenced in calculators through an immutable RuptureSet
.
Edited by Powers, Peter M.