[Shake-dev] developing new GMPE module for ShakeMap v3.5
Bruce Worden
cbworden at caltech.edu
Sat Dec 18 21:29:08 UTC 2010
Hi Georgia,
Sorry about the late response. The problem you are having is with your
calls to _makeAmps(). Note that in MA2005 they supply the full
compliment of arguments, but your calls have a truncated list. When
_makeAmps calls siteCorrectList, some of the args are undefined,
resulting in the error you are seeing.
Picking a prototype GMPE module can be tricky. I've implemented most,
but not all, to make some attempt to produce ground motions to the
ShakeMap default Vs30. But some modules don't have native site
corrections, so I cheat a bit and use something related. In other
cases, I use the native correction, but since that correction is
relative to the no-correction value, I have to first remove the SM
default correction and then apply the site-specific correction.
In any event, you do not need to implement a GMPE-native site
correction function. You can do what Youngs97 does, and just refuse to
allow grind to run with -gmpesc or -nativesc. In this case you just
configure your Borcherdt tables to be relative to the base rock type
that your GMPE assumes.
Bruce
On Dec 15, 2010, at 5:57 AM, Georgia Cua wrote:
> Dear Bruce,
>
> I'm trying to code a new GMPE module for our ShakeMap v3.5
> installation in Switzerland. It has the functional form of Cua and
> Heaton (unpublished) constrained with Swiss weak motion data and NGA
> strong motion data, and should be valid in the magnitude range 2 <=
> M <= 8.
>
> I have written the new module (SwissNGA.pm) based on Small.pm
> (because it uses Rjb as a distance measure) and MA2005.pm (because
> it does not have a GMPE-spefic site amplification approach, and
> should thus use the Hazus module).
>
> Essentially the new module is Small.pm with a few lines/subroutines
> replaced with portions of MA2005.pm (from Constructor, and
> subroutines siteCorrectGrd, siteCorrectList), and of course,
> changing the calculation of the regression equation.
>
> In theory, should this result in a working module, or is the basic
> approach flawed?
>
> I have installed the new module and tried running it on a scenario
> event (just event information, no PGM observations), resulting in
> the following error
>
> shake at phantom:~/opt/shakemap/bin$ ./shake -event newtest -verbose
> shake: Running: '/rdsk/projects/shake/opt/shakemap-3.5-vanilla/
> bin/../bin/grind -event newtest -qtm -lonspan 5.5 -boundcheck -xml -
> lonspan 5.5 -psa'
> grind: Predictive map: no data in '/rdsk/projects/shake/opt/
> shakemap-3.5-vanilla/bin/../data/newtest/input'
> grind: Using fixed boundary 5.6 45.6 10.8 47.8
> grind: 47.8:45.6:10.8:5.6
> grind:
>
> arg <lons> must be an array ref at /rdsk/projects/shake/opt/
> shakemap-3.5-vanilla/bin/../perl/lib/Shake/GMPE/SwissNGA.pm line 306
> shake: Error in grind: 65280
>
> Is the approach of basing the new module primarily on Small.pm (with
> portions from MA2005.pm) a valid approach, or are there some
> subtleties that I am completely bulldozing over? Do you have any
> more detailed documentation/instructions for writing new modules?
>
> Sorry if this is not the type of question to be sending to the
> developer list!
>
> Thanks,
> Georgia
>
> PS. the new module SwissNGA.pm is attached
>
> <SwissNGA.pm><ATT00001.html>
> _______________________________________________
> Shake-dev mailing list
> Shake-dev at geohazards.usgs.gov
> https://geohazards.usgs.gov/mailman/listinfo/shake-dev
More information about the Shake-dev
mailing list