New Rupture Surface Representation

[Ned Field]

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.

[Ned Field]

I have finished developing this branch.

I spot checked a number of things using the local-mode GUIs, so I'm pretty sure things are OK.

What remains to be done is:

0) Notify developers to commit changes before the merge?

1) Merge branch back into trunk

2) Have Peter check results against the Junit tests he's been developing.

3) Test remote calc applications against local versions (e.g., I had to delete the method ScenarioShakeMapCalculator?.outputToServlet.writeObject(propagationEffect)), and I'm not sure whether this screwed anything up).

4) I added ptSrcDistCorr to:

DisaggregationCalculator?
HazardCurveCalculator?
ScenarioShakeMapCalculator?
SpectrumCalculator?

But we still need to add ptSrcDistCorr to:

HazusMapCalculator?
PortfolioLossCurveCalculator? (Kevin has been working on this?)

Hazard Maps (e.g., in sha.calc.hazardMap.components.CalculationSettings?)
Anywhere else?

[Kevin Milner]

I'm completed preparing SCEC-VDO (uncommitted until branch is merged) for the merge, but came across one issue:

Is it not possible to have a CompoundRuptureSurface?? I see that you implemented CompoundGriddedSurface?, but that's specific to EvenlyGriddedSurface?'s. For UCERF3 (the main initial user of compound surfaces), aren't we going to use a new surface representation (quads) anyway which won't be compatible with this class? Or will we need to create a CompoundQuadSurface? once the QuadSurface? class has been defined?

I understand that this might be tricky, but I think it'd be a big win if this were generic to any RuptureSurface?.

[Ned Field]

The only methods in CompoundGriddedSurface? that aren't applicable to a more generic (abstracted) CompoundRuptureSurface? are the get perimeter methods, since it's not clear how to create these for non-gridded surfaces. We probably should put all the other common methods in a parent AbstractCompoundRuptureSurface? class, but we can do that later when we implement the alternative types.

[Kevin Milner]

I think it's time to close this one as the new implementation has been widely used for a while now