Rupture type for multi-fault source with opposing dips

[Jack Williams]

Hi OpenQuake!

I have a question regarding the best rupture type to use in a scenario calculation for a multi-fault rupture which involves two reverse faults with opposite dips. This situation is represented in the map at the link below (MCE_RuptureSource.png), where the white circle is the site, the pink polygons are the rupture source with the red line indicating the top line of the rupture, the pink circle is is the (nominal) rupture epicentre, and the other red lines are other faults.

I have tried building the ruptures using both a multi-plane rupture ('rupture_model_multiplane.xml') and a simple fault rupture comprised of two fault geometries ('rupture_model_simple.xml'). The calculations run successfully using the BooreEtAl2014 and ChiouYoungs2014 GMM's (see job file in the linked folder).

However, when I checked these results against those derived from the USGS hazard spectra for an equivalent case as possible (in terms of rupture, source-to-site distances, and site conditions), the OpenQuake hazard values are higher (see mce_hazard_spectra_ref87.png)? I suspect this is to do with how OpenQuake derives the source-to-site distances, and maybe some unrealistic simplifications of 'average' rupture strike and dip for a source with oppositely dipping faults? Or maybe I put the wrong values in the USGS hazard spectra calculator.... Any insights are welcome!

To double check too, under the RHR, coordinates for an east-dipping simple source should go from south to north, and for a west-dipping source, coordinates should be listed from north to south??

I am using OpenQuake v3.20 on a MacOS. All the files referenced above can be found here: Oq_question

Cheers,
Jack

[Fatahillah Surya Yudha]

Dear Jack,

I think i have publication reference that seems answer your question,

https://doi.org/10.1785/0120130309

And some answer maybe documented here,

https://www.globalquakemodel.org/gempublications/openquake-hazard-component-testing-procedures

[Christopher Brooks]

Dear Jack,

The best OpenQuake rupture surface typology to use here is the MultiSurface class. For a bit more context, OpenQuake rupture objects which consider a MultiSurface can be generated from a MultiFaultSource. A MultiFaultSource contains a set of geometric sections (each with a unique section ID), which can combine to form different geometrically complex ruptures (which use the MultiSurfaceClass to combine them into a single OQ rupture surface in such instances).

Each potential combination of sections which can rupture in a single occurrence is referred to as a multi-planar rupture and each of these has a probability of occurrence within a given investigation time (just a side note in case you wish to consider such sources within a probabilistic analysis in OQ, the investigation time in your job file must correspond to that used to develop any MultiFaultSource(s) within your seismic source characterisation). 

Attached here I provide an example of an arbitrary OQ rupture usable within a scenario hazard calculation which was generated from a MultiFaultSource (i.e. the surface typology is MultiSurface as would suit your needs here). The rupture is provided in a CSV format (also usable within a scenario calculation), but the logic of how the MultiSurface rupture's mesh is specified is the same as if provided more conventionally within an XML.

Secondly, regarding the calculation of source-to-site distances, in the instance of considering a rupture generated from a MultiFaultSource, the OpenQuake Engine uses the GC2 system of Spudich and Youngs (2015). For simpler rupture surface typologies, the functions used to compute source-to-site distances consider the 3D Mesh of points representing the surface and a Mesh representing a given site to compute the seismic hazard at. I provide here links to each function which computes a finite rupture distance metric available in OQ; 1) Joyner-Boore distance, 2) rupture distance, 3) Rx and 4) Ry0.

Lastly, indeed your logic for satisfying the right-hand rule is correct.

Thanks, and I hope my answer is of help to you.

Christopher

GEM Seismic Hazard Team

[Jack Williams]

Hi both

Thanks for your helpful responses :)

The MultiSurface class does seem like the right approach here. However, I am having difficulty setting up a MultiFaultSource that can be used to generate a MultiSurface in a scenario calculation. Specifically, my understanding was that MultiFaultSources need separate input files that (1) define the geometry of the different sections and then (2) combine these sections into various multifault sources respectively (e.g., https://github.com/gem/oq-engine/tree/master/openquake/qa_tests_data/classical/case_65).

I had a go at this using the attached two files, but run into trouble with:

'RuptureConverter' object has no attribute 'convert_multiFaultSource'

So I suspect the scenario calculator is unable to read this MultiFaultSource as a single rupture? Any suggestion for what I'm getting wrong here?

FYI - I realise this question is essentially a duplication of this: https://groups.google.com/g/openquake-users/c/pyDPtOUJIbw/m/VohMIvuHAQAJ

However, the proposed solution for this query is to use a MultiPlanarRupture, not a MultiFaultRupture....

Cheers,
Jack

[Christopher Brooks]

Dear Jack,

To elaborate upon my initial response (and perhaps explain myself a bit better!), the MultiFaultSource source typology is often used to generate MultiSurface ruptures in a probabilistic analysis, but within a scenario calculation, we do not need to consider the source itself (I was just explaining in my initial response that MultiFaultSources are often generate such multi-planar surfaces for context, my apologies for the confusion).

Therefore, the solution both here and in the discussion you provide a link to is the same - that is, use a MultiPlanarRupture (i.e. a MultiSurface). 

One good approach to create a MultiSurface programmatically is to create a list of PlanarSurface objects (using PlanarSurface.from_corner_points is a good approach - it only requires the corners in 3D space of each surface) and then using MultiSurface(list_of_planars) to create a single MultiSurface object. This MultiSurface can then be used to create a regular OQ rupture object which considers a MultiSurface (i.e. it is a MultiPlanarRupture). You can then write this rupture to an XML or CSV for use in a scenario calculation. An alternative approach which is less programmatic which could also be quite straightforward can be seen here, where a multiPlanesRupture (in effect a MultiPlanarRupture) is constructed by specifying a KiteSurface in an XML.

Thanks,

Christopher

[Jack Williams]

Hi Christopher

Many thanks for your helpful reply, that all makes to me :)

I did, however, find some inconsistencies in how Rx is computed depending on whether I use a multiplane (Rx = -10.3 km) or simple rupture geometry (Rx = 22.6 km, this is the correct value) for a scenario calculation. Rjb (8.5 km) and Rrup (19.6 km) are the same for both rupture types. Any idea why this might be? I suspect the issue may be because Rx is derived for a planar surface (https://github.com/gem/oq-engine/blob/engine-3.20/openquake/hazardlib/geo/surface/planar.py#L483) in a different way from a simple rupture geometry (this is linked in your first reply)?

For reference, attached are the rupture .xml files I used, plus a map representing the source and site

Many thanks,

Jack

[Marco Pagani]

Hi Jack,

The calculation of Rx in the GC2 in the case of sections dipping in opposite directions is not ideal, as it “homogenizes” the dip direction for the whole rupture, causing some local inconsistencies. See Fig. 8 (top left panel) in https://pubs.usgs.gov/of/2015/1028/pdf/ofr2015-1028.pdf

Best wishes,

Marco

--
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/bdcd4c78-5866-4581-94c8-350bea918a02n%40googlegroups.com.