[Shake-dev] Varying GMPE bias correction parameters

Mon Oct 20 19:53:10 UTC 2014

Bruce and David,

Thank you for your quick response and thoughtful comments. I suspected that using zone_config would be a work around. Its not the ideal solution, but will help us at this point in time.

I agree with your comments David about the issues with applying a single inter-event term. Ideally, we would want the GMPE to fit the data in our areas of interest, which would generally be population centres, to reduce the error in loss estimates (assuming thats the main application). Perhaps weighting the observation data by near-observation population would accomplish this. Although, I suspect using DYFI data this will implicitly occur (which we are currently not doing). 

Regards
Nick

___________________________ 
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 <mailto: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/>

> On 17/10/2014, at 3:23 pm, David Wald <wald at usgs.gov> wrote:
> 
> 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 <mailto:cbworden at gmail.com>>
> Date: Thursday, October 16, 2014 at 6:42 PM
> To: Nick Horspool <n.horspool at gns.cri.nz <mailto:n.horspool at gns.cri.nz>>
> Cc: <shake-dev at geohazards.usgs.gov <mailto: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 <mailto: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 <mailto: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 <mailto:Shake-dev at geohazards.usgs.gov>
>>> https://geohazards.usgs.gov/mailman/listinfo/shake-dev <https://geohazards.usgs.gov/mailman/listinfo/shake-dev>
>> 
>> _______________________________________________ Shake-dev mailing list Shake-dev at geohazards.usgs.gov <mailto:Shake-dev at geohazards.usgs.gov> https://geohazards.usgs.gov/mailman/listinfo/shake-dev <https://geohazards.usgs.gov/mailman/listinfo/shake-dev>

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/shake-dev/attachments/20141021/e4d54784/attachment.html>