Opened 13 years ago

Closed 11 years ago

#332 closed task (fixed)

Compound rupture surfaces needed to support multi fault ruptures

Reported by: Kevin Milner Owned by: Kevin Milner
Priority: critical Milestone: OpenSHA 1.3
Component: sha Version:
Keywords: Cc:

Description

We need to implement compound rupture surfaces in order to support UCERF3 multi fault ruptures. I see a few ways of doing this:

  1. Modify each calculator to take a list of EvenlyGriddedSurfaces?
  2. Create a rupture surface interface which could be gridded, triangular, or a compound surface.
    • Distance calculations would be defined in this interface, and all calculators would be modified to use this general surface
    • this has the added benefit of allowing arbitrary surface types
  3. Create a rupture surface interface (like in 2. above), and modify calculators to accept a list of these objects (as opposed to making "CompoundSurface?" an implementation of the Surface interface)

However we decide to do it, it will require a pretty major overhaul of the ways that distances are computed in hazard calculations, and will take careful thought.

Change History (4)

comment:1 Changed 13 years ago by Kevin Milner

A couple thoughts about distance calculations. When supporting multiple surface implementations, we'll need a way to calculate all of these distance metrics (from http://www.opensha.org/glossary-distance):

DistanceX could get tricky with multi fault ruptures. First of all, how would the sign be determined if you had a mix of different fault types? Also, how do you extend the fault trace indefinitely if there are multiple fault traces? You would have to have the fault sections in order, perhaps, and the extend the first and last one? Still, weird things could happen if faults came together at a T. Is there a definition in literature that takes compound surfaces into account?

Theoretically, each of these distance calculations could be computed if each fault geometry could supply the following information:

  • distance to surface (optionally below a certain depth, for DistanceSeis?)
  • fault trace
  • surface projection

Or we could have each surface implementation actually have a calcDistanceRup, calcDistanceSeis, calcDistanceJB, calcDistanceX method. But then we'd want to take advantage of the propagation effect speedup. This gets complicated really quickly!

Version 0, edited 13 years ago by Kevin Milner (next)

comment:2 Changed 13 years ago by Peter Powers

I think that trying to develop apis that can handle the myriad of geometric complexities will be nightmarish. It could lead to code that is more complicated than warranted by relatively low-probability multi-fault rupture. An alternate possibility would be to partition moment over the various participant ruptures, treating any multi-fault event as multiple simultaneous events. I'm not sure what thought the NGA folks have to these matters, but I doubt there is enough data in their db to even consider providing empirical relationships for the kinds of ruptures were talking about.

Moment partitioning could be done based on area as a baseline, with more complicated rules perhaps being added if scientifically justifiable.

This, however, doesn't alleviate the need for faster distance calculations.

comment:3 Changed 13 years ago by Ned Field

There are other propagation-effect params in some attenuation relationships that will also need to be calculated (e.g., that deal with directivity).

We should really have a meeting to brainstorm the best way forward on this.

comment:4 Changed 11 years ago by Kevin Milner

Resolution: fixed
Status: newclosed

This has been done long ago, closing

Note: See TracTickets for help on using tickets.