[Shake-dev] Varying GMPE bias correction parameters

David Wald wald at usgs.gov
Fri Oct 17 02:23:48 UTC 2014


Hi Nick,

Good to hear from you. Thanks for sharing this query with the group. Let me
add to Bruce's thoughts on this.

Bruce implemented both an L1 & L2 norms for the bias correction. L1 is the
default. L2, however, will weight larger amplitudes over lower ones thus
³favoring" close-in stations (if the number of stations is comparable). This
behavior needs to be validated. If the L2 is effective for this purpose, you
could increase the maximum distance routinely.

That said, I¹m not sure I would want to rely on a distant-only data set to
compute an inter-event bias term, hence the cut off. A GMPE misfit in the
attenuation with distance at distant sites by could be incorrectly absorbed
in a bias term that then incorrectly resets estimated amplitudes at near-in
distances. Thus a reasonable cut-off distance (bias_max_range) seems like a
good precaution. 

All this gets back to the very real concern that a singe inter-event term in
the GMPE business is probably too simple for some events. For instance most
GMPE¹s underestimate close in stations for recent M6.0 Napa event yet
over-predict distance sites. A single bias term mostly fixes one yet
degrades the other. We know better than trying to invert for too many
parameters on the fly, however.

Cheers,

David

‹
David Wald, Ph.D.
U.S. Geological Survey, Golden, CO
wald at usgs.gov, (303) 273 8441

Adjunct Associate Professor of Geophysics
Colorado School of Mines

From:  Bruce Worden <cbworden at gmail.com>
Date:  Thursday, October 16, 2014 at 6:42 PM
To:  Nick Horspool <n.horspool at gns.cri.nz>
Cc:  <shake-dev at geohazards.usgs.gov>
Subject:  Re: [Shake-dev] Varying GMPE bias correction parameters

> Hi Nick,
> 
> This issue has come up for us recently, too. I'm thinking of adding an
> optional parameter that sets the maximum number of stations to use in the bias
> in addition to the minimum. I'm not sure if that would solve your problem (I'm
> not sure it would solve ours, either), but it is something we're thinking
> about.
> 
> In the meantime, there currently isn't a particularly elegant way to do what
> you want. The best I can offer would be to use zone_config and define
> geographic polygons where events would have adequate numbers of near stations
> (these polygons are defined with "box" statements in zone_config.conf). If you
> name these boxes "NEAR," for example, then in the .../config/zone directory
> you would have "grind.NEAR" with the 100km config. The default
> .../config/grind.conf would have the 200km config. You would then run
> zone_config as the first process after .../data/<event_id>/input/event.xml is
> created. zone_config would look at the epicenter to determine if it was inside
> one of the polygons: If it was, .../config/zone/grind.NEAR would be copied (as
> grind.conf) to .../data/<event_id>/config and used in preference to the
> default .../config/grind.conf. If the epicenter was not inside one of your
> polygons, then .../config/grind.conf would be used.
> 
> You could also do the opposite -- have the polygons for the more distant
> stations. Or you could have three or more zones.
> 
> If you go this route, one thing to keep in mind is that the events that have
> event-specific grind.conf (in .../data/<event_id>/config) will always use that
> file  (until you delete it) in preference to the default config file. So if
> you change grind.conf in .../config and re-run the event, it won't see the
> change. You'd have to change (or delete)
> .../data/<event_id>/config/grind.conf.
> 
> Hope this helps,
> Bruce
> 
> 
> On Oct 16, 2014, at 2:37 PM, Nick Horspool <n.horspool at gns.cri.nz> wrote:
> 
>> Hi All
>> 
>> I was wanting to know if there is a way to vary the GMPE bias correction
>> parameters. I would like to set the bias_max_distance parameter to a default
>> value (say 100km), but if the conditions for bias correction is not met, then
>> revert to another value (e.g. 200km). The min_number_stations would be set to
>> a fixed value (e.g. 6).
>> 
>> The reason for this, is that for most of our events, our network is dense
>> enough to have many stations within 100km to perform bias correction.
>> However, for a small proportion of events our network does not have enough
>> stations within 100km to run the bias correction. We don¹t want to default to
>> much more than 100km as we would like to have the near source observations
>> dominating the bias correction.
>> 
>> Thanks in advance
>> 
>> Nick Horspool
>> ___________________________
>> Nick Horspool 
>> Natural Hazard Risk Specialist
>> Risk and Society Department
>> GNS Science 
>> TE PU AO 
>> 1 Fairway Drive, Avalon, P O Box 30 368, Lower Hutt 5040, New Zealand
>> E n.horspool at gns.cri.nz, T +64 4 570 4282, F +64 4 570 4600
>> www.gns.cri.nz <http://www.gns.cri.nz/>
>> 
>> 
>> 
>> 
>> Notice: This email and any attachments are confidential. If received in error
>> please destroy and immediately notify us. Do not copy or disclose the
>> contents.
>> _______________________________________________
>> Shake-dev mailing list
>> Shake-dev at geohazards.usgs.gov
>> https://geohazards.usgs.gov/mailman/listinfo/shake-dev
> 
> _______________________________________________ Shake-dev mailing list
> Shake-dev at geohazards.usgs.gov
> https://geohazards.usgs.gov/mailman/listinfo/shake-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/shake-dev/attachments/20141016/90b07f92/attachment-0001.html>


More information about the Shake-dev mailing list