Custom Query (454 matches)

To increase the flexibility of defining more complicated rupture surfaces later (e.g., base on T-surfs or to include multi-fault ruptures), and to improve computational efficiency with respect to computing propagation effects (e.g., distanceJB), we want to revise the treatment of rupture surfaces.

Currently what's returned by EqkRupture?.getRuptureSurface() is an EvenlyGriddedSurface?, which then gets passed (together with a Site) to some kind of calculator (e.g., a PropagationEffect? class or a PropagationEffectParameter?) in order to compute the propagation effect values. This definition made the rupture surface oblivious to any propagation effects, which was elegant from an encapsulation perspective. However, this is more costly in terms of computations.

The change is to make whatever is returned from EqkRupture?.getRuptureSurface() able to compute the propagation effects itself (for a given site location). This means that these surfaces, by definition, know about propagation effects. But what's really good is these calculations do not need to be redone if the site location does not change. For example, in UCERF3 there will be many ruptures that utilize the same section of fault, so this new framework will allow us to compute this distance only once (and perhaps the same could go for a careful redefining of how floating ruptures are handled, and even the treatment of background seismicity if we model these with actual finite surfaces).

To this end, Ned has written a new interface "org.opensha.sha.faultSurface.RuptureSurface?", which is what will now be returned by EqkRupture?.getRuptureSurface(), where EvenlyGriddedSurface? will implement this interface (so everything should still work). In the future we can define alternative types of surfaces (besides EvenlyGriddedSurface?) that implement the RuptureSurface? interface.

The following are the next steps:

1) change EqkRupture?.getRuptureSurface() to return the new RuptureSurface? interface.

2) change the EvenlyGriddedSurface? interface to implement the RuptureSurface? interface, and implement this new interface in all classes that presently implement EvenlyGriddedSurface?. This means porting the propagation effect calculations to these RuptureSurface? implementing classes (and taking the calculations out of the PropagationEffect? and PropagationEffectParameter? classes, where the latter will simply fetch the values from the RuptureSurface? interface).

3) the above changes will cause errors where whatever is calling EqkRupture?.getRuptureSurface() needs methods that are unique to EvenlyGriddedSurface?. Ideally, we would change those references to get what they need to from the RuptureSurface? interface (I've already added many such methods to RuptureSurface?). Where this is not feasible, or too much work, we can simply cast what's returned by EqkRupture?.getRuptureSurface() to an EvenlyGriddedSurface?. The latter will be fine in sub-packages that never will encounter anything other than an EvenlyGriddedSurface? (e.g., e.g., all the analysis calculations for UCERF2 will be fine since we aren't going to change UCERF2 to utilize any new types of surfaces). Code that does need to deal with new surfaces in the future (e.g., Cybershake stuff) can deal with the new cases when they come along (e.g., when casting to EvenlyGriddedSurface? fails).

Interestingly, this change will remove a big motivation for having the "PropagationEffect?" class, which was created to avoid redundant distance calculations when , for example, multiple IMRs need the same thing.

We may still want to keep the "PropagationEffect?" class for dealing with the prSrcCorr and nshmpPtSrcCorr options, but we need to think about this a bit more.

I modified FaultSectionPrefData? to: 1) contain a coupling coefficient; 2) add option to apply this and aseismicity factor to various get methods (e.g., getOrigSlipRate() versus getReducedSlipRate(); 3) apply aseismicity as an increase of upper seismogenic depth only (no change in lower seismogenic depth) as recommended by Ray Weldon; and 4) cache the Stirling surface for efficient distance calculations.

I moved the previous getSimpleFaultData(aseisReducesArea) method to getSimpleFaultDataOld(aseisReducesArea), where the latter applies aseismicity as a modification of both upper and lower seismogenic depths (needed for UCERF2 and other legacy calcs). I used my judgement in what should apply the new method, so be on the lookout for potential problems.

This ticket submitted after the fact so that this change gets picked up in the release notes of v1.3

WGCEP_UCERF_2_3 is no longer supported as relevant databases will soon be changing to support UCERF3. Use WGCEP_UCERF_2_Final instead for which all database data has been converted to flat files.