BBP CyberShake 2015 - Revision history

Maechlin: Redirected page to CyberShake Study 15.12

2016-02-08T00:48:31Z

Redirected page to CyberShake Study 15.12

Maechlin at 00:47, 8 February 2016

2016-02-08T00:47:11Z

Maechlin at 00:46, 8 February 2016

2016-02-08T00:46:24Z

Maechlin at 22:04, 17 August 2015

2015-08-17T22:04:15Z

Maechlin at 21:55, 17 August 2015

2015-08-17T21:55:04Z

Maechlin at 00:00, 16 August 2015

2015-08-16T00:00:45Z

Maechlin at 20:45, 14 August 2015

2015-08-14T20:45:54Z

Maechlin: /* BBP CyberShake Schematic 2009 */

2015-08-14T20:45:30Z

BBP CyberShake Schematic 2009

Maechlin at 20:45, 14 August 2015

2015-08-14T20:45:22Z

Maechlin at 20:44, 14 August 2015

2015-08-14T20:44:57Z

← Older revision		Revision as of 00:48, 8 February 2016
Line 1:		Line 1:
−	[[CyberShake Study 15.12]]	+	#redirect[[CyberShake Study 15.12]]
	== Compuational Goal ==		== Compuational Goal ==

@@ Line 1: / Line 1: @@
-[[CyberShake Study 15.10]]
+[[CyberShake Study 15.12]]
 == Compuational Goal ==
 We are working on doing a series of broadband CyberShake runs, extending the 1 Hz deterministic results we generated in the spring with stochastic results from high-frequency implementation on the BBP.

← Older revision		Revision as of 00:46, 8 February 2016
Line 1:		Line 1:
−	== Compuational Goal ==	+	[[CyberShake Study 15.10]]
		+	1== Compuational Goal ==

	We are working on doing a series of broadband CyberShake runs, extending the 1 Hz deterministic results we generated in the spring with stochastic results from high-frequency implementation on the BBP.		We are working on doing a series of broadband CyberShake runs, extending the 1 Hz deterministic results we generated in the spring with stochastic results from high-frequency implementation on the BBP.

@@ Line 8: / Line 8: @@
 #Select the model based on the CyberShake site, and use the same model for all ruptures on that site.
 #Select the model based on the rupture, and use the same model for all sites which include that rupture.
 == Computational Details ==

← Older revision		Revision as of 21:55, 17 August 2015
Line 1:		Line 1:
		+	== Compuational Goal ==
		+
		+	We are working on doing a series of broadband CyberShake runs, extending the 1 Hz deterministic results we generated in the spring with stochastic results from high-frequency implementation on the BBP.
		+
		+	Before we setup the calculation, we evaluate questions about the 1D velocity model needed for the high frequency results. It seems like there are three ways we could handle this in the context of CyberShake:
		+
		+	#Use the same model (LA Basin?) for all CyberShake sites and all ruptures.
		+	#Select the model based on the CyberShake site, and use the same model for all ruptures on that site.
		+	#Select the model based on the rupture, and use the same model for all sites which include that rupture.
		+
	== Computational Details ==		== Computational Details ==

@@ Line 1: / Line 1: @@
 == Computational Details ==
-We have a copy of BBP installed on Blue Waters;  the two codes are in /u/sciteam/scottcal/scratch/bbp/15.3.0/bbp/src/gp/WccFormat/Progs .
+A copy of BBP v15.4 is installed on Blue Waters; /u/sciteam/scottcal/scratch/bbp/15.3.0/bbp/src/gp/WccFormat/Progs
-Alternatively, if you have a recent version of the BBP installed, you should be able to find it in your install under <version#>/bbp/src/gp/WccFormat/Progs .It sounds like it would probably be best to use the current version of the code, though, and then just run the site response for all events.
+In the recent BBP install, find it under <version#>/bbp/src/gp/WccFormat/Pros
-We checked with David Gill, and the version of CVM-S4.26 we used for CyberShake Study 15.4 does include the GTL, with a 500 m/s minimum cutoff.  It sounds like it would be better to extract Vs30 values from it rather than Wills.  Should we apply the 500 m/s cutoff to the Vs30 values we pass to site response like we did with CyberShake, or use them as-is?
+We confirmed the version of CVM-S4.26 used for CyberShake Study 15.4 does include the GTL, with a 500 m/s minimum cutoff.  It sounds like it would be better to extract Vs30 values from it rather than Wills.  Should we apply the 500 m/s cutoff to the Vs30 values we pass to site response like we did with CyberShake, or use them as-is?
-Site response module: wcc_siteamp.  I'm not sure what is the difference btw the 2 versions on the BBP.  Can you point me to where the source codes are (or send them to me) and I'll take a look?
+Site response module: wcc_siteamp.  The current version of the code uses site amplification factors based on the 2014 NGA GMPEs. Check to see if that is on the BBP.  This version is not formally validated this version (e.g. by redoing the GP2010 validations).Need to make sure to run some compatibility checks just to make sure the results looked OK.
   Should we only do it if the Vs30 for the site is below 600-700 m/s.
-Actually, I would recommend just applying the modification to all sites without worrying about the specific Vs30.  For sites that have Vs30 greater than about 600-700 the modification will be very minor.  But the extra overhead in running the code for all sites is probably insignificant relative to the (equally trivial) overhead in checking the sites for an arbitrary Vs30 threshold
+Apply the modification to all sites without worrying about the specific Vs30.  For sites that have Vs30 greater than about 600-700 the modification will be very minor.  But the extra overhead in running the code for all sites is probably insignificant relative to the (equally trivial) overhead in checking the sites for an arbitrary Vs30 threshold and having different processing streams based on this.
   Related question - in 2011 we pulled the Vs30 values from Wills.  Is that still correct, or should we use Vs30 from the velocity model we used for the CyberShake deterministic (CVM-S4.26)?
-There are some concerns about the near-surface velocity values in the CVM used for the previous calcualtions, in particular, very high Vs for rock sites, and that is why we used Wills  I'm not sure what is in CVM-S4.26, does it include the "geotechnical layer"?  If so, then its probably best to use these values, so that the LF and HF portions are consistent.
+There are some concerns about the near-surface velocity values in the CVM used for the previous calcualtions, in particular, very high Vs for rock sites, and that is why we used Wills  In CVM-S4.26, does it include the "geotechnical layer"?  If so, then its probably best to use these values, so that the LF and HF portions are consistent.
   Program Name: wcc_siteamp14.c
@@ Line 26: / Line 23: @@
 Check to see if this parameter was set previously. (i.e., as model=<something> either in a parfile or on the command line)
-Regarding the question of whether we should we apply the 500 m/s cutoff to the Vs30 values we pass to site response like we did with CyberShake, or use them as-is?
+Regarding the question of whether we should we apply the 500 m/s cutoff to the Vs30 values we pass to site response like we did with CyberShake, or use them as-is? Current decision is to use them as is.  There will be an apparent disconnect with the 500 m/s cutoff at some sites, although the the 500 m/s value with a 100 meter grid spacing is an adequate approximation for the LF calculation.
 == Priority CyberShake Sites of Interest ==

@@ Line 41: / Line 41: @@
 == BBP CyberShake Schematic 2009 ==
 *[http://scec.usc.edu/scecwiki/images/4/4a/HF_Schematic.png Schematic]
 == Related Entries ==

← Older revision		Revision as of 20:45, 14 August 2015
Line 39:		Line 39:
	*LADP - another rock site, near fault		*LADP - another rock site, near fault

		+	== BBP CyberShake Schematic 2009 ==
	*[http://scec.usc.edu/scecwiki/images/4/4a/HF_Schematic.png Schematic]		*[http://scec.usc.edu/scecwiki/images/4/4a/HF_Schematic.png Schematic]