[Shake-dev] Updated Release 3.5

[Bruce Worden]

Jack,

Thanks for your input. My experience over a lot of events is that when  
the bias hits reasonably wide stops (e.g., +/- 2 (remember, these are  
magnitude units now)), something pathological is going on. Either the  
magnitude or origin is associated with the wrong data, an out-of- 
network event is given the wrong origin or magnitude, an event is  
split and the associations are screwed up, etc. Setting the bias to  
zero in these cases is essentially saying that the bias didn't work,  
and we're not going to try to second guess the network's magnitude and  
location. The purpose of the bias is to adjust the GMPE for inter- 
event variance, not to overcome an epic fail on the part of the  
network. If the network gets it wrong, ShakeMap is going to be wrong  
no matter what you do. Once the fix is made, you either re-run or  
cancel the ShakeMap.

But you are correct, it would be possible to end up with a bias of  
-1.95 for PGA and 0.0 for PGV. This is probably more likely with PSA  
than PGM, but it could occasionally happen. If you trust the bias  
mechanism and the data more than the network's magnitude and location,  
you can set your bias stops at some huge value (+/- 10, for example)  
and you'll rarely trigger the limits. (grind will internally enforce a  
limit of 1 <= magnitude + bias <= 10, and set the bias to zero if this  
range is exceeded, but I could change that behavior if you want to  
propose something better.)

I believe Pete has rerun most NC events with 3.5 -- you could have a  
look at the situations where grind hit the bias stops and see what  
sort of circumstances obtained. That might help guide our development  
and operational strategies. But my guess, based on the SCSN events  
I've run, is that you won't find many examples. It is usually a  
transient phenomenon that the network fixes shortly after the event.

Bruce


On Aug 11, 2010, at 11:13 AM, Jack Boatwright wrote:

> Bruce,
>
> You say "When computing bias in grind, if the bias hits bias_(max| 
> min)_bias, the bias is now set to zero, rather than the min/max.  
> This is safer."
>
> What do you mean by "safer?"  By setting the bias to zero, it  
> appears that you are increasing the disagreement between the average  
> GM data and the bias-adjusted GMPE.  Is it safer because you suspect  
> there is a glitch in the data that ShakeMap missed?  I would argue  
> that the present data stream (at least in northern California) is  
> actually very glitch-free, and that you are exhibiting excessive GM  
> data mistrust.
>
> In addition, the PGV and PGA biases are strongly correlated, so that  
> often a limited bias in one will be accompanied by a near-limit bias  
> in the other, and your "safer" solution will more strongly split the  
> biases for the two parameters.
>
> 		take care,          Jack
>
> At 5:12 PM -0700 8/10/10, Bruce Worden wrote:
>> Hi Folks,
>>
>> I've updated the release code with a number of bug fixes and  
>> enhancements.
>>
>> o iiscale, which was the subject of a previous update, now prints  
>> the name of the operative GMICE with the scale; also, the Wald99  
>> relation used a hard-wired set of PGM values that were not entirely  
>> correct--the new version gives somewhat different PGM ranges for  
>> each intensity value, and they are now consistent with the way  
>> Wald99 works. I've also improved the documentation for iiscale in  
>> the Software Guide.
>>
>> o Gabe Plank at UNR has found that "gm" from GraphicsMagick makes  
>> better-looking text on Linux systems than does "convert" from  
>> ImageMagick. I've updated genex and genex.conf to allow the use of  
>> gm, and updated the Software Guide to reflect this option. Linux  
>> users may wish to try this out.
>>
>> o When computing bias in grind, if the bias hits bias_(max| 
>> min)_bias, the bias is now set to zero, rather than the min/max.  
>> This is safer.
>>
>> o Fix timezone bug reported by Gabe Plank.
>>
>> o Removed -gsm as a default flag to mapping in shake.conf. GSM  
>> folks, take notice.
>>
>> o Removed the various obsolete programs to retrieve CIIM data from  
>> retrieve.conf. If you want to use CIIM data, add the correct  
>> program "getdyfi" to retrieve.conf.
>>
>> o Other minor fixes and documentation updates.
>>
>> As always, please let me know if you run into any problems.
>>
>> Bruce
>>
>> _______________________________________________
>> Shake-dev mailing list
>> Shake-dev at geohazards.usgs.gov
>> https://geohazards.usgs.gov/mailman/listinfo/shake-dev
>