<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Bruce and David,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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). </div><div class=""><br class=""></div><div class="">Regards</div><div class="">Nick</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><font color="red" face="Arial" class=""><b class="">___________________________</b></font> <br class=""><font size="2" face="Arial" class=""><b class="">Nick Horspool</b></font> <br class=""><font size="2" color="#5f5f5f" face="Arial" class="">Natural Hazard Risk Specialist </font><br class=""><font size="2" color="#5f5f5f" face="Arial" class="">Risk and Society Department</font> <br class=""><font size="2" color="#c21212" face="Arial" class=""><b class="">GNS Science</b></font> <br class=""><font size="2" color="#c21212" face="Arial" class=""><b class="">TE PU AO</b></font> <br class=""><font size="2" face="Arial" class="">1 Fairway Drive, Avalon, P O Box 30 368, Lower Hutt 5040, New Zealand</font> <br class=""><font size="2" face="Arial" class=""><b class="">E</b> <a href="mailto:n.horspool@gns.cri.nz" class="">n.horspool@gns.cri.nz</a>, <b class="">T </b>+64 4 570 4282, <b class="">F </b>+64 4 570 4600</font> <br class=""><a href="http://www.gns.cri.nz/" class=""><font size="2" color="blue" face="Arial" class=""><b class=""><u class="">www.gns.cri.nz</u></b></font></a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 17/10/2014, at 3:23 pm, David Wald <<a href="mailto:wald@usgs.gov" class="">wald@usgs.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class="">Hi Nick,</div><div class=""><br class=""></div><div class="">Good to hear from you. Thanks for sharing this query with the group. Let me add to Bruce's thoughts on this. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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 (<i class="">bias_max_range</i>) seems like a good precaution. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div class=""><div class="">—</div><div class="">David Wald, Ph.D.</div><div class="">U.S. Geological Survey, Golden, CO</div><div class=""><a href="mailto:wald@usgs.gov" class="">wald@usgs.gov</a>, (303) 273 8441</div><div class=""><br class=""></div><div class="">Adjunct Associate Professor of Geophysics</div><div class="">Colorado School of Mines</div></div></div><div class=""><br class=""></div><span id="OLK_SRC_BODY_SECTION" class=""><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class=""><span style="font-weight:bold" class="">From: </span> Bruce Worden <<a href="mailto:cbworden@gmail.com" class="">cbworden@gmail.com</a>><br class=""><span style="font-weight:bold" class="">Date: </span> Thursday, October 16, 2014 at 6:42 PM<br class=""><span style="font-weight:bold" class="">To: </span> Nick Horspool <<a href="mailto:n.horspool@gns.cri.nz" class="">n.horspool@gns.cri.nz</a>><br class=""><span style="font-weight:bold" class="">Cc: </span> <<a href="mailto:shake-dev@geohazards.usgs.gov" class="">shake-dev@geohazards.usgs.gov</a>><br class=""><span style="font-weight:bold" class="">Subject: </span> Re: [Shake-dev] Varying GMPE bias correction parameters<br class=""></div><div class=""><br class=""></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" class="" type="cite"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class="">Hi Nick,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">You could also do the opposite -- have the polygons for the more distant stations. Or you could have three or more zones.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Hope this helps,</div><div class="">Bruce</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class="">On Oct 16, 2014, at 2:37 PM, Nick Horspool <<a href="mailto:n.horspool@gns.cri.nz" class="">n.horspool@gns.cri.nz</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi All<div class=""><br class=""></div><div class="">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). </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Thanks in advance</div><div class=""><br class=""></div><div class="">Nick Horspool<br class=""><div apple-content-edited="true" class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div class=""><font color="red" face="Arial" class=""><b class="">___________________________</b></font> <br class=""><font size="2" face="Arial" class=""><b class="">Nick Horspool</b></font> <br class=""><font size="2" color="#5f5f5f" face="Arial" class="">Natural Hazard Risk Specialist </font><br class=""><font size="2" color="#5f5f5f" face="Arial" class="">Risk and Society Department</font> <br class=""><font size="2" color="#c21212" face="Arial" class=""><b class="">GNS Science</b></font> <br class=""><font size="2" color="#c21212" face="Arial" class=""><b class="">TE PU AO</b></font> <br class=""><font size="2" face="Arial" class="">1 Fairway Drive, Avalon, P O Box 30 368, Lower Hutt 5040, New Zealand</font> <br class=""><font size="2" face="Arial" class=""><b class="">E</b> <a href="mailto:n.horspool@gns.cri.nz" class="">n.horspool@gns.cri.nz</a>, <b class="">T </b>+64 4 570 4282, <b class="">F </b>+64 4 570 4600</font> <br class=""><a href="http://www.gns.cri.nz/" class=""><font size="2" color="blue" face="Arial" class=""><b class=""><u class="">www.gns.cri.nz</u></b></font></a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline"></div><br class=""></div><div class=""><div style="border-top: solid 1px black; border-bottom: solid 1px black;
padding: 10px 0; margin: 20px 0; font-size: 8pt;
font-family: Verdana, Arial, Helvetica, sans-serif;" class="">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.<br class=""></div></div></div>_______________________________________________<br class="">Shake-dev mailing list<br class=""><a href="mailto:Shake-dev@geohazards.usgs.gov" class="">Shake-dev@geohazards.usgs.gov</a><br class=""><a href="https://geohazards.usgs.gov/mailman/listinfo/shake-dev" class="">https://geohazards.usgs.gov/mailman/listinfo/shake-dev</a><br class=""></blockquote></div><br class=""></div></div></div>_______________________________________________
Shake-dev mailing list
<a href="mailto:Shake-dev@geohazards.usgs.gov" class="">Shake-dev@geohazards.usgs.gov</a>
<a href="https://geohazards.usgs.gov/mailman/listinfo/shake-dev" class="">https://geohazards.usgs.gov/mailman/listinfo/shake-dev</a>
</blockquote></span></div>
</div></blockquote></div><br class=""></div><div>
<div style="border-top: solid 1px black; border-bottom: solid 1px black;
padding: 10px 0; margin: 20px 0; font-size: 8pt;
font-family: Verdana, Arial, Helvetica, sans-serif;">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.<br></div>
</div>
</body></html>