CyberShake MareNostrum Training - Revision history

Scottcal: /* Videos */

2024-01-19T05:33:53Z

Videos

Scottcal: /* Videos */

2024-01-19T05:33:37Z

Videos

Scottcal: /* Check DB */

2020-04-30T14:19:44Z

Check DB

Scottcal: /* Initialize database with run information */

2020-04-28T19:57:22Z

Initialize database with run information

Scottcal: /* Videos */

2020-04-22T21:05:05Z

Videos

Scottcal: /* Velocity Models */

2020-04-21T21:18:51Z

Velocity Models

Scottcal: /* Velocity Models */

2020-04-21T21:18:33Z

Velocity Models

Scottcal: /* Extending CyberShake */

2020-04-21T19:47:44Z

Extending CyberShake

Scottcal: /* Extending CyberShake */

2020-04-21T16:17:41Z

Extending CyberShake

Scottcal: /* Extending CyberShake */

2020-04-21T16:04:01Z

Extending CyberShake

← Older revision		Revision as of 05:33, 19 January 2024
Line 4:		Line 4:

	Recordings from the live training sessions are available below:		Recordings from the live training sessions are available below:
−

	[https://g-c662a6.a78b8.36fe.data.globus.org/cybershake/training/Ch1_Full_2020-02-14T08_02.mp4 February 2, 2020 (1:04, 157 MB)]. Covers the overview, database, and jobs involved in SGT creation.		[https://g-c662a6.a78b8.36fe.data.globus.org/cybershake/training/Ch1_Full_2020-02-14T08_02.mp4 February 2, 2020 (1:04, 157 MB)]. Covers the overview, database, and jobs involved in SGT creation.

@@ Line 5: / Line 5: @@
 Recordings from the live training sessions are available below:
-[http://hypocenter.usc.edu/research/cybershake/BSC/Part2_2020-04-22.mp4 April 22, 2020 (1:12, 405 MB)].  Covers the post-processing jobs, data products jobs, and how to extend CyberShake to include new models.
+[https://g-c662a6.a78b8.36fe.data.globus.org/cybershake/training/Ch1_Full_2020-02-14T08_02.mp4 February 2, 2020 (1:04, 157 MB)].  Covers the overview, database, and jobs involved in SGT creation.
 == Training overview ==

@@ Line 317: / Line 317: @@
 <ol>
-<li><b>Copy over my helper script</b> from /gpfs/scratch/pr1ejg00/pr1ejg10/TEST/db_check.sh .</li>
+<li><b>Copy over my helper script</b> from /gpfs/scratch/pr1ejg00/pr1ejg10/TEST/check_db.sh .</li>
 <li><b>Edit the script.</b>  You'll need to change both the sqlite file it points to, and also the run id (the -r argument).</li>

@@ Line 115: / Line 115: @@
 sqlite> select * from Rupture_Variation_Scenario_IDs;
 |36|genslip-v3.3.1b|Graves & Pitarka (2014) with uniform grid down dip hypocenter location, modified rupture variation constant
-insert into CyberShake_Runs(Site_ID, ERF_ID, SGT_Variation_ID, Velocity_Model_ID, Rup_Var_Scenario_ID, Status, Status_Time, Last_User, Max_Frequency, Low_Frequency_Cutoff, SGT_Source_Filter_Frequency) values (1, 36, 1, 1, 1, "SGT Started", "2020-02-14 12:00:00", "<username>", 0.5, 0.5, 1.0)
+insert into CyberShake_Runs(Site_ID, ERF_ID, SGT_Variation_ID, Velocity_Model_ID, Rup_Var_Scenario_ID, Status, Status_Time, Last_User, Max_Frequency, Low_Frequency_Cutoff, SGT_Source_Filter_Frequency) values (1, 36, 1, 1, 1, "SGT Started", "2020-02-14 12:00:00", "<username>", 0.5, 0.5, 1.0);
 </pre>

@@ Line 5: / Line 5: @@
 Recordings from the live training sessions are available below:
-[http://hypocenter.usc.edu/research/cybershake/BSC/Ch1_Full_2020-02-14T08_02.mp4 February 2, 2020 (1:04, 157 MB)]
+[http://hypocenter.usc.edu/research/cybershake/BSC/Ch1_Full_2020-02-14T08_02.mp4 February 2, 2020 (1:04, 157 MB)].  Covers the overview, database, and jobs involved in SGT creation.
 == Training overview ==

@@ Line 464: / Line 464: @@
 <li>Create a new execution stage which can replace UCVM.  For a simple model, this is easier than integrating it into UCVM.  Some things to keep in mind:
 <ul>
-<li>The generated mesh should be in [[CyberShake_Code_Base#AWP_format AWP format]] to interface with the SGT code.</li>
+<li>The generated mesh should be in [[CyberShake_Code_Base#AWP_format | AWP format]] to interface with the SGT code.</li>
 <li>If only one model is being used, the smoothing stage can be skipped.</li>
 <li>If not guaranteed, the mesh should be post-processed to verify that all Vs values are above the minimum (and if adjustments are necessary, that Vp and rho are scaled).</li>

← Older revision		Revision as of 21:18, 21 April 2020
Line 457:		Line 457:

	=== Velocity Models ===		=== Velocity Models ===
		+
		+	There are two main approaches to adding new velocity models.
		+
		+	<ul>
		+	<li>Register a new model into UCVM. This requires multiple manual steps, and should be done in coordination with the SCEC software group.</li>
		+	<li>Create a new execution stage which can replace UCVM. For a simple model, this is easier than integrating it into UCVM. Some things to keep in mind:
		+	<ul>
		+	<li>The generated mesh should be in [[CyberShake_Code_Base#AWP_format AWP format]] to interface with the SGT code.</li>
		+	<li>If only one model is being used, the smoothing stage can be skipped.</li>
		+	<li>If not guaranteed, the mesh should be post-processed to verify that all Vs values are above the minimum (and if adjustments are necessary, that Vp and rho are scaled).</li>
		+	<li>For all points in the mesh, Vp/Vs >= 1.45 for numerical convergence.</li>
		+	</ul>
		+	</li>
		+	</ul>
		+
		+	With either approach, be sure to <b>add the new velocity model into the Velocity_Models table</b>.

@@ Line 438: / Line 438: @@
 #Both rupture geometries and slip time histories are provided.  The rupture generator is bypassed, and each individual slip time history is used to produce a seismogram.
-From our conversations, I believe the plan is to use approach #1, so I will outline the steps involved there.
+From our conversations, I believe the plan is to use approach #1, so I will outline the steps involved there in setting up the database.
 <ol>
 <li><b>If using a new GP generator, create a rupture variation scenario entry in the Rupture_Variation_Scenario_IDs table.</b>  This is used to track what version and parameters of the GP rupture generator code are used, since the same ERF could be used with multiple rupture variations.  You will need to specify a name and a description.</li>
 <li><b>If using a new GP generator, add any necessary metadata to the Rupture_Variation_Scenario_Metadata.</b>  This is useful for verification and reproducibility.</li>
 <li><b>Add new entries to the Rupture_Variations table.</b>  This table is used by CyberShake to determine which rupture variations go with a given ERF, rupture variation scenario, source, and rupture.  Every rupture variation for a given ERF and scenario will have a unique (source id, rupture id, rupture variation id) tuple.  You should also include the Rup_Var_LFN, which stands for 'Logical File Name', and should be something unique -- for example, 'e36_rv6_128_1.txt.variation-r000000' for ERF 36, rupture variation scenario id 6, source 128, rupture 1, rupture variation 0.  Including the hypocenter locations is optional.</li>
 </ol>

← Older revision		Revision as of 16:17, 21 April 2020
Line 439:		Line 439:

	From our conversations, I believe the plan is to use approach #1, so I will outline the steps involved there.		From our conversations, I believe the plan is to use approach #1, so I will outline the steps involved there.
		+
		+	<ol>
		+	<li>Add new entries to the database.
		+	<ol>
		+	<li><b>If using a new GP generator, create a rupture variation scenario entry in the Rupture_Variation_Scenario_IDs table.</b> This is used to track what version and parameters of the GP rupture generator code are used, since the same ERF could be used with multiple rupture variations. You will need to specify a name and a description.</li>
		+	<li><b>If using a new GP generator, add any necessary metadata to the Rupture_Variation_Scenario_Metadata.</b> This is useful for verification and reproducibility.</li>
		+	<li><b>Add new entries to the Rupture_Variations table.</b> This table is used by CyberShake to determine which rupture variations go with a given ERF, rupture variation scenario, source, and rupture. Every rupture variation for a given ERF and scenario will have a unique (source id, rupture id, rupture variation id) tuple. You should also include the Rup_Var_LFN, which stands for 'Logical File Name', and should be something unique -- for example, 'e36_rv6_128_1.txt.variation-r000000' for ERF 36, rupture variation scenario id 6, source 128, rupture 1, rupture variation 0. Including the hypocenter locations is optional.</li>
		+	</ol>
		+	</li>
		+	</ol>

	=== Sites ===		=== Sites ===

@@ Line 408: / Line 408: @@
 Adding a new earthquake rupture forecast require several different modifications.
-==== Ruptures ===
+==== Ruptures ====
 First, you should add information for the new ruptures (the fault surfaces).  This consists of both database additions and the creation of rupture geometry files.
@@ Line 432: / Line 432: @@
 </ol>
-=== Rupture Variations ===
+==== Rupture Variations ====
 === Sites ===