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