[Shake-dev] regression distances and plotregr

[Bruce Worden]

Jack,

If you had actually bothered to read and comprehend my email, you  
would understand that ShakeMap accommodates attenuation relations  
that use hypocentral distance or distance to the rupture plane, as  
well as those that use JB distance.  It could also accommodate other  
distance measures, whatever those might be.  It simply does not  
currently handle modules that arbitrarily and capriciously mix their  
distance measures for the different ground motion parameters.  Nor  
does it work properly with modules that don't supply a programmatic  
handle to their non-JB distance-calculating routine.  How do you  
expect ShakeMap (or Pete's program) to know how far your model thinks  
a point is from the "source?"  Should it guess?

Break the rules all you want, you scamp you.  Just don't expect your  
module to work properly.

Best,
Bruce


On Mar 6, 2007, at 5:02 PM, Jack Boatwright wrote:

> Bruce,
>
> Source depth is an important parameter for moderate earthquakes,  
> and it can
> strongly condition the attenuation of ground motion.  I'm appalled  
> that you
> regard modelling ground motion as a rule-bound programming  
> exercise, and
> that you're willing to degrade the ability of ShakeMap to model  
> data from
> these events because you insist that the distance measure that
> Bill Joyner and Dave Boore used for large earthquakes in 1979 be  
> used for
> all earthquakes.
>
> Had you made the rules more explicit, I still would have broken them.
>
> 				take care,             Jack
>
> At 3:39 PM -0800 3/6/07, Bruce Worden wrote:
>> Hi Pete,
>>
>> I think the problem is that Small_Seg.pm cheats a little bit in a
>> couple of ways (though I blame myself for not making the rules more
>> explicit).  First, it is using more than one distance measure within
>> the same module, something that isn't anticipated by the system (and
>> which will not work correctly as grind is currently written).
>> Second, it isn't admitting that it uses anything other than Rjb.
>>
>> As Kris points out, a module that uses distance-to-fault should set
>> its "dist" element to either dist_hypo or dist_rrupt, and it should
>> assume that it will be given that distance in subs "maximum()" and
>> "random()" if those functions are called with a distance.  See subs
>> new() and maximum() in Youngs97.pm for an example.
>>
>> The implementation here is that estimates (and the bias) use a lat
>> and lon to get a distance from the regression-supplied distance
>> function (dist_rjb by default).  That dist may then be modified by
>> the uncertainty estimate.  The resulting distance is given back to
>> the regression, which returns an amplitude(s) for the point.
>>
>> Changing the code to accommodate modules that use different distance
>> measures for different ground motion parameters would be a
>> considerable undertaking and involve a not-insignificant performance
>> hit, and I'm not sure that it will ever be required for any modules
>> other than Small_Seg and Large_Seg. (Dave?  Vince?)
>>
>> I imagine this situation has caused some discrepancy between your
>> estimates and your data, especially near the epicenter of small, deep
>> events.  But it is hard to say how much your maps are affected in
>> general.  I believe you are using HazusPGV for your larger events, so
>> that should not be an issue.
>>
>> In the short term, I suggest you switch to Vince's Small.pm module,
>> which should work fairly well for N Cal.  In the near future we are
>> all (at least in the US) going to have to switch to NGA regressions
>> (probably BA_oct06 for N and S CA), which are calibrated down to
>> about M4.0, so this will become even less of an issue.
>>
>> Bruce
>>
>>
>> On Mar 3, 2007, at 3:45 PM, Peter Lombard wrote:
>>
>>> Bruce,
>>>
>>> I have found a problem in plotregr that I really don't know how to
>>> solve. It
>>> may also be a problem in grind; you will have to evaluate that!
>>>
>>> When I wrote plotregr, I intended it to plot the data values so
>>> that they
>>> could be directly compared with the regression for the event
>>> magnitude. That
>>> means that the event data should be plotted at the distance that the
>>> regression module uses when it computes the regression values.
>>>
>>> Actual event data shows I have not achieved my goal. In NC, we  
>>> use the
>>> Small_Seg regression, which uses hypocentral distance for PGA and
>>> PGV. A
>>> recent event here had a hypocentral depth of 16.6 Km. A regression
>>> plot
>>> (attached) shows one station plotted at less than 4 km distance.
>>> That's not
>>> what I want.
>>>
>>> <pga_regr.gif>
>>>
>>> In plotregr, I try to use the distance function used by the
>>> regression, using
>>> the following code (borrowed from grind):
>>>
>>> #------------------------------------------------------------------- 
>>> --
>>> --
>>>     # Determine which regression to use, load it and create an  
>>> object
>>>     # Get functions for $DIST and $CUSTOM_SITECORR (custom distance
>>> and
>>>     # site correction functions)
>>>
>>> #------------------------------------------------------------------- 
>>> --
>>> --
>>>     my $regress = get_regression($src,$faultcoords);
>>>     %amp_sd = $regress->sd();
>>>
>>>     $DIST = \&dist_rjb;
>>>     $CUSTOM_SITECORR = undef;
>>>
>>>     if (defined $regress->{dist}) {
>>> 	print "Using custom distance formula\n";
>>> 	$DIST = $regress->{dist};
>>>     }
>>>
>>> The problem is that most regressions don't provide access to the
>>> function that
>>> is used by the regression to compute distance. Some regression
>>> modules use
>>> different distance measures for the different PGA, PGV, PSA values.
>>> Thus the
>>> regressions' distance function needs an argument to specify for  
>>> which
>>> regression variable the distance is to be calculated.
>>>
>>> For the plotregr program, this leads to misleading plots at near
>>> distances.
>>>
>>> Is this a problem for grind? Does it mean that the "wrong" distance
>>> is being
>>> used when comparing station data against the regression for the bias
>>> computation?
>>>
>>> Or is am I mistaken in my understanding of how ShakeMap works?
>>>
>>> Pete_______________________________________________
>>> Shake-dev mailing list
>>> Shake-dev at scsnmail.gps.caltech.edu
>>> http://unix1.gps.caltech.edu/mailman/listinfo/shake-dev
>>
>> _______________________________________________
>> Shake-dev mailing list
>> Shake-dev at scsnmail.gps.caltech.edu
>> http://unix1.gps.caltech.edu/mailman/listinfo/shake-dev
>
>
>
>