Revert UCERF2_Final to useing original distance calculation metrics

[Kevin Milner]

E-mail chain below:

---

That makes sense Kevin.

Can you do it?

(and check the results)?

Thanks,

Ned

On Feb 17, 2011, at 10:49 AM, Kevin Milner wrote:

Ned,

Thanks for figuring this out!

I was thinking that we could dig the old version up from the repository, and put it somewhere in the UCERF2 package (so we don't clutter up the commons package with deprecated old versions).

What do you think?

Kevin

On 2/17/2011 5:55 AM, Ned (Edward) Field wrote:

OK, this explains it.

The upper mag is the mean+0.24, so for the seconds mags you listed from each run:

7.760313417005248 + 0.24 = 8.00031...
7.759870329651965 + 0.24 = 7.99987...

and the nearest discrete mag to each of these is 8.05 and 7.95, respectively.

I doubt this difference will have any influence on anything we've published (at least not to the relevant significant figs).

Unless the exact same calculation used in the old RelativeLocation?.getHorzDistance(loc1, loc2) still exists somewhere in the present project (a question for Peter), I'm not sure there is a good way to revert unless we want to add an "old" version:

LocationUtils?.horzDistanceOld(loc1, loc2);

(which does what RelativeLocation?.getHorzDistance(loc1, loc2) did), and to use this in an "old" version of:

FaultTrace?.getTraceLengthOld()

And then change UCERF2 stuff to use this old version.

Suggestions Peter?

Ned

On Feb 16, 2011, at 12:32 PM, Kevin Milner wrote:

Ned,

Should we modify UCERF2 in trunk to use the original version of that code for consistency with the published results?

I printed out the values that you asked for (each value is repeated many times).

Current (HEAD):
rupNameLong[23]: SJV+A+CC+B+SM
rupMeanMag[23]: 7.7177350627539365
...
rupNameLong[23]: SJV+A+CC+B+SM
rupMeanMag[23]: 7.760313417005248
...

Old version:
rupNameLong[23]: SJV+A+CC+B+SM
rupMeanMag[23]: 7.717402747238975
...
rupNameLong[23]: SJV+A+CC+B+SM
rupMeanMag[23]: 7.7598703296519655
...

Does this confirm your suspicions?

Thanks,
Kevin

On 02/15/2011 04:10 PM, Ned (Edward) Field wrote:

Hi Kevin,

I'm 95% sure this differences is due what's being returned by:

FaultTrace?.getTraceLength()

Previously distances herein were computed using:

RelativeLocation?.getHorzDistance(loc1, loc2);

And following changes/improvements made by Peter in spring of 2009 these are being computed using:

LocationUtils?.horzDistance(loc1, loc2);

I suspect this causes a slight difference in the length of faults, and therefore the mean magnitude computed from length*width. A change in mean mag can change the range of mags in the Gaussian distribution.

The test would be to write out the values of rupMeanMag[rup] (along with rupNameLong[rup]) right after it's computed near line 270 in A_FaultSegmentedSourceGenerator. Comparing this for the two runs would show any important slight mag diffs.

Let me know the result if you do this (I can tell you if this explains things).

If you need consistency I'd simply use the old code for your CyberShake? runs.

Thanks for pointing this out (we need to remember it in case it rears is ugly head elsewhere).

Cheers,

Ned

On Feb 15, 2011, at 4:00 PM, Kevin Milner wrote:

Ned,

Here's the info for the current repository HEAD, source 121 only:

*
ERF: WGCEP (2007) UCERF2 - Single Branch
Params: Rupture Offset = 5.0; Floater Type = Along strike & centered down dip; Background Seismicity = Exclude; Apply CyberShake? DDW Corr = true; Probability Model = Poisson

Source 121: San Jacinto;SJV+A+CC+B+SM, 7 Ruptures

0. mag: 7.45 prob: 5.610487E-7
1. mag: 7.55 prob: 3.9804104E-6
2. mag: 7.65 prob: 1.013452E-5
3. mag: 7.75 prob: 1.3163359E-5
4. mag: 7.85 prob: 8.7256085E-6
5. mag: 7.95 prob: 2.950272E-6
6. mag: 8.05 prob: 3.6185963E-7

summed probs: 3.987708E-5
*

And for the tagged old version:

*
ERF: WGCEP (2007) UCERF2 - Single Branch
Params: Rupture Offset = 5.0; Floater Type = Along strike & centered down dip; Background Seismicity = Exclude; Apply CyberShake? DDW Corr = true; Probability Model = Poisson

Source 121: San Jacinto;SJV+A+CC+B+SM, 6 Ruptures

0. mag: 7.45 prob: 5.64439E-7
1. mag: 7.55 prob: 4.067499E-6
2. mag: 7.65 prob: 1.0364772E-5
3. mag: 7.75 prob: 1.34737265E-5
4. mag: 7.85 prob: 8.93764E-6
5. mag: 7.95 prob: 3.02327E-6

summed probs: 4.0431347E-5
*

All parameters are the same. It looks like one larger rupture has been added, rup 6, mag 8.05. All of the probabilities have been scaled down accordingly.

Thanks,
Kevin

[Kevin Milner]

Done in [7569]. The old RelativeLocation? class was restored as trunk/src/org/opensha/sha/earthquake/rupForecastImpl/WGCEP_UCERF_2_Final/oldClasses/UCERF2_Final_RelativeLocation.java, and is now being used for all horizontal distance calculations by UCERF2.

There were a few cases where classes used by UCERF2 (FualtTrace?, StirlingGriddedSurface?) used the new horizontal distance calculation. I duplicated StirlingGriddedSurface? in trunk/src/org/opensha/sha/earthquake/rupForecastImpl/WGCEP_UCERF_2_Final/oldClasses/UCERF2_Final_StirlingGriddedSurface.java, and added a calcOldFaultLength method to UCERF2_Final_RelativeLocation to fix this.

Now all sources match the Spring 2009 values (in terms of # ruptures, magnitude of those ruptures, and probability of those ruptures). Also, hazard curve calculations show no change in the hazard results with this update. Ned, if you have any other verifications for me to do let me know. Closing the ticket.