SCECpedia - User contributions [en]

File:MUSCAL region extent.png

2026-04-27T21:05:18Z

Scottcal:

UCVM muscal

2026-04-27T21:01:47Z

Scottcal: /* Delivered Model */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H v15.1.1</li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H v15.1.1</li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Below is a list of local high-resolution models that were evaluated for inclusion.

Northern and Central California:
<ul>
<li>Ridgecrest regional (Li and Ben-Zion (2024))</li>
<li>Ridgecrest fault zone (Zhou et al. (2022))</li>
<li>San Joaquin basin (Shaw & Plesch (2016))</li>
<li>SFCVM v21.1 (Hirakawa & Aagaard (2022))</li>
</ul>

Southern California:
<ul>
<li>San Jacinto fault zone (Fang et al. (2019))</li>
<li>San Gabriel-San Bernardino Basin (Li et al. (2023))</li>
<li>Imperial Valley (Persaud et al. (2016))</li>
<li>Coachella Valley (Ajala et al. (2019))</li>
<li>Santa Maria Basin (Plesch et al. (2020))</li>
</ul>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model in grid points are 1251 (lat) x 1301 (lon) x 210 (depth). Grid points have a spacing of 0.01 degrees in the horizontal; the depth is variable with denser sampling near the surface. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

{|
| [[File:MUSCAL_region_extent.png|thumb|400px]]
|}

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

UCVM muscal

2026-04-27T21:01:21Z

Scottcal: /* Delivered Model */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H v15.1.1</li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H v15.1.1</li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Below is a list of local high-resolution models that were evaluated for inclusion.

Northern and Central California:
<ul>
<li>Ridgecrest regional (Li and Ben-Zion (2024))</li>
<li>Ridgecrest fault zone (Zhou et al. (2022))</li>
<li>San Joaquin basin (Shaw & Plesch (2016))</li>
<li>SFCVM v21.1 (Hirakawa & Aagaard (2022))</li>
</ul>

Southern California:
<ul>
<li>San Jacinto fault zone (Fang et al. (2019))</li>
<li>San Gabriel-San Bernardino Basin (Li et al. (2023))</li>
<li>Imperial Valley (Persaud et al. (2016))</li>
<li>Coachella Valley (Ajala et al. (2019))</li>
<li>Santa Maria Basin (Plesch et al. (2020))</li>
</ul>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model in grid points are 1251 (lat) x 1301 (lon) x 210 (depth). Grid points have a spacing of 0.01 degrees in the horizontal; the depth is variable with denser sampling near the surface. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

{|
| [File:MUSCAL_region_extent.png|thumb|400px]
|}

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

UCVM muscal

2026-04-27T20:47:12Z

Scottcal: /* Regional Models */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H v15.1.1</li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H v15.1.1</li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Below is a list of local high-resolution models that were evaluated for inclusion.

Northern and Central California:
<ul>
<li>Ridgecrest regional (Li and Ben-Zion (2024))</li>
<li>Ridgecrest fault zone (Zhou et al. (2022))</li>
<li>San Joaquin basin (Shaw & Plesch (2016))</li>
<li>SFCVM v21.1 (Hirakawa & Aagaard (2022))</li>
</ul>

Southern California:
<ul>
<li>San Jacinto fault zone (Fang et al. (2019))</li>
<li>San Gabriel-San Bernardino Basin (Li et al. (2023))</li>
<li>Imperial Valley (Persaud et al. (2016))</li>
<li>Coachella Valley (Ajala et al. (2019))</li>
<li>Santa Maria Basin (Plesch et al. (2020))</li>
</ul>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

UCVM muscal

2026-04-27T20:46:05Z

Scottcal: /* Local Models */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Below is a list of local high-resolution models that were evaluated for inclusion.

Northern and Central California:
<ul>
<li>Ridgecrest regional (Li and Ben-Zion (2024))</li>
<li>Ridgecrest fault zone (Zhou et al. (2022))</li>
<li>San Joaquin basin (Shaw & Plesch (2016))</li>
<li>SFCVM v21.1 (Hirakawa & Aagaard (2022))</li>
</ul>

Southern California:
<ul>
<li>San Jacinto fault zone (Fang et al. (2019))</li>
<li>San Gabriel-San Bernardino Basin (Li et al. (2023))</li>
<li>Imperial Valley (Persaud et al. (2016))</li>
<li>Coachella Valley (Ajala et al. (2019))</li>
<li>Santa Maria Basin (Plesch et al. (2020))</li>
</ul>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

UCVM muscal

2026-04-27T20:43:27Z

Scottcal:

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Below is a list of local high-resolution models that were evaluated for inclusion.

Northern and Central California:
<ul>
<li>Ridgecrest regional (Li and Ben-Zion (2024))</li>
<li>Ridgecrest fault zone (Zhou et al. (2022))</li>
<li>San Joaquin basin (Shaw & Plesch (2016))</li>
<li>SFVM (Hirakawa & Aagaard (2022))</li>
</ul>

Southern California:
<ul>
<li>San Jacinto fault zone (Fang et al. (2019))</li>
<li>San Gabriel-San Bernardino Basin (Li et al. (2023))</li>
<li>Imperial Valley (Persaud et al. (2016))</li>
<li>Coachella Valley (Ajala et al. (2019))</li>
<li>Santa Maria Basin (Plesch et al. (2020))</li>
</ul>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

UCVM muscal

2026-04-24T22:06:15Z

Scottcal: /* Extended Model */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Local high-resolution models that were evaluated for inclusion are:
<list>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

To solve this in a consistent and reproducible way, we will extend the MUSCAL model through UCVM. The initial plan is to use the following algorithm:
<ol>
<li>Query 3D MUSCAL model at a given point.</li>
<li>If the model returns NaNs (indicating the point is beyond the bounds of the 3D model):
<ol>
<li>Query the 1D MUSCAL model (Te-Yang to provide this).</li>
<li>Determine Vs30 from the USGS Global Vs30 model.</li>
<li>Apply the Ely taper (LVT) to the top 300m.</li>
</ol>
</li>
</ol>

File:USC muscal horiz slice z0.png

2026-04-24T22:04:34Z

Scottcal:

UCVM muscal

2026-04-24T22:04:13Z

Scottcal:

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Local high-resolution models that were evaluated for inclusion are:
<list>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is interpolated using trilinear interpolation.

Details about the model creation are provided in the paper and the [https://zenodo.org/records/19243477 Zenodo page].

Below is a plot of the 3D model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitude:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

== Extended Model ==

The 3D MUSCAL model is defined over the same volume as the CANVAS base model. However, some simulation regions may extend beyond the boundaries, like the blue corners in the example CyberShake volume for USC below:

{|
| [[File:USC_muscal_horiz_slice_z0.png|thumb|400px]]
|}

UCVM muscal

2026-04-24T21:08:59Z

Scottcal: /* Model Components */

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model). Next, regional and local models are added where they improve the fit, based on M4 simulations. These simulations were run to 1 Hz with topography using a minimum Vs of 450 m/s. Finally, a spatially varying taper following the Ely approach is added.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Local high-resolution models that were evaluated for inclusion are:
<list>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is intended to be interpolated using trilinear interpolation.

Details about the model creation are provided in <paper>.

Below is a plot of the model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

UCVM muscal

2026-04-24T18:14:07Z

Scottcal:

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== Model overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Model Components ===

The model was built by starting with a base model (the CANVAS (Doody et al., 2023) tomography model) and then adding regional and local models where they improve the fit, based on M4 simulations.

==== Regional Models ====

Regional models evaluated for inclusion are:
<ul>
<li>Northern California
<ul>
<li>Lin et al. (2010)</li>
<li>Furlong et al. (2024)</li>
<li>Guo et al. (2024)</li>
</ul></li>
<li>Central California
<ul>
<li>CCA-06</li>
<li>CVM-H <what version?></li>
<li>CVM-S4.26</li>
<li>Guo et al. (2024)</li>
<li>Berg et al. (2021)</li>
</ul></li>
<li>Southern California
<ul>
<li>Fang et al. (2022)</li>
<li>CVM-S4.26</li>
<li>CVM-H <what version?></li>
<li>Berg et al. (2021)</li>
</ul></li>
</ul>

==== Local Models ====

Local high-resolution models that were evaluated for inclusion are:
<list>

==== Taper ====

MUSCAL includes a low-velocity taper using the Ely-Jordan approach. Vs30 for this method is produced by merging the Thompson (2018) Vs30 map with the [https://earthquake.usgs.gov/data/vs30/ USGS global Vs30 dataset].

The depth of the taper varies depending on the site and ranges from 300m to 1500m.

== Delivered Model ==

The final version of MUSCAL is delivered in netCDF format. The dimensions of the model are <X x Y x Z>. Grid points have a spacing of <m>. The model is intended to be interpolated using trilinear interpolation.

Details about the model creation are provided in <paper>.

Below is a plot of the model extent.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

Callaghan Presentations

2026-04-22T04:17:55Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2026 ==
*SSA CyberShake presentaiton: [[:File:2026_SSA_CyberShake_presentation.pptx | PPTX]], [[:File:2026_SSA_CyberShake_presentation.pdf | PDF]]

== 2025 ==
*SC25 presentation at OSU booth: [[File:AWP_presentation_for_OSU_booth.pptx | PPTX]]
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

File:2026 SSA CyberShake presentation.pptx

2026-04-22T04:17:41Z

Scottcal:

File:2026 SSA CyberShake presentation.pdf

2026-04-22T04:16:19Z

Scottcal:

Callaghan Presentations

2026-04-22T04:15:30Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2026 ==
*SSA CyberShake presentaiton: [[File:2026_SSA_CyberShake_presentation.pptx | PPTX]], [[File:2026_SSA_CyberShake_presentation.pdf | PDF]]

== 2025 ==
*SC25 presentation at OSU booth: [[File:AWP_presentation_for_OSU_booth.pptx | PPTX]]
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

File:AWP presentation for OSU booth.pptx

2026-04-09T21:36:57Z

Scottcal:

Callaghan Presentations

2026-04-09T21:32:50Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*SC25 presentation at OSU booth: [[File:AWP_presentation_for_OSU_booth.pptx | PPTX]]
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

Callaghan Presentations

2026-04-09T21:30:45Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*SC25 presentation at OSU booth: [[:File:AWP_presentation_for_OSU_booth.pptx | PPTX]]
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

UCVM muscal

2026-04-02T16:00:32Z

Scottcal:

This page describes the Multi-Scale CALifornia (MUSCAL) velocity model and its integration into UCVM.

== MUSCAL overview ==

The MUSCAL Vp and Vs model was created by Te-Yang Yeh and Yehuda Ben-Zion in 2025-6 by starting with the CANVAS tomography model as a base and then integrating multiple regional and local high-resolution models. Each submodel is evaluated to determine where it improves the fit through simulations of M4 historical events to 1 Hz, and then the overall model is updated where the submodel improves the fit.

=== Datasets ===

zone: 11

command use:
plot_depth_profile.py -n $UCVM_INSTALL_PATH/conf/ucvm.conf -i $UCVM_INSTALL_PATH -d vs -c muscal
-o muscal_small_depth_1000.png -C 'Multi-Scale Statewide California Velocity Model'
-v 1000 -b 0 -s 36.5054,-119.0587 -e 30000

==== big data in netcdf ====

model_MSCAL_CANVAS_dll0.01_dz50_cmpd.nc
4.5G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:671 from 0 to 100,000
50 increments until 30,000
1000 increments til 100000

Plot Depth profile at 36.5054,-119.0587 in different step increments. No interpretation and access data using nc api

{|
| [[FILE:muscal_big_deth_50.png|thumb|300px|muscal big 50 vs]]
| [[FILE:muscal_big_deth_100.png|thumb|300px|muscal big 100 vs]]
| [[FILE:muscal_big_depth_500.png|thumb|300px|muscal big 500 vs]]
| [[FILE:muscal_big_deth_1000.png|thumb|300px|muscal big 1000 vs]]
|}

[[FILE:muscal_big_depth-50_matprops.json.txt]]
[[FILE:muscal_big_depth-100_matprops.json.txt]]
[[FILE:muscal_big_depth-500_matprops.json.txt]]
[[FILE:muscal_big_depth-1000_matprops.json.txt]]

==== small data in netcdf ====
model_MUSCAL_CANVAS_dll0.01_vardz_cmpd.nc
2.1G

longitdue:1301 from -126 to -113
latitude:1251 from 31 to 43.5
depth:210 from 0 to 99,000
50 increments upto 3000
100 increments upto 5000
250 increments upto 10000
500 increments upto 30000
1000 increments upto 99000

Depth profiles in different steps : 50m,100m,500m,1000m

Direct from netcdf as external file

{|
|[[FILE:muscal_small_depth_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_deth_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_depth_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_deth_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_depth-50_matprops.json.txt]]
[[FILE:muscal_small_depth-100_matprops.json.txt]]
[[FILE:muscal_small_depth-500_matprops.json.txt]]
[[FILE:muscal_small_depth-1000_matprops.json.txt]]

Loaded in-memory as binary data no interpolation

{|
|[[FILE:muscal_small_no_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_no_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_no_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_no_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_no_interp-50_matprops.json.txt]]
[[FILE:muscal_small_no_interp-100_matprops.json.txt]]
[[FILE:muscal_small_no_interp-500_matprops.json.txt]]
[[FILE:muscal_small_no_interp-1000_matprops.json.txt]]

==== Another small dataset in netcdf ====

model_MUSCAL_CANVAS_dll0.01_vardz_float32_cmpd.nc
1.4G

All longitude, latitude, and depth points are now saved as float32, as well as the vp, vs, and rho.

Loaded in-memory as binary data with interpolation

{|
|[[FILE:muscal_small_interp_50.png|thumb|300px|muscal small 50 vs]]
|[[FILE:muscal_small_interp_100.png|thumb|300px|muscal small 100 vs]]
|[[FILE:muscal_small_interp_500.png|thumb|300px|muscal small 500 vs]]
|[[FILE:muscal_small_interp_1000.png|thumb|300px|muscal small 1000 vs]]
|}

[[FILE:muscal_small_interp-50_matprops.json.txt]]
[[FILE:muscal_small_interp-100_matprops.json.txt]]
[[FILE:muscal_small_interp-500_matprops.json.txt]]
[[FILE:muscal_small_interp-1000_matprops.json.txt]]

=== Validation ===

Several steps of pre/post processing are done to original MUSCAL model(netcdf format) in order to
incorporate it into UCVM and CVM explorer.

Because of the speed of netcdf-C code is too slow to support in-time nature of the explorer and would
like to have interpolation on query,

* Number of depth layer is reduced with deeper layers merged into fewer layers
* preprocessing the netcdf data into binary data files
* data are all in float32

[[FILE:MUSCAL_test_points_deep.txt]]
[[FILE:MUSCAL_test_points_shallow.txt]]

Final result from ucvm_query, (with interpolation)

[[FILE:MUSCAL_test_points_deep.final.txt]]
[[FILE:MUSCAL_test_points_shallow.final.txt]]

Visualizing AWP-ODC Output

2026-02-23T22:15:28Z

Scottcal:

This page documents a procedure to visualize AWP-ODC velocity output, using remote Paraview. So far, this procedure has only been tested on Titan using Paraview 4.4.0.

== Configure the simulation ==

When running the AWP-ODC simulation, make sure it is configured to produce velocity output.

Take note of the following parameters:
*NX, NY, NZ (and NBGX, NEDX, NGBY, NEDY, NGBZ, NEDZ if specified)
*WRITE_STEP
*NSKPX, NSKPY, NSKPZ
*NTISKP

They'll be needed when producing the output.

== Create a Paraview XDMF file ==

Once the simulation is complete, we must create a configuration file which tells Paraview how the velocity data is laid out in memory.

For this, run the script [https://github.com/SCECcode/cybershake-core/blob/main/Utils/visualizer/create_timeseries_file.py create_timeseries_file.py].
<pre>
Usage: ./create_timeseries_file.py <X dim in output> <Y dim in output> <grid decimation> <NT in sim> <DT of sim> <NTISKP> <timesteps output per file> <prefix> <output file>
</pre>

Based on this, a XDMF (XML) file is produced which can serve as input to Paraview.

== Create traces ==

Often, other visual references are needed to make the visualization meaningful. The approach outlined uses a Cartesian grid projection to display the velocity results. This means that to display other data, we have to convert the data from (lat, lon) into (X index, Y index).

To do this, use the code get_grid_values.c, in https://github.com/SCECcode/cybershake-core/blob/main/PreCVM/GenGrid_py/src/get_grid_values.c . It takes a path to a gridfile generated from PreCVM; the modellat, modellon, and modelrot; an input CSV file in lat,lon format; a path to the output file; the grid spacing; and the xshift and yshift from the model_params file. geoproj should always be set to 1, which is Rob's great circle projection. Here's a sample invocation:

<pre>
./get_grid_values gridfile=gridfile_fwd modellat=35.70115 modellon=-119.75587 modelrot=-30.0 infile=CA_trace.csv outfile=ca_trace_grid.csv grid_spacing_km=0.1 xshift=-149.95001 yshift=-134.95001 geoproj=1
</pre>

The directory https://github.com/SCECcode/cybershake-core/blob/main/Utils/visualizer/ contains trace files for California, CCA, USGS, and cvms4/cvms4.26/cvms5 models in lat,lon format, ready for use with get_grid_values.

== Use local Paraview to connect to remote nodes ==

The easiest way to visualize the data is to leave it on the remote system, and use the client/server functionality of Paraview. In this mode, Paraview connects to a remote system and uses the remote cluster to drive the rendering.

Follow the instructions at [https://www.olcf.ornl.gov/tutorials/running-paraview-on-titan/ Titan's Paraview guide], under "Interactive Mode", to create a connection.

== Load datasets ==

Once the job starts on Titan, you can begin loading data.

=== Velocity data ===

To load velocity data, go to File->Open and select the XDMF file you previously made. It will appear in the 'Pipeline Browser' window in the upper left. You may need to click on the eye next to it to get it to display. Additionally, the data is rendered on the Y/Z plane (there is a reason I had to set it up this way, but now I forget why), so click on the '-X' icon to the right of the Slice pull-down in the toolbar. You should see the rectangle defined by your simulation region. You can change the timestep you're looking at by changing the value in the text box to the right of "Time:".

=== Traces ===

Loading traces is more involved. For each trace:

#Go to File->Open and select the .csv trace file you created earlier. The .csv file should appear in the Pipeline Browser window on the left.
#On the Properties tab below the Pipeline Browser, de-select 'Have Headers' and click 'Apply'. A spreadsheet will appear.
#Go to Filters->Alphabetical->Table to Points. This will open a new filter, below your .csv file in the Pipeline Browser.
#In the Properties tab, change the Y Column pull-down to "Field 1", and the Z column pull-down to "Field 2". Click "Apply". You have now converted the .csv into a series of points. You can close the spreadsheet. If you click on the eye next to 'TableToPoints1' in the Pipeline Browser, you will see your outline appear, but as a series of points. We will next convert it to line segments.
#Go to Filters->Alphabetical->Programmable Filter. This filter allows you to write your own VTK code, in Python, to do whatever you like. We will write code which will convert the series of points into line segments.
#Copy and paste the following into the 'Script' section of the Properties tab:
pdi = self.GetPolyDataInput()
pdo = self.GetPolyDataOutput()
numPoints = pdi.GetNumberOfPoints()
pdo.Allocate()
for i in range(0, numPoints-1):
points = [i, i+1]
pdo.InsertNextCell(3,2,points)
#Click 'Apply'. It may take a moment, depending on how many points you have. You should now see the outline of the object. If you don't, try toggling the eye.
#To change the color of the object, click on "ProgrammableFilter1", scroll down in the Properties tab, and under Coloring click the Edit button and pick a new color. You can also change the Line Width in the Styling section.

Repeat this until all your traces have been loaded.

== Modify visuals ==

You may need to make additional modifications to your plot to make it look as you like.

=== Add timestamp ===

To display the timestamp on the plot, go to Filters->Temporal->Annotate Time Filter. Click 'Apply' in the Properties tab to make it appear. You can click and drag it on the Layout to move it around. If you want to show fewer decimal places, change the 'Format' section in the Properties tab.

=== Change plot colors ===

I'm not sure how the default plot colors are selected, but they're usually not symmetric around 0 which isn't what we want.

To change the colors, click on the XDMF file in the Pipeline Browser. The Color Map Editor will appear on the right side.

#Change the max and min to be symmetric around 0. To determine what the max and min should be:
##Select a timestep about 10% of the way through the simulation.
##Click on the Information tab (next to the Properties tab). It will show you what the Data Range is for velocity, an easy way to figure out how extreme your values are.
##I usually select a max and min about 10% of the global max and min. I find this gives a good balance between too much saturation and not losing the small values, but you may prefer other settings.
#Click on the 'Rescale to Custom Data Range' button. It's 2 buttons to the left of the pull-down that says 'X Velocity, with what looks like an arrow with a C. Set your new max and min.
#If you want to change the color scheme, click on the 'Choose Preset' button in the Color Map Editor on the right. It's the one with a heart on it. Select a new color scheme.
#If you want to alter how quickly the color changes from neutral to red or blue, you can click on the horizontal bar (not the triangle part, that controls opacity) to add new reference points. Then, you can edit the 'Color transfer function values' table to set new R,G,and B values for it.

=== Edit color legend ===

If you want to alter the color legend, click on the 'Edit Color Legend Parameters' button, near the top right of the Color Map Editor. It's the button with an 'e' on it.

== Save state ==

Before starting your animation, save a state file. That way, if there are any issues, you don't have to reload everything again. Go to File->Save State.

In the future, you should reconnect before you try to load it. It may take 15-20 seconds to load once you confirm the file paths.

== Create series of snapshots ==

The way that Paraview creates animations is by creating a series of snapshots, which you can then render into a movie. To save a series of snapshots, go to File->Save Animation. Check over the Animation Settings. Note that you can set a custom Timestep range, so if you aren't able to finish rendering the snapshots in the length of your Titan job, you can resume from where you left off.

'''If the connection terminates in the middle, or your local machine goes to sleep, you may end up with rendered frames in which the content wasn't updated. Check your last frames to be sure they have the correct timestamp.'''

I think the speed of rendering is a function of your internet connection, the number of remote nodes, and the image size. It typically takes me 90-120 minutes to render a 2000-timestep animation at ~1280x800. I use PNG files.

== Create movie ==

On Linux, you can use ffmpeg to string together the PNGs to create a movie, with a command like:
ffmpeg -framerate <fps> -i fileprefix.%04d.png <output movie.mp4>

Callaghan Presentations

2026-02-09T21:55:07Z

Scottcal: /* 2025 */

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*SC25 presentation at OSU booth:
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

CyberShake UCERF2 ERF

2026-01-09T06:30:42Z

Scottcal: Created page with "All CyberShake studies through Study 24.8 utilize an earthquake rupture forecast (ERF) derived from UCERF2. Some details about the construction of this ERF for CyberShake are..."

All CyberShake studies through Study 24.8 utilize an earthquake rupture forecast (ERF) derived from UCERF2. Some details about the construction of this ERF for CyberShake are described below.

== Event Types ==

There are three types of events given by the UCERF2 ERF: regular, median, and aleatory.

=== Regular ===
Regular events represent floating sources in UCERF2, about 85% of all events in CyberShake.
<ol>
<li> Compute target Magnitude Frequency Distribution (MFD) for each source as a Gutenberg-Richter (G-R) distribution up to maximum magnitude determined by two Mw-Area scaling relationships (Ellsworth-B; Hanks and Bakun, 2007). The G-R b-value depends on the fault type: b=0 for type A faults (e.g., the San Andreas), and the average of G-R distributions with b=0 and b=0.8 are used for type B faults. Then average the MFD from the two scaling relationships, which is discretized in 0.1 magnitude bins (i.e., UCERF2 magnitude) to determine the final source MFD.</li>
<li> Extend the down-dip width (DDW) of the fault to match the Somerville (2006) area for a full-fault rupture at the maximum magnitude. (CyberShake-only, not done for standard UCERF2)</li>
<li> For each magnitude bin, compute the rupture area with Somerville 2006 (or, for standard UCERF2, Hanks and Bakun, 2007).</li>
<li> Build N floating ruptures with that area.</li>
<li> Set rate of each rupture to G-R rate for magnitude divided by N (equal weight to each rupture for that magnitude bin).</li>
</ol>

=== Median ===
Median events represent the characteristic sources in UCERF2, whose rupture areas are modified to match the Somerville (2006) scaling relationship, which represent ~2% of events in CyberShake.
<ol>
<li>For each branch on UCERF2 logic tree (Ellsworth-B; Hanks and Bakun, 2007), compute median magnitude from area with given scaling relationship, discretized into 0.1 magnitude bins (i.e., UCERF2 magnitude)</li>
<li>For each source:
<ol>
<li>compute implied area from Somerville 2006 from UCERF2 magnitude</li>
<li>compute DDW correction factor as ratio of implied area to original UCERF2 (U2) area, intended to be: ddwCorrFactor = som06Area / origU2Area 
Note that there is a bug in the UCERF2 implementation such that ddwCorrFactor = som06Area / ellBArea (rather than origU2Area). This resulted in a constant ddwCorrFactor = 1.65959 for characteristic sources (this bug does not affect floating regular sources).</li>
<li>extend DDW such that the new rupture area equals the implied Somerville 2006 area: newDDW = origDDW * ddwCorrFactor (to the nearest integer) 
Note: what this does, holding magnitude constant, is extend the area such that if you were to use Somerville 2006 to compute magnitude it would equal the input UCERF2 magnitude.</li>
</ol>
</li>
</ol>

=== Aleatory ===
Aleatory events have the same rupture areas of Median events, but with varying magnitudes to capture the variations in magnitude-area relationship, which represent ~13% of events in CyberShake.
<ol>
<li>For each Median source, compute the total moment rate</li>
<li>compute moment balanced Gaussian aleatory magnitude distribution with sigma=0.12, two sided truncation at 2 sigma 
Note: this means that the resultant moment rate from this distribution will equal the moment rate from Median (1)</li>
<li>Compute magnitude discretized in 0.1 magnitude bins 
Note: the largest magnitudes in CyberShake are aleatory events that have very large stress drops, which can lead to very high seismic hazard at long return periods.</li>
</ol>

Summary: Both Regular and Median types follow the Somerville 2006 scaling relationship, hence have the same estimated stress drop values. Aleatory events, on the other hand, have a large range of stress drop values.

CyberShake Rupture Files

2025-12-22T20:49:50Z

Scottcal:

CyberShake uses rupture files to provide descriptions of rupture geometry, and, in some cases, slip information about individual events to be simulated. A description of these files is below.

== UCERF2 files ==

To date, all CyberShake simulations have been performed using UCERF 2 events. These events can include both a rupture geometry file and a Standard Rupture Format (SRF) description of the event itself.

=== UCERF2 Rupture Geometry Files ===

Rupture geometry files contain a list of all the points which appear on the surface of the rupture. This information is needed to determine which SGTs should be saved (so that we have an SGT for each point on every rupture surface), and to generate a rupture variation when passed into the RupGen-api code. We can also use the rupture geometry to generate the list of points we need SGTs for when doing post-processing. Since 2014, we have tried to replace the SRF with the rupture geometry whenever possible, as it is a much smaller file and therefore reduces I/O.

The format of the rupture geometry files is:

Probability = <prob>
Magnitude = <mag>
GridSpacing = <spacing between elements, in km>
NumRows = <# rows>
NumCols = <# cols>
# Lat Lon Depth Rake Dip Strike
<data for (row 0,col 0)>
<data for (row 0,col 1)>
...
<data for (row 0,col c)>
<data for (row 1,col 0)>
...
<data for (row r,col c)>

A 'row' is defined as a set of rupture points all at the same depth, and rows are listed in the file from shallowest to deepest.

For ERF 35, we used 1 km spacing; this should be used with 0.5 Hz simulations. For ERF 36, we used 200 m spacing; this should be used with 1 Hz simulations.

These files are stored in <CyberShake root>/ruptures/Ruptures_erf<ERF ID>/<src ID>/<rup ID>/<src>_<rup>.txt. The path to the top-level ruptures directory is specified in [[CyberShake_Code_Base#Configuration_file | cybershake.cfg]], and the substructure is assumed in the [[CyberShake_Code_Base#PreSGT | PreSgt]] code.

The geometry files for ERF 36 are available here: [https://g-3a9041.a78b8.36fe.data.globus.org/cybershake/ruptures_erf36.tgz ERF 36](4.1 GB)

=== Rupture Variation files ===

Initially, we precomputed rupture variations for all events and saved these to disk. This was done for the Graves & Pitarka (2006) (Rupture Variation Scenario ID 3) and Graves & Pitarka (2010) (Rup Var Scenario ID 4). These SRFs can be found on SCEC disks at /home/rcf-104/CyberShake2007/ruptures/RuptureVariations_35_V2_3 (Rup Var Scenario ID 3) and /home/rcf-104/CyberShake2007/ruptures/RuptureVariations_35_V3_2 (Rup Var Scenario ID 4), using the same <src id>/<rup id> directory hierarchy as the rupture geometry files.

Starting in 2012, we stopped writing out all the SRFs. Instead, they are generated on-demand in memory during the post-processing. However, these files can still be generated by calling the _write_srf() function in genslip. They follow the SRF format; version 1 is documented [http://hypocenter.usc.edu/research/cybershake/srf4.pdf here] and version 2 [http://hypocenter.usc.edu/research/cybershake/SRF-Description-Graves_2.0.pdf here].

== RSQSim files ==

As part of a new effort for 2018, we are proposing to generate CyberShake curves using ruptures generated from RSQSim.

=== RSQSim Rupture Geometry files ===

Rupture geometry files generate from RSQSim ruptures have a different header, as the rupture points are on a tetrahedral grid instead of an evenly spaced rectangular one, and so GridSpacing, NumRows, and NumCols don't really translate. Instead, the file format is:

<pre>
Probability = 5.325298E-6
Magnitude = 7.305054
AveArea = <average area of fault element>
NumPoints = <total number of points>
# Lat Lon Depth Rake Dip Strike
<data for point 0>
<data for point 1>
...
<data for point P>
</pre>

No order should be assumed for the points.

These files will use the same directory structure (<CyberShake root>/ruptures/Ruptures_erf<ERF ID>/<src ID>/<rup ID>/<src>_<rup>.txt).

=== RSQSim SRFs ===

RSQSim SRFs are in version 1 format. The optional "PLANE" section is omitted, since planes don't really map well to RSQSim faults.

CyberShake Study Database Archiving

2025-12-13T00:17:20Z

Scottcal:

== SQLite Archiving ==

The following procedure should be used when we want to archive a study to SQLite which is either in the production or data access database to disk, to free up room in the database.

First, dump the old database contents into a new directory by running the following commands.

Note that if you don't want to lock the tables, you can replace '--lock-all-tables' with '--single-transaction=TRUE' in the following commands.

You can add --no-create-info if you don't want the create statement for the table at the beginning of the dump file.

<ol>
<li>Determine the Study ID you want to archive, from looking at the Studies table in the DB:</li>
select * from Studies;
<li>Dump the PeakAmplitudes, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Run_ID in (select R.Run_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake PeakAmplitudes > peak_amps.sql
<li>Dump Hazard_Datasets, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake Hazard_Datasets > hazard_datasets.sql
<li>Dump Hazard_Curves, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Hazard_Dataset_ID in (select D.Hazard_Dataset_ID from Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curves > hazard_curves.sql
<li>Dump Hazard_Curve_Points, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Hazard_Curve_ID in (select C.Hazard_Curve_ID from Hazard_Curves C, Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curve_Points > hazard_curve_points.sql
<li>Dump CyberShake_Runs, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake CyberShake_Runs > runs.sql
<li>You now need the rest of the input tables. They used to be pretty small, but now they're up to ~70GB with indices. As of the completion of Study 22.12, here are their approximate sizes (in the DB, not as dump files):
{| border="1"
! Table !! Size (GB)
|-
| AR_Hazard_Curve_Points || 44.6
|-
| CyberShake_Site_Ruptures || 10.3
|-
| Ruptures || 2.3
|-
| Rupture_Variations || 2.6
|-
| AR_Hazard_Curves || 1.4
|-
| Other tables || 0.5
|}
You can either:
<ul>
<li>Dump all of the input tables -- they are small enough that we don't mind capturing data which wasn't directly used in this study.</li>
mysqldump --skip-add-drop-table -u cybershk -p CyberShake AR_Hazard_Curve_Points AR_Hazard_Curves AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Ruptures CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Points Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rupture_Variations Ruptures Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
<li>Dump only the sections of the large input tables that you need. Note that the Points table isn't used anymore, so don't bother to dump it.
<ol>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'AR_Hazard_Curve_ID in (select distinct C.AR_Hazard_Curve_ID from AR_Hazard_Curves C where C.AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) )' CyberShake AR_Hazard_Curve_Points > ar_hazard_curve_points.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'CS_Site_ID in (select R.Site_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake CyberShake_Site_Ruptures > cs_site_ruptures.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Ruptures > ruptures.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where '(Rup_Var_Scenario_ID, ERF_ID) in (select R.Rup_Var_Scenario_ID, R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Rupture_Variations > rupture_variations.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID)' CyberShake AR_Hazard_Curves > ar_hazard_curves.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p CyberShake AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
</ol>
</ul>

</ol>

Next, convert the SQL dumps into SQLite format using mysql2sqlite:

#For each of the dump files, run:
mysql2sqlite <SQL dump file> > <SQLite dump file>
Example: ./mysql2sqlite peak_amps.sql > peak_amps.sqlite
For large tables this may take an hour or two.

Create a SQLite database and import the tables. Use sqlite3 3.7.11 or later, or there will be an error reading the dump files. If you get errors about too many entries, upgrade to a more recent version and try again.
<ol>
<li>Create a database for this study:</li>
sqlite3 <study name>
<li>For each dump file, run the following command:</li>
.read <path/to/dump/file.sqlite>
</ol>

Run a few queries on the original table on the database, and on the sqlite files to check that the count is the same.
<ol>
<li>Check the number of PeakAmplitudes:</li>
select count(*) from PeakAmplitudes P, CyberShake_Runs R where R.Study_ID=<study_id> and P.Run_ID=R.Run_ID;
<li>Check the number of rupture variations for each site:</li>
select count(*) from CyberShake_Runs R, CyberShake_Site_Ruptures SR, Rupture_Variations V where R.Site_ID=SR.CS_Site_ID and SR.Source_ID=V.Source_ID and SR.Rupture_ID=V.Rupture_ID and R.ERF_ID=V.ERF_ID and R.ERF_ID=SR.ERF_ID and V.Rup_Var_Scenario_ID=R.Rup_Var_Scenario_ID and R.Study_ID=<study id>;
</ol>

Create index on Run_ID and IM_Type_ID in PeakAmplitudes table to speed up access.
<ol>
<li>Copy over the original version to a new file.</li>
<li>Set the SQLITE_TMPDIR variable to point to a filesystem with lots of free space.</li>
<li>Using a current version of sqlite3, open the new database file and run:</li>
CREATE INDEX "idx_PeakAmplitudes_Run_ID_IM_Type_ID" ON "PeakAmplitudes" (`Run_ID`, `IM_Type_ID`);
</ol>

Move the files to the archive location on project.
<ol>
<li>Tar up the sqlite files:</li>
tar czvf <study_name>.tgz *.sqlite
<li>SFTP the tgz file to the study sqlite archive location on project at CARC (/project/scec_608/cybershake/results/sqlite_studies/<study name>), using hpc-transfer1.</li>
<li>Extract the database to /project/scec_608/cybershake/results/sqlite_studies/<study_name> .</li>
tar xzvf sqlite_dumps/<study_name>.tgz <study_name>.sqlite
</ol>

== Move study to from production DB to data access DB ==

CyberShake Code Base

2025-11-26T19:57:56Z

Scottcal: /* DirectSynth */

This page details all the pieces of code which make up the CyberShake code base, as of November 2017. Note that this does not include the workflow middleware, or the workflow generators; that code is detailed at [[CyberShake Workflow Framework]].

Conceptually, we can divide up the CyberShake codes into three categories:

#Strain Green Tensor-related codes: These codes produce the input files needed to generate SGTs, actually calculate the SGTs, and do some reformatting and sanity checks on the results.
#Synthesis-related codes: These codes take the SGTs and perform seismogram synthesis and intensity measure calculations.
#Data product codes: These codes insert the results into the database, and use the database to generate a variety of output data products.

Below is a description of each piece of software we use, organized by these categories. For each piece of software, we include a description of where it is located, how to compile and use it, and what its inputs and outputs are. At the end, we provide a description of input and output files and formats.

== Code Installation ==

Historically, we have selected a root directory for CyberShake, then created the subdirectories 'software' for all the code, 'ruptures' for the rupture files, 'logs' for log files, and 'utils' for workflow tools. This is typically set up in unpurged storage space, so once installed purging isn't a worry. Each code listed below, along with the configuration file, should be checked out into the 'software' subdirectory.

In terms of compilers, you should use the GNU compilers unless specifically directed otherwise.

Most of the codes below contain a main directory. Inside that is a bin directory, with binaries; a src directory with code requiring compilation; and wrappers, in the main directory.

If you are looking for compilation instructions, a general guide is available [[CyberShake compilation guide | here]].

=== Configuration file ===

Many CyberShake codes use a configuration file, which specifies the root directory for the CyberShake installation, the command use to start an MPI executable, paths to a tmp and scratch space (which can be the same), and the path to the CyberShake rupture directory. We have done this instead of environment variables because it's more transparent and easier for multiple users. Both of these files should be stored in the 'software' subdirectory.

The configuration file is available at:
https://github.com/SCECcode/cybershake-core/cybershake.cfg
Obviously, this file must be edited to be correct for the install.

The keys that CyberShake currently expects to find are:
*CS_PATH = /path/to/CyberShake/software/directory
*SCRATCH_PATH = /path/to/shared/scratch
*TMP_PATH = /path/to/tmp (can be node-local, or shared with scratch
*RUPTURE_PATH = /path/to/CyberShake/rupture/directory
*MPI_CMD = ibrun or aprun or mpiexec
*LOG_PATH = /path/to/CyberShake/logs/directory

To interact with cybershake.cfg, the CyberShake codes use a Python script to deliver cybershake.cfg entries as key-value pairs, located here:
https://github.com/SCECcode/cybershake-core/config.py
Several CyberShake codes import config, then use it to read out the cybershake.cfg file.

=== Compiler file ===

A long time ago, Gideon Juve created a compiler file, Compilers.mk, which contains information about which compilers should be used for which system. This file should also be downloaded using 'svn export' and installed in the software directory, from
https://github.com/SCECcode/cybershake-core/Compilers.mk

Some of the makefiles reference this file. This can - and should - be updated to reflect new systems.

== SGT-related codes ==

[[File:SGT_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the SGT part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_SGT_workflow.odg source file (ODG)]]]

=== PreCVM ===

This code stands for "Pre-Community-Velocity-Model". It has to be run before the UCVM codes, since it generates input files required by UCVM.

Purpose: To determine the simulation volume for a particular CyberShake site.

Detailed description: PreCVM queries the CyberShake database to determine all of the ruptures which fall within a given cutoff for a certain site. From that information, padding is added around the edges to construct the CyberShake simulation volume for this site. Additional padding so the X and Y dimensions are multiples of 10, 20, or 40 might also be applied, depending on the input parameters. Using this volume, both the X/Y offset of each grid point, and then the latitude and longitude using a great circle projection, are determined and written to output files.

Needs to be changed if:
#The CyberShake volume depth needs to be changed, so as to have the right number of grid points. That is set in the genGrid() function in GenGrid_py/gen_grid.py, in km.
#X and Y padding needs to be altered. That is set using 'bound_pad' in Modelbox/get_modelbox.py, around line 70.
#The rotation of the simulation volume needs to be changed. That is set using 'model_rot' in Modelbox/get_modelbox.py, around line 70.
#The database access parameters have changed. That's in Modelbox/get_modelbox.py, around line 80.
#The divisibility needs for GPU simulations change (currently, we need the dimensions to be evenly divisible by the number of GPUs used in that dimension. That is in Modelbox/get_modelbox.py, around line 250.

Source code location: https://github.com/SCECcode/cybershake-core/PreCVM/

Author: Rob Graves, wrapped by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
pre_cvm.py
Modelbox/get_modelbox.py
Modelbox/bin/gcproj
GenGrid_py/gen_grid.py
GenGrid_py/bin/gen_model_cords

Compile instructions:Run 'make' in the Modelbox/src and the GenGrid_py/src directories.

Usage:
<pre>Usage: pre_cvm.py [options]
Options:
-h, --help show this help message and exit
--site=SITE Site name
--erf_id=ERF_ID ERF ID
--modelbox=MODELBOX Path to modelbox file (output)
--gridfile=GRIDFILE Path to gridfile (output)
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coorfile (output)
--paramsfile=PARAMSFILE
Path to paramsfile (output)
--boundsfile=BOUNDSFILE
Path to boundsfile (output)
--frequency=FREQUENCY
Frequency
--gpu Use GPU box settings.
--spacing=SPACING Override default spacing with this value.
--server=SERVER Address of server to query in creating modelbox,
default is focal.usc.edu.</pre>

Typical run configuration: Serial; requires 6 minutes for 100m spacing, 10 billion point volume

Input files: None; inputs are retrieved from the database

Output files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridfile|gridfile]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Params|params]], [[CyberShake_Code_Base#Coord|coord]], [[CyberShake_Code_Base#Bounds|bounds]]

=== UCVM ===

Purpose: To generate a populated velocity mesh for a CyberShake simulation volume.

Detailed description: UCVM takes the volume defined by PreCVM and queries the [[UCVM]] software, using the C API, to populate the volume. The resulting mesh is then checked for Vp/Vs ratio, minimum Vp/Vs/rho, and for no Infs or NaNs. The data is outputted in either Graves (RWG) format or AWP format. This code also produces log files, which will be written to the CyberShake logs directory/GenLog/site/v_mpi-<processor number>.log. This can be useful if there's an error and you aren't sure why.

Needs to be changed if:
#New velocity models are added. Velocity models are specified in the DAX and passed through the wrapper scripts into the C code and then ultimately to UCVM, so an if statement must be added to around line 250 (and around line 450 if it's applicable for no GTL).
#The backend UCVM substantially changes. If we move to the Python implementation, for example.
#If additional models are added, new libraries may need to be added to the makefile.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
single_exe.py
single_exe.csh
bin/ucvm-single-mpi

Compile instructions:The makefile needs to be edited so that "UCVM_HOME" points to the UCVM home directory. Then run 'make' in the UCVM/src directory.

Usage:
<pre>All of site, gridout, modelcords, models, and format must be specified.
Usage: single_exe.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coordfile (output)
--models=MODELS Comma-separated string on velocity models to use.
--format=FORMAT Specify awp or rwg format for output.
--frequency=FREQUENCY
Frequency
--spacing=SPACING Override default spacing with this value (km)
--min_vs=MIN_VS Override minimum Vs value. Minimum Vp and minimum
density will be 3.4 times this value.
</pre>

Typical run configuration: Parallel on ~4000 cores; for 10 billion points and the C version of UCVM, takes about 20 minutes. Typically only half the cores per node are used to get more memory per process.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#coords|coords]]

Output files: either [[CyberShake_Code_Base#RWG_format|RWG format]] or [[CyberShake_Code_Base#AWP_format|AWP format]], depending on the option selected.

=== Smoothing ===

Purpose: To smooth a velocity file along model interfaces.

Detailed description: The smoothing code takes in a velocity mesh, determines the surface coordinates of the interfaces between velocity models, gets a list of all the points which need to be smoothed, and then performs the smoothing by averaging in both the X and Y direction for a user-specified number of points (default of 10km in each direction).

Needs to be changed if:
#We change our version of UCVM. The LD_LIBRARY_PATH needs to be modified, in run_smoothing.py around line 98.
#The smoothing algorithm is modified. Currently that is specified in the average_point() function in smooth_mpi.c.
#We start using velocity models with boundaries aren't perpendicular to the earth's surface.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM/smoothing

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
smoothing/run_smoothing.py
bin/determine_surface_model
smoothing/determine_smoothing_points.py
smoothing/smooth_mpi

Compile instructions:Run 'make' in the smoothing directory, and make sure that determine_surface_model has been compiled in the UCVM/src directory. You may need to change the compiler; currently it uses 'cc'.

Usage:
<pre>Usage: run_smoothing.py [options]

Options:
-h, --help show this help message and exit
--gridout=GRIDOUT gridout file
--coords=COORDS coords file
--models=MODELSTRING comma-separated list of velocity models
--smoothing-dist=SMOOTHING_DIST
Number of grid points to smooth over. About 10km of
grid points is a good starting place.
--mesh=MESH AWP-format velocity mesh to smooth
--mesh-out=MESH_OUT Output smoothed mesh
</pre>

Typical run configuration: Parallel on ~1500 cores; for 5 billion points and the C version of UCVM, takes about 16 minutes.

Input files: [[CyberShake_Code_Base#AWP_format|AWP format velocity file]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#AWP_format|AWP format]] smoothed velocity file.

=== PreSGT ===

Purpose: To generate a series of input files which are used by the wave propagation codes.

Detailed description: PreSGT determines the X and Y coordinates of the site location (where the impulse will go for the wave propagation simulation) and determines, which mesh point (X and Y) maps most closely to every point on a fault surface which is within the cutoff. That information is combined with an adaptive mesh approach to create a list of all the points for which SGTs should be saved.

Needs to be changed if:
#We change our approach for saving adaptive mesh points.
#We change the location of the rupture geometry files, currently assumed to be <rupture root>/Ruptures_erf<erf ID> . This is specified in presgt.py, line 167.
#The directory hierarchy and naming scheme for rupture geometry files, currently <src id>/<rup id>/<src id>_<rup_id>.txt, changes. This is specified in faultlist_py/CreateFaultList.py, line 36.
#The number of header lines in the rupture geometry file changes. This would require changing the nheader value, currently 6, specified in faultlist_py/CreateFaultList.py, line 36.
#We switch to RSQSim ruptures, or other ruptures in which the geometry isn't planar. Modifications would be required to gen_sgtgrid.c.

Source code location: https://github.com/SCECcode/cybershake-core/PreSgt

Author: Rob Graves, heavily modified by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#libcfu|libcfu]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
presgt.py
faultlist_py/CreateFaultList.py
bin/gen_sgtgrid

Compile instructions:Run 'make' in the src directory.

Usage:
<pre>Usage: ./presgt.py <site> <erf_id> <modelbox> <gridout> <model_coords> <fdloc> <faultlist> <radiusfile> <sgtcords> <spacing> [frequency]
Example: ./presgt.py USC 33 USC.modelbox gridout_USC model_coords_GC_USC USC.fdloc USC.faultlist USC.radiusfile USC.cordfile 200.0 0.1
</pre>

Typical run configuration: Parallel on 8 nodes, 32 cores (gen_sgtgrid is a parallel code); for 200m spacing UCERF2, takes about 8 minutes.

Input files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#Faultlist|faultlist]], [[CyberShake_Code_Base#Radiusfile|radiusfile]], [[CyberShake_Code_Base#SgtCoords|sgtcoords]].

=== PreAWP ===

Purpose: To generate input files in a format that AWP-ODC expects.

Detailed description: PreAWP performs a number of steps:
#An IN3D parameter file is produced, needed for AWP-ODC.
#A file with the SGT coordinates to save in AWP format is produced. Since RWG and AWP use different coordinate systems, a coordinate transformation (X->Y, Y->X, zero-indexing->one-indexing) is performed on the SGT coordinates file.
#The velocity file in translated to AWP format, if it isn't in AWP format already.
#The correct source, based on the dt and nt, is selected. The source must be generated manually ahead of time. Details about source generation are given [[CyberShake Code Base#Impulse source descriptions | here]].
#Striping for the output file is also set up here.
#Files are symlinked into the directory structure that AWP expects. Note that slightly different versions of this exist for the CPU and GPU implementations of AWP-ODC-SGT.

Needs to be changed if:
#The path to the Lustre striping command (lfs) changes. This path is hard-coded in build_awp_inputs.py, line 14. Note that this is the path to lfs on the compute node, NOT the login node.
#The AWP code changes its input format.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/ (HIP GPU) or https://github.com/SCECcode/cybershake-core/AWP-GPU-SGT/utils/ (CUDA GPU) or https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT/utils/ (CPU), AND also https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: SgtHead

Executable chain:
build_awp_inputs.py
build_IN3D.py
build_src.py
build_cordfile.py
SgtHead/gen_awp_cordfile.py
build_media.py
SgtHead/bin/reformat_velocity

Compile instructions:Run 'make' in the SgtHead/src directory.

Usage:
<pre>Usage: build_awp_inputs.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout input file
--fdloc=FDLOC Path to fdloc input file
--cordfile=CORDFILE Path to cordfile input file
--velocity-prefix=VEL_PREFIX
RWG velocity prefix. If omitted, will not reformat
velocity file, just symlink.
--frequency=FREQUENCY
Frequency of SGT run, 0.5 Hz by default.
--px=PX Number of processors in X-direction.
--py=PY Number of processors in Y-direction.
--pz=PZ Number of processors in Z-direction.
--source-frequency=SOURCE_FREQ
Low-pass filter frequency to use on the source,
default is same frequency as the frequency of the run.
--spacing=SPACING Override default spacing, derived from frequency.
--velocity-mesh=VEL_MESH
Provide path to velocity mesh. If omitted, will
assume mesh is named awp.<site>.media.
</pre>

Typical run configuration: Serial; for 1 Hz run, takes about 11 minutes.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#SgtCoords|cordfile]], velocity mesh (if in [[CyberShake_Code_Base#RWG_format|RWG format]], will be converted to [[CyberShake_Code_Base#AWP_format|AWP]]), [[CyberShake_Code_Base#RWG_source|RWG source]]

Output files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP source|AWP source]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]].

=== AWP-ODC-SGT, CPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the CPU version. It uses the IN3D file for its parameters.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: iobuf module

Executable chain:
awp_odc_wrapper.sh
bin/pmcl3d

Compile instructions:Using the GNU compilers, run 'make' in the src directory.

Usage:
<pre> pmcl3d <IN3D parameter file>
</pre>

Typical run configuration: Parallel; for 0.5 Hz run (2 billion points, 20k timesteps), takes about 45 minutes on 10,000 cores.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== AWP-ODC-SGT, CUDA GPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the GPU version. It takes parameters on the command-line, so the wrapper converts the IN3D file into command-line arguments and invokes it.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: hhttps://github.com/SCECcode/cybershake-core/AWP-GPU-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: CUDA toolkit module

Executable chain:
gpu_wrapper.py
bin/pmcl3d

Compile instructions:modules PrgEnv-gnu and module cudatoolkit must be loaded first. Then, run 'make' in the src directory.

Usage:
<pre>Usage: ./pmcl3d
Options:
[(-T | --TMAX) <TMAX>]
[(-H | --DH) <DH>]
[(-t | --DT) <DT>]
[(-A | --ARBC) <ARBC>]
[(-P | --PHT) <PHT>]
[(-M | --NPC) <NPC>]
[(-D | --ND) <ND>]
[(-S | --NSRC) <NSRC>]
[(-N | --NST) <NST>]

[(-V | --NVE) <NVE>]
[(-B | --MEDIASTART) <MEDIASTART>]
[(-n | --NVAR) <NVAR>]
[(-I | --IFAULT) <IFAULT>]
[(-R | --READ_STEP) <x READ_STEP]

[(-X | --NX) <x length]
[(-Y | --NY) <y length>]
[(-Z | --NZ) <z length]
[(-x | --NPX) <x processors]
[(-y | --NPY) <y processors>]
[(-z | --NPZ) <z processors>]

[(-1 | --NBGX) <starting point to record in X>]
[(-2 | --NEDX) <ending point to record in X>]
[(-3 | --NSKPX) <skipping points to record in X>]
[(-11 | --NBGY) <starting point to record in Y>]
[(-12 | --NEDY) <ending point to record in Y>]
[(-13 | --NSKPY) <skipping points to record in Y>]
[(-21 | --NBGZ) <starting point to record in Z>]
[(-22 | --NEDZ) <ending point to record in Z>]
[(-23 | --NSKPZ) <skipping points to record in Z>]

[(-i | --IDYNA) ]
[(-s | --SoCalQ) <s SoCalQ>]
[(-l | --FL) <l FL>]
[(-h | --FH) ]
[(-p | --FP) ]
[(-r | --NTISKP) <time skipping in writing>]
[(-W | --WRITE_STEP) <time aggregation in writing>]

[(-100 | --INSRC) <source file>]
[(-101 | --INVEL) <mesh file>]
[(-o | --OUT) <output file>]
[(-c | --CHKFILE) <checkpoint file to write statistics>]

[(-G | --IGREEN) <IGREEN for SGT>]
[(-200 | --NTISKP_SGT) <NTISKP for SGT>]
[(-201 | --INSGT) <SGT input file>]
</pre>

Typical run configuration: Parallel; for 1 Hz run (10 billion points, 40k timesteps), takes about 55 minutes on 800 GPUs.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== PostAWP ===

Purpose: To prepare the AWP results for use in post-processing.

Detailed description: PostAWP prepares the outputs of AWP so that they can be used with the RWG-authored post-processing code. Specifically, it undoes the AWP coordinate transformation and reformats the AWP output files into the SGT component order expected by RWG (XX->YY, YY->XX, XZ->-YZ, YZ->-XZ, and all SGTs are doubled if we are calculating the Z-component), creates separate SGT header files, and calculates MD5 sums on the SGT files. Calculating the header information requires a number of input files, since lambda, mu, and the location of the impulse must all be included. The MD5 sums can be calculated separately, using the MD5 wrapper RunMD5sum.

Needs to be changed if:
#The AWP code is modified to produce outputs in exactly RWG order
#The header format for the post-processing code changes
#We decide not to calculate MD5 sums

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/prepare_for_pp.py (this will work for the CPU version of AWP also, despite the path); https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
AWP-GPU-SGT/utils/prepare_for_pp.py
SgtHead/bin/reformat_awp_mpi
SgtHead/bin/write_head

Compile instructions:Run 'make write_head' and 'make reformat_awp_mpi' in the SgtHead/src directory.

Usage:
<pre>Usage: ./prepare_for_pp.py <site> <AWP SGT> <reformatted SGT filename> <modelbox file> <rwg cordfile> <fdloc file> <gridout file> <IN3D file> <AWP media file> <component> <run_id> <header> [frequency]
</pre>

Typical run configuration: Parallel, 4 processors on 2 nodes; for a 750 GB SGT, takes about 100 minutes without the MD5 sums.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#SgtCoords|RWG cordfile]]), [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]

Output files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]], [[CyberShake_Code_Base#SGT header file|SGT header file]]

=== RunMD5sum ===

Purpose: Wrapper for performing MD5sums.

Detailed description: On Titan, we ran into wallclock issues when bundling the MD5sums along with PostAWP. This wrapper supports performing the MD5 sums separately.

Needs to be changed if:
#We change hash algorithms

Source code location: https://github.com/SCECcode/cybershake-core/SgtHead/run_md5sum.sh

Author: Scott Callaghan

Dependencies: none

Executable chain:
run_md5sum.sh

Compile instructions: none

Usage:
<pre>Usage: ./run_md5sum.sh <file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 70 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]]

Output files: MD5sum, with filename <RWG SGT filename>.md5

=== NanCheck ===

Purpose: Check the SGTs for anomalies before the post-processing.

Detailed description: This code checks to be sure the SGTs are the expected size, then checks for NaNs or too many consecutive zeros in the SGT files.

Needs to be changed if:
#We change the number of timesteps in the SGT file. Currently this is hardcoded, but it should be a command-line parameter.
#We want to add additional checks.

Source code location: https://github.com/SCECcode/cybershake-core/SgtTest/

Author: Rob Graves, Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
perform_checks.py
bin/check_for_nans

Compile instructions: Run 'make' in SgtTest/src .

Usage:
<pre>Usage: ./perform_checks.py <SGT file> <SGT header file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 45 minutes.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Sgt Coords|RWG coordinate file]], [[CyberShake_Code_Base#IN3D | IN3D file]]

Output files: none

== PP-related codes ==

The following codes are related to the post-processing part of the workflow.

[[File:PP_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the PP part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_PP_workflow.odg source file (ODG)]]]

=== CheckSgt ===

Purpose: To check the MD5 sums of the SGT files to be sure they match.

Detailed description: CheckSgt takes the SGT files and their corresponding MD5 sums and checks for agreement.

Needs to be changed if:
#We change hashing algorithms.
#We decide to add additional sanity checks to the beginning of the post-processing.

Source code location: https://github.com/SCECcode/cybershake-core/CheckSgt

Author: Scott Callaghan

Dependencies: none

Executable chain:
CheckSgt.py

Compile instructions: none

Usage:
<pre>Usage: ./CheckSgt.py <sgt file> <md5 file>
</pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 90 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], SGT MD5 sums

Output files: None

=== DirectSynth ===

DirectSynth is the code we currently use to perform the post-processing. For historical reasons, all of the codes used for CyberShake post-processing are documented here: [https://scec.usc.edu/it/Post-processing_options CyberShake post-processing options] (login required). The current version uses the [[Rupture_Variation_Generator_v5.5.2|Graves and Pitarka (2022) rupture generator]], RupGen-v5.5.2.

Purpose: To perform reciprocity calculations and produce seismograms, intensity measures, and duration measures.

Detailed description: DirectSynth reads in the SGTs across a group of processes, and hands out tasks (synthesis jobs) to worker processes. These worker processes read in rupture geometry information from disk and call the RupGen-api to generate full slip histories in memory. The workers request SGTs from the reader processes over MPI. X and Y component PSA calculations are performed from the resultant seismograms, and RotD and duration calculations are also performed, if requested. More details about the approach used are available at [[DirectSynth]].

Needs to be changed if:
#We have new intensity measures or other calculations per seismogram to perform.
#We decide to change the post-processing algorithm.
#The wrapper needs to be modified if we want to set different custom environment variables.

Source code location: https://github.com/SCECcode/cybershake-core/DirectSynth

Author: Scott Callaghan, original seismogram synthesis code by Rob Graves, X and Y component PSA code by David Okaya, RotD code by Christine Goulet

Dependencies: [[CyberShake Code Base#Getpar | Getpar]], [[CyberShake Code Base#libcfu | libcfu]], [[CyberShake Code Base#RupGen-api-v5.5.2 | RupGen-api-v5.5.2, [[CyberShake Code Base#FFTW | FFTW]], [[CyberShake Code Base#libmemcached | libmemcached]] (optional) and [[CyberShake Code Base#memcached | memcached]] (optional)

Executable chain:
direct_synth.py
utils/pegasus_wrappers/invoke_memcached.sh
memcached
bin/direct_synth

Compile instructions:
#Compile RupGen-api first.
#Edit the makefile in DirectSynth/src . Check the following variables:
##BASE_DIR should point to the top-level CyberShake install directory
##LIBCFU should point to the libcfu install directory
##CUR_RG_LIB should point to the RupGen-api-<version>/lib directory
##LDLIBS should have the correct paths to the libcfu and libmemcached lib directories
##CUR_RG_INC should point to the RupGen-api-<version>/include directory
##IFLAGS should have the correct paths to the libcfu and libmemcached include directories
#Run 'make direct_synth' in DirectSynth/src.

direct_synth.py has an if statement which, based on the wrapper to MPI on the target system (such as 'mpiexec', 'ibrun', or 'jsrun'), will set up the execution string. You may need to add a new section of the if statement if a new MPI wrapper is used. This is also the place to change the number of cores used per node. You may also need to add hard-coded paths to memcached here.

Usage:
<pre>
direct_synth.py
stat=<site short name>
slat=<site lat>
slon=<site lon>
run_id=<run id>
sgt_handlers=<number of SGT handler processes; must be enough for the SGTs to be read into memory>
debug=<print logs for each process; 1 is yes, 0 no>
max_buf_mb=<buffer size in MB for each worker to use for storing SGT information; 512 recommended>
rupture_spacing=<'uniform' or 'random' hypocenter spacing>
ntout=<nt for seismograms>
dtout=<dt for seismograms>
rup_list_file=<input file containing ruptures to process>
rv_info_file=<input file containing rvfrac and random seed for each rupture variation>
sgt_xfile=<input SGT X file>
sgt_yfile=<input SGT Y file>
sgt_zfile=<optional, input SGT Z file>
x_header=<input SGT X header>
y_header=<input SGT Y header>
z_header=<optional, input SGT Z header>
det_max_freq=<maximum frequency of deterministic part>
stoch_max_freq=<maximum frequency of stochastic part>
run_psa=<'1' to run X and Y component PSA, '0' to not>
run_rotd=<'1' to run RotD calculations, '0' to not>
run_durations=<'1' to run duration calculation, '0' to not>
run_period_durations=<'1' to run period duration calculations, '0' to not>
simulation_out_pointsX=<the number of components: 2 for just horizontal, 3 to include vertical>
simulation_out_pointsY=1
simulation_out_timesamples=<same as ntout>
simulation_out_timeskip=<same as dtout>
surfseis_rspectra_seismogram_units=cmpersec
surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa
surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=<high filter, 5.0 for 1 Hz runs, 20.0 or higher for 10 Hz runs>
surfseis_rspectra_apply_byteswap=no
</pre>

Typical run configuration: Parallel, typically on 3840 processors; for 750 GB SGTs with ~7000 ruptures, takes about 12 hours.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], [[CyberShake_Code_Base#SGT header file|SGT headers]], [[CyberShake_Code_Base#rupture list file|rupture list file]], [[CyberShake_Code_Base#rupture variation info file|rupture variation info file]], [[CyberShake_Rupture_Files|rupture geometry files]]

Output files: [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | Seismograms]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

== Data Product Codes ==

The software in this section takes the data products produced by the SGT and post-processing stages, adds some of it to the database, and creates final data products. Note that all these codes should be installed on a server close to the database, to reduce insertion and query time. Currently these are all installed on SCEC disks and accessed from shock.usc.edu.

[[File:Data_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the data product of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_data_workflow.odg source file (ODG)]]]

=== Load Amps ===

Purpose: Load data from output files into the database.

Detailed description: This code loads either PSA, RotD, or Duration data into the database, depending on command-line options. It also performs sanity checks on the PSA data being inserted: values must be between 0.008 and 8400 cm/s2. If they are less than 0.008, some will still be passed through if it's a small magnitude event at large distances. If this constraint is violated, it will abort. Note that if LoadAmps needs to be rerun, sometimes the database must be cleaned out first, as data from the previous attempt may have inserted successfully and will cause duplicate key errors if you try to insert the same data again.

Needs to be changed if:
#We change the sanity checks on data inserts.
#We modify the format of the PSA, RotD, or Duration files.
#We add new types of data to insert.
#We change the database schema.
#We add a new server. To add a new server, in addition to providing a command-line option for it, you will need to create a Hibernate config file. You can start with moment.cfg.xml or focal.cfg.xml and edit lines 7-16 appropriately.

Source code location: https://github.com/SCECcode/cybershake-core/CyberCommands

Author: Joshua Garcia, Scott Callaghan

Dependencies: LoadAmps calls CyberCommands, a Java code with a long list of dependencies (all of these are checked into the Java project):

*Ant
*Apache Commons
*Hibernate
*MySQL bindings
*Xerces
*DOM4J
*Log4J
*Java 1.6+

Executable chain:
insert_dir.sh
CyberLoadAmps_SC
cybercommands_SC.jar
CyberLoadamps.java

Compile instructions: Check out CyberCommands into Eclipse. Create the cybercommands_SC.jar file using Eclipse's JAR build framework and the cybercommands_SC.jardesc description file. Install cybercommand_SC.jar and the required JAR files on the server. Point insert_dir.sh to CyberLoadAmps_SC to cybercommands_SC.jar.

Usage:
<pre>Usage: CyberLoadAmps [-r | -d | -z | -u][-c] [-d] [-periods periods] [-run RunID] [-p directory] [-server name] [-z] [-help] [-i insertion_values]
[-u] [-f]
-i <insertion_values> Which values to insert -
gm: geometric mean PSA data (default)
xy: X and Y component PSA data
gmxy: Geometric mean and X and Y components
-run <RunID> Run ID - this option is required
-p <directory> file path with spectral acceleration files,
either top-level directory or zip file - this option is required
-server <name> server name (focal, surface, intensity, moment,
or csep-x) - this option is required
-periods <periods> Comma-delimited periods to insert
-c Convert values from g to cm/sec^2
-d Assume one BSA file per rupture, with embedded
header information.
-f Don't apply value checks to insertion values; use
with care!.
-help print this message
-r Read rotd files (instead of bsa.)
-u Read duration files (instead of bsa.)
-z Read zip files instead of bsa.</pre>

Typical run configuration: Serial; for 5 periods, takes about 10 minutes. It's wildly dependent on the database and contention from other database processes.

Input files: [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

Output files: none

=== Check DB Site ===

Purpose: Verify that data was correctly loaded into the database.

Detailed description: This code takes a list of components (or type IDs) to check for a run ID, and verifies that there is one entry for every rupture variation. If some rupture variations are missing, a file is produced which lists the missing source, rupture, rupture variation tuples.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/db/CheckDBDataForSite.java and DBConnect.java

Author: Scott Callaghan (CheckDBDataForSite.java), Nitin Gupta, Vipin Gupta, Phil Maechling (DBConnect.java)

Dependencies: Both are checked into the CyberShake project:

*Apache Commons
*MySQL bindings

Executable chain:
check_db.sh
CheckDBDataForSite.java

Compile instructions: Check out CheckDBDataForSite.java and DBConnect.java. Compile them by running 'javac -classpath mysql-connector-java-5.0.5-bin.jar:commons-cli-1.0.jar DBConnect.java CheckDBDataForSite.java'. The paths to the MySQL bindings jar and the Apache Commons jar may be different depending on your installation.

Usage:
<pre>usage: CheckDBDataForSite
-p <periods> Comma-separated list of periods to check, for geometric
and rotd.
-t <type_ids> Comma-separated list of type IDs to check, for duration.
-c <component> Component type (geometric, rotd, duration) to check.
-h,--help Print help for CheckDBDataForSite
-o <output> Path to output file, if something is missing (required).
-r <run_id> Run ID to check (required).
-s <server> DB server to query against.
</pre>

Typical run configuration: Serial; typically takes just a few seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Missing variations file | Missing variations file]]

=== DB Report ===

Purpose: Produce a database report, a data product which Rob Graves used for a time.

Detailed description: This code takes a run ID, queries the database for PSA values for all components, and writes the output to a text file. The list of periods and the DB config parameters are specified in an XML config file.

Needs to be changed if:
#Username, password, or database host are changed: the DB connection parameters in default.xml would need to be edited.
#We want results for different periods: edit default.xml.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/reports/db_report_gen.py . default.xml in the same directory is also needed, and can be generated by editing and running conf_get.py, also in the same directory.

Author: Kevin Milner

Dependencies: MySQLdb

Executable chain:
db_report_gen.py

Compile instructions: None, all code is Python.

Usage:
<pre>Usage: db_report_gen.py [options] SITE_SHORT_NAME

NOTE: defaults are loaded from defaults.xml and can be edited manually
or overridden with conf_gen.py

Options:
-h, --help show this help message and exit
-e ERF_ID, --erfID=ERF_ID
ERF ID for Report (default = none)
-f FILENAME, --file=FILENAME
Store Results to a file instead of STDOUT. If a
directory is given, a name will be auto generated.
-i, --id Flag for specifying site ID instead of Short Name
(default uses Short Name)
--hypo, --hpyocenter Flag for appending hypocenter locations to result
-l LIMIT, --limit=LIMIT
Limit the total number of rusults, or 0 for no limit
(default = 0)
-o, --sort SLOW: Force SQL Order By statement for sorting. It
will probably come out sorted, but if it doesn't, you
can use this. (default will not sort)
-p PERIODS, --periods=PERIODS
Comma separated period values (default = 3.0,5.0,10.0)
--pr, --print-runs Print run IDs for site and optionally ERF/Rup Var
Scen/SGT Var IDs
-r RUP_VAR_SCENARIO_ID, --rupVarID=RUP_VAR_SCENARIO_ID
Rupture Variation Scenario ID for Report (default =
none)
--ri=RUN_ID, --runID=RUN_ID
Allows you to specify a run ID to use (default uses
latest compatible run ID)
-R RUPTURE, --rupture=RUPTURE
Only give information on specified rupture. Must be
acompanied by -S/--source flag (default shows all
ruptures)
-s SGT_VAR_ID, --sgtVarID=SGT_VAR_ID
SGT Variation ID for Report (default = none)
-S SOURCE, --source=SOURCE
Only give information on specified source. To specify
rupture, see -R option (default shows all sources)
--s_im, --sort-ims Sort output by IM value (increasing)...may be slow!
-v, --verbose Verbosity Flag (default = False)
</pre>

Typical run configuration: Serial; about 1 minute. It's wildly dependent on the database and contention from other database processes.

Input files: default.xml

Output files: [[CyberShake_Code_Base#DB Report file | DB Report file]]

=== Curve Calc ===

Purpose: Calculate CyberShake hazard curves alongside comparison GMPEs.

Detailed description: This code takes a run ID, component, and period, queries the database for the appropriate IM values, and calculates a hazard curve in the desired format. Comparison GMPE curves can also be plotted.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#New IM types need to be supported.

Source code location: The CyberShake curve calculator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.HazardCurvePlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by curve_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/curve_plot_wrapper.sh .

The OpenSHA project also has configuration files for various GMPEs, config files for UCERF2, and configuration files for output formats preferred by Tom and Rob, in src/org/opensha/sha/cybershake/conf.

Author: Kevin Milner

Dependencies: Standard OpenSHA dependencies

Executable chain:
curve_plot_wrapper.sh
HazardCurvePlotter.java

Compile instructions: Use the OpenSHA build process if building from source.

Usage:
<pre>
usage: HazardCurvePlotter [-?] [-af <arg>] [-benchmark] [-c] [-cmp <arg>]
[-comp <arg>] [-cvmvs] [-e <arg>] [-ef <arg>] [-f] [-fvs <arg>] [-h
<arg>] [-imid <arg>] [-imt <arg>] [-n] [-novm] [-o <arg>] [-p
<arg>] [-pf <arg>] [-pl <arg>] [-R <arg>] [-r <arg>] [-s <arg>]
[-sgt <arg>] [-sgtsym] [-t <arg>] [-v <arg>] [-vel <arg>] [-w
<arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship
description file(s) for comparison.
Multiple files should be comma
separated
-benchmark,--benchmark-test-recalc Forces recalculation of hazard
curves to test calculation speed.
Newly recalculated curves are not
kept and the original curves are
plotted.
-c,--calc-only Only calculate and insert the
CyberShake curves, don't make plots.
If a curve already exists, it will
be skipped.
-cmp,--component <arg> Intensity measure component.
Options: GEOM,X,Y,RotD100,RotD50,
Default: GEOM
-comp,--compare-to <arg> Compare to aspecific Run ID (or
multiple IDs, comma separated)
-cvmvs,--cvm-vs30 Option to use Vs30 value from the
velocity model itself in GMPE
calculations rather than, for
example, the Wills 2006 value.
-e,--erf-id <arg> ERF ID
-ef,--erf-file <arg> XML ERF description file for
comparison
-f,--force-add Flag to add curves to db without
prompt
-fvs,--force-vs30 <arg> Option to force the given Vs30 value
to be used in GMPE calculations.
-h,--height <arg> Plot height (default = 500)
-imid,--im-type-id <arg> Intensity measure type ID. If not
supplied, will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-n,--no-add Flag to not automatically calculate
curves not in the database
-novm,--no-vm-colors Disables Velocity Model coloring
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple
periods should be comma separated
(default: 3)
-pf,--password-file <arg> Path to a file that contains the
username and password for inserting
curves into the database. Format
should be "user:pass"
-pl,--plot-chars-file <arg> Specify the path to a plot
characteristics XML file
-R,--run-id <arg> Run ID
-r,--rv-id <arg> Rupture Variation ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-sgtsym,--sgt-colors Enables SGT specific symbols
-t,--type <arg> Plot save type. Options are png,
pdf, jpg, and txt. Multiple types
can be comma separated (default is
pdf)
-v,--vs30 <arg> Specify default Vs30 for sites with
no Vs30 data, or leave blank for
default value. Otherwise, you will
be prompted to enter vs30
interactively if needed.
-vel,--vel-model-id <arg> Velocity Model ID
-w,--width <arg> Plot width (default = 600)
</pre>

Typical run configuration: Serial; about 30 seconds per curve. It's wildly dependent on the database and contention from other database processes.

Input files: ERF config file, GMPE config files

Output files: [[CyberShake_Code_Base#Hazard Curve | Hazard Curve]]

=== Disaggregate ===

Purpose: Disaggregate the curve results to determine the largest contributing sources.

Detailed description: This code takes a run ID, a probability or IM level, and a period to disaggregate at. It produces disaggregation distance-magnitude plots and also a list of the % contribution of each source.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#We want to support different kinds of disaggregation, or for a different kind of ERF.

Source code location: The Disaggregator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.DisaggregationPlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by disagg_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/disagg_plot_wrapper.sh .

Author: Kevin Milner, Nitin Gupta, Vipin Gupta

Dependencies: Standard OpenSHA dependencies

Executable chain:
disagg_plot_wrapper.sh
DisaggregationPlotter.java

Compile instructions: Use the standard OpenSHA building process if building from source.

Usage:
<pre>usage: DisaggregationPlotter [-?] [-af <arg>] [-cmp <arg>] [-e <arg>]
[-fvs <arg>] [-i <arg>] [-imid <arg>] [-imt <arg>] [-o <arg>] [-p
<arg>] [-pr <arg>] [-r <arg>] [-R <arg>] [-s <arg>] [-sgt <arg>]
[-t <arg>] [-vel <arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship description
file(s) for comparison. Multiple files
should be comma separated
-cmp,--component <arg> Intensity measure component. Options:
GEOM,X,Y,RotD100,RotD50, Default: GEOM
-e,--erf-id <arg> ERF ID
-fvs,--force-vs30 <arg> Option to force the given Vs30 value to be
used in GMPE calculations.
-i,--imls <arg> Intensity Measure Levels (IMLs) to
disaggregate at. Multiple IMLs should be
comma separated.
-imid,--im-type-id <arg> Intensity measure type ID. If not supplied,
will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple periods
should be comma separated (default: 3)
-pr,--probs <arg> Probabilities (1 year) to disaggregate at.
Multiple probabilities should be comma
separated.
-r,--rv-id <arg> Rupture Variation ID
-R,--run-id <arg> Run ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-t,--type <arg> Plot save type. Options are png, pdf, and
txt. Multiple types can be comma separated
(default is pdf)
-vel,--vel-model-id <arg> Velocity Model ID
</pre>

Typical run configuration: Serial; typically takes about 30 seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Disaggregation file | Disaggregation file]]

== Stochastic codes ==

With CyberShake, we also have the option to augment a completed run with stochastic seismograms. The following codes are used to add stochastic high-frequency content to an already-completed low-frequency deterministic run.

[[File:stochastic workflow overview.png|thumb|right|300px|Overview of the codes involved in the stochastic part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/stochastic_workflow_overview.odg source file (ODG)]]]

=== Velocity Info ===

Purpose: To determine slowness-averaged VsX values for a CyberShake site, from UCVM.

Detailed description: Velocity Info takes a location, a velocity model, and grid spacing information and queries UCVM to generate three VsX values needed by the site response:
#Vs30, calculated as: 30 / sum( 1 / (Vs sampled from [0.5, 29.5] at 1 meter increments, for 30 values) )
#Vs5H, like Vs30 but calculated over the shallowest 5*gridspacing meters. So if gridspacing=100m, Vs5H = 500 / sum( 1 / (Vs sampled from [0.5, 499.5] at 1 meter increments, for 500 values) )
#VsD5H, like Vs30, but calculated over gridspacing increments, instead of 1 meter. The start and end are weighted half as much. So if gridspacing=100m, VsD5H = 5 / sum( 0 / (Vs sampled from [0, 500] at 1 meter increments, for 500 values) )

Needs to be changed if:
#We need to support more than one model - for instance, if the CyberShake site box (not simulation volume) spans multiple models. The code to parse the model string and load models in initialize_ucvm() would need to be changed.
#We want to support new kinds of velocity values.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/src/retrieve_vs.c

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM | UCVM]]

Executable chain:
retrieve_vs

Compile instructions:Run 'make retrieve_vs'

Usage:
<pre>Usage: ./retrieve_vs <lon> <lat> <model> <gridspacing> <out filename></pre>

Typical run configuration: Serial; takes about 15 seconds.

Input files: None

Output files: [[CyberShake_Code_Base#Velocity_Info file|Velocity Info file]]

=== Local VM ===

Purpose: To generate a "local" 1D velocity file, required for the high-frequency codes.

Detailed description: Local VM takes in an input file containing a 1D velocity model. It then calculates Qs from these values and writes all the velocity data to a new file. For all Study 15.12 runs, we used the LA Basin 1D model from the BBP, v14.3.0. It's registered in the RLS, and is located at /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod.

Needs to be changed if:
#We change the algorithm for calculating Vs.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/gen_local_vel.py

Author: Scott Callaghan, modified from Rob Graves' code

Dependencies: None

Executable chain:
gen_local_vel.py

Compile instructions: None

Usage:

<pre>Usage: ./gen_local_vel.py <1D velocity model> <output></pre>

Typical run configuration: Serial; takes less than a second.

Input files: [[CyberShake_Code_Base#BBP velocity file|BBP 1D velocity file]]

Output files: [[CyberShake_Code_Base#Local VM file|Local VM file]]

=== Create Dirs ===

Purpose: To create a directory for each source.

Detailed description: The high-frequency codes produce many intermediate files. To avoid overloading the filesystem, Create Dirs creates a separate directory for every source.

Needs to be changed if: This code is basically just a wrapper around mkdir, and is unlikely to need changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/create_dirs.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
create_dirs.py

Compile instructions: None

Usage:
<pre>
Usage: ./create_dirs.py <file with list of dirs>
</pre>

Typical run configuration: Serial, takes just a few seconds.

Input files: File with a directory to create (a source ID) on each line.

Output files: None.

=== HF Synth ===

Purpose: HF Synth generates a high-frequency stochastic seismogram for one or more rupture variations.

Detailed description: This code wraps multiple broadband platform codes to reduce the number of invocations required. Specifically, it calls:
#srf2stoch_lite(), a reduced-memory version of srf2stoch. We have modified it to call rupgen_genslip() to generate the SRF, rather than reading it in from disk.
#hfsim(), a wrapper for:
##hb_high(), Rob Graves's original BBP code to produce the seismograms
##wcc_getpeak(), which calculates PGA for the seismogram
##wcc_siteamp14(), which performs site amplification.

Vs30 is required, so if it is not passed as a command-line argument, UCVM is called to determine it.

Additionally, hf_synth_lite is able to handle processing on multiple rupture variations, to further reduce the number of invocations.

Needs to be changed if:
#A new version of one of Rob's codes - the high-frequency generator or the site amplification - is needed. We have tried to use whatever the most recent version is on the BBP, for consistency.
#New velocity parameters are needed for the site amplification.
#The format of the rupture geometry files changes.

The makefile needs to be changed if the path to libmemcached, UCVM, Getpar, or the rupture generator changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem

Author: wrapper by Scott Callaghan, hb_high(), wcc_getpeak(), and wcc_siteamp14() by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
hf_synth_lite

Compile instructions: Run 'make' in src.

Usage: There is no 'help' usage string, but here's a sample invocation:
<pre>
/projects/sciteam/jmz/CyberShake/software/HFSim_mem/bin/hf_synth_lite
stat=OSI slat=34.6145 slon=-118.7235
rup_geom_file=e36_rv6_121_0.txt source_id=121 rupture_id=0
num_rup_vars=5 rup_vars=(0,0,0);(1,1,0);(2,2,0);(3,3,0);(4,4,0)
outfile=121/Seismogram_OSI_4331_121_0_hf_t0.grm
dx=2.0 dy=2.0 tlen=300.0 dt=0.025
do_site_response=1 vs30=359.1 debug=0 vmod=LA_Basin_BBP_14.3.0.local
</pre>

Typical run configuration: Serial; takes a few seconds per rupture variation up to a minute, depending on the size of the fault surface.

Input files: [[CyberShake_Code_Base#Local_VM_file | Local velocity file]], [[CyberShake_Rupture_Files#UCERF2_Rupture_Geometry_Files | rupture geometry file]]

Output files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Combine HF Synth ===

Purpose: This code combines the seismograms produced by HF Synth so that there is just 1 seismogram per source/rupture combo.

Detailed description: Since we split up work so that each HF Synth job takes a chunk of rupture variations, we may end up with multiple seismogram files per rupture, each containing some of the rupture variations. This script concatenates the files, using cat, into a single file, ready to be worked on later in the workflow.

Needs to be changed if: I can't think of a circumstance where we would need to change this.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/combine_seis.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
combine_seis.py
cat

Compile instructions: None

Usage:
<pre>
Usage: ./combine_seis.py <seis 0> <seis 1> ... <seis N> <output seis name>
</pre>

Typical run configuration: Serial; takes a few seconds.

Input files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A single high-frequency seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== LF Site Response ===

Purpose: This code performs site response modifications to the CyberShake low-frequency seismograms.

Detailed description: The LF Site Response code takes a low-frequency seismogram and some velocity parameters, and outputs a seismogram with site response applied. In Study 15.12, this was a necessary step before combining the low and high frequency seismograms together. Since Vs30 is required, if it's not passed as a command-line argument, then UCVM is called to determine it.

The reason we calculate site response for the low-frequency deterministic seismograms is that we want both the low- and high-frequency results to be for the same site-response condition. For the HF, we used Vs30 directly
for the site-response adjustment, but for the LF we had to use an adjusted VsX value since the grid spacing was 100 m (so Vs30 doesn't make sense).

Needs to be changed if:
#We change the site response algorithm.
#We decide to use different velocity parameters for setting site response.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/LF_Site_Response

Author: wrapper by Scott Callaghan, site response by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
lf_site_response

Compile instructions: Edit the makefile to point to RupGen, libmemcached, and Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./lf_site_response
seis_in=Seismogram_OSI_3923_263_3.grm seis_out=263/Seismogram_OSI_3923_263_3_site_response.grm
slat=34.6145 slon=-118.7235
module=cb2014
vs30=359.1 vref=344.7
</pre>

Typical run configuration: Serial; takes less than a second.

Input files: A low-frequency deterministic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A low-frequency deterministic seismogram with site response, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Merge IM ===

Purpose: This code combines low-frequency deterministic and high-frequency stochastic seismograms, then processes them to obtain intensity measures.

Detailed description: The Merge IM code takes an LF and HF seismogram and performs the following processing:
#A high-pass filter is applied to the HF seismogram.
#The LF seismogram is resampled to the same dt as the HF seismogram.
#The two seismograms are combined into a single broadband (BB) seismogram.
#The PSA code is run on the resulting seismogram.
#If desired, the RotD and duration codes are also run on the seismogram.

Merge IM works on a seismogram file at the rupture level, so it assumes that the input files contain multiple rupture variations.

Needs to be changed if:
#We change the filter-and-combine algorithm.
#We decide to modify the post-processing and IM types we want to capture.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/MergeIM

Author: Scott Callaghan, Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]]

Executable chain:
merge_psa

Compile instructions: Edit the makefile to point to Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./merge_psa
lf_seis=182/Seismogram_OSI_3923_182_23_site_response.grm hf_seis=182/Seismogram_OSI_4331_182_23_hf.grm seis_out=182/Seismogram_OSI_4331_182_23_bb.grm
freq=1.0 comps=2 num_rup_vars=16
simulation_out_pointsX=2 simulation_out_pointsY=1
simulation_out_timesamples=12000 simulation_out_timeskip=0.025
surfseis_rspectra_seismogram_units=cmpersec surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=20.0 surfseis_rspectra_apply_byteswap=no
out=182/PeakVals_OSI_4331_182_23_bb.bsa
run_rotd=1 rotd_out=182/RotD_OSI_4331_182_23_bb.rotd
run_duration=1 duration_out=182/Duration_OSI_4331_182_23_bb.dur
</pre>

Typical run configuration: Serial; takes 5-30 seconds, depending on the number of rupture variations in the files.

Input files: LF deterministic seismogram and HF stochastic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: BB seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]]; also [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], and [[Accessing_CyberShake_Duration_Data | Duration files]]

== File types ==

=== Modelbox ===

Purpose: Contains a description of the simulation box, at the surface.

Filename convention: <site>.modelbox

Format:
<pre>
<site name>
APPROXIMATE CENTROID:
clon= <centroid lon> clat =<centroid lat>
MODEL PARAMETERS:
mlon= <model lon> mlat =<model lat> mrot=<model rot, default -55> xlen= <x-length in km> ylen= <y-length in km>
MODEL CORNERS:
<lon 1> <lat 1> (x= 0.000 y= 0.000)
<lon 2> <lat 2> (x= <max x> y= 0.000)
<lon 3> <lat 3> (x= <max x> y= <max y>)
<lon 4> <lat 4> (x= 0.000 y= <max y>)
</pre>

Generated by: PreCVM

Used by: PreSGT, PostAWP

=== Gridfile ===

Purpose: Specify the three dimensions, and gridspacing in each dimension, of the volume.

Filename convention: gridfile_<site>

Format:
<pre>
xlen=<x-length in km>
0.0 <x-length> <grid spacing in km>
ylen=<y-length in km>
0.0 <y-length> <grid spacing in km>
zlen=<z-length in km>
0.0 <z-length> <grid spacing in km>
</pre>

=== Gridout ===

Purpose: Specify the km offsets for each grid index, in X, Y, and Z, from the upper southwest corner.

Filename convention: gridout_<site>

Format:
<pre>
xlen=<x-length in km>
nx=<number of gridpoints in X direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
2 <2*grid spacing> <grid spacing>
3 <3*grid spacing> <grid spacing>
...
nx-1 <(nx-1)*grid spacing> <grid spacing>
ylen=<y-length in km>
ny=<number of gridpoints in Y direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
ny-1 <(ny-1)*grid spacing> <grid spacing>
zlen=<z-length in km>
nz=<number of gridpoints in Z direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
nz-1 <(nz-1)*grid spacing> <grid spacing>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT, PreAWP

=== Params ===

Purpose: Succinctly specify the parameters for the CyberShake volume. Similar information to the modelbox file, but in a different format.

Filename convention: model_params_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
Model origin coordinates:
lon= <model lon> lat= <model lat> rotate= <model rotation, default -55>

Model origin shift (cartesian vs. geographic):
xshift(km)= <x shift, usually half the x-length minus 1 grid spacing> yshift(km)= <y-shift, usually half the y-length minus 1 grid spacing>

Model corners:
c1= <nw lon> <nw lat>
c2= <ne lon> <ne lat>
c3= <se lon> <se lat>
c4= <sw lon> <sw lat>

Model Dimensions:
xlen= <x-length> km
ylen= <y-length> km
zlen= <z-length> km
</pre>

Generated by: PreCVM

Used by:

=== Coord ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, for each point on the surface.

Filename convention: model_coords_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
...
<lon> <lat> <nx-1> 1
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT

=== Bounds ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, but only for the points along the boundary. A subset of the coord file.

Filename convention: model_bounds_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
<lon> <lat> <nx-1> 1
<lon> <lat> 0 2
<lon> <lat> <nx-1> 2
...
<lon> <lat> 0 <ny-1>
<lon> <lat> 1 <ny-1>
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by:

=== Velocity files ===

==== RWG format ====

Purpose: Input velocity files for the RWG wave propagation code, emod3d.

Filename convention: v_sgt-<site>.<p, s, or d>

Format: 3 files, one each for Vp (*.p), Vs (*.s), and rho (*.d). Each is binary, with 4-byte floats, in fast X, Z (surface->down), slow Y order.

Generated by: UCVM

Used by: PreAWP

==== AWP format ====

Purpose: Input velocity file for the AWP-ODC wave propagation code.

Filename convention: awp.<site>.media

Format: Binary, with 4-byte floats, in fast Y, X, slow Z (surface down) order.

Generated by: UCVM

Used by: Smoothing, PreAWP, PostAWP

=== Fdloc ===

Purpose: Coordinates of the site, in X Y grid indices, and therefore the coordinates where the SGT impulse should be placed.

Filename convention: <site>.fdloc

Format:
<pre>
<X grid index of site> <Y grid index of site>
</pre>

Generated by: PreSGT

Used by: PreAWP, PostAWP

=== Faultlist ===

Purpose: List of paths to all the rupture geometry files for all ruptures which are within the cutoff for this site. Used to produce a list of points to save SGTs for.

Filename convention: <site>.faultlist

Format:
<pre>
<path to rupture file> nheader=<number of header lines, usually 6> latfirst=<1, to signify that latitude comes first in the rupture files>
...
</pre>

Generated by: PreSGT

Used by: PreSGT

=== Radiusfile ===

Purpose: Describe the adaptive mesh SGTs will be saved for.

Filename convention: <site>.radiusfile

Format:
<pre>
<number of gradations in X and Y>
<radius 1> <radius 2> <radius 3> <radius 4>
<decimation less than radius 1> <decimation between radius 1 and 2> <between 2 and 3> <between 3 and 4>
<number of gradations in Z>
<depth 1> <depth 2> <depth 3> <depth 4>
<decimation less than depth 1> <decimation between depth 1 and 2> <between 2 and 3> <between 3 and 4>
</pre>

Generated by: PreSGT

Used by: PreSGT

=== SGT Coordinate files ===

There are two formats for the list of points to save SGTs for, one for Rob's codes and one for AWP-ODC. As with other coordinate transformations between the two systems, to convert X and Y offsets from RWG to AWP you have to flip the X and Y and add 1 to each, since RWG is 0-indexed and AWP is 1-indexed.

==== SgtCoords ====

Purpose: List of all the points to save SGTs for.

Filename convention: <site>.cordfile

Format: Z changes fastest, then Y, then X slowest.
<pre>
# geoproj= <projection; we usually use 1 for great circle>
# modellon= <model lon> modellat= <model lat> modelrot= <model rot, usually -55>
# xlen= <x-length> ylen= <y-length>
#
<total number of points>
<X index> <Y index> <Z index> <Single long to capture the index, in the form XXXXYYYYZZZZ> <lon> <lat> <depth in km>
...
</pre>

Generated by: PreSGT

Used by: PreSGT, PreAWP, PostAWP

==== AWP cordfile ====

Purpose: List of SGT points to save in a format usable by AWP-ODC-SGT.

Filename convention: awp.<site>.cordfile

Format: Remember that X and Y are flipped and have 1 added from RWG. The points are sorted by Y, then X, then Z, so Y changes slowest and Z changes fastest. This is flipped from the RWG cordfile because X and Y components are swapped.
<pre>
<number of points>
<X coordinate> <Y coordinate> <Z coordinate>
...
</pre>

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== Impulse source descriptions ===

We generate the initial source description for CyberShake, with the required dt, nt, and filtering, using gen_source, in https://github.com/SCECcode/cybershake-core/SimSgt_V3.0.3/src/ (run 'make get_source'). gen_source hard-codes its parameters, but you should only change 'nt', 'dt', and 'flo'. We have been setting flo to twice the CyberShake maximum frequency, to reduce filtering affects at the frequency of interest. gen_source wraps Rob Graves's source generator, which we use for consistency.

To generate a source for a component, run
<pre>
$>./gen_source xsrc=0 ysrc=0 zsrc=0 <fxsrc|fysrc|fzsrc>=1 moment=1e20
</pre>

Once this RWG source is generated, we then use AWP-GPU-SGT/utils/data/format_source.py to reprocess the RWG source into an AWP-source friendly format. This involves reformatting the file and multiplying all values by 1e15 for unit conversion. Different files must be produced for X and Y coordinates, since in the AWP format different columns are used for different components.

Finally, AWP-GPU-SGT/utils/build_src.py takes the correct AWP-friendly source (nt and dt) for a run and adds the impulse location coordinates, producing a complete AWP format source description.

==== RWG source ====

Purpose: Source description for the SGT impulse.

Filename convention: source_cos0.10_<frequency>hz

Format:
<pre>
source cos
<nt> <dt> 0 0 0.0 0.0 0.0 0.0
<value at ts0> <value at ts1> <value at ts2> <value at ts3> <value at ts4> <value at ts5>
<value at ts6> <value at ts7> <value at ts8> <value at ts9> <value at ts10> <value at ts11>
...
</pre>

Generated by: gen_source (see above)

Used by: PreAWP

==== AWP source ====

Purpose: Source description which can be used by AWP-ODC.

Filename convention: <site>_f<x or y>_src

Format: Note that X and Y coordinates are swapped between RWG and AWP format, because of how the box is defined. Additionally, RWG is 0-indexed, and AWP is 1-indexed, and the RWG values must be multiplied by 1e15 for unit conversion.
<pre>
<X index of source, same as site X index> <Y index of source, same as site Y index>
<XX impulse at ts0> <YY at ts0> <ZZ at ts0> <XY at ts0> <XZ at ts0> <YZ at ts0>
...
</pre>
Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== IN3D ===

Purpose: Input file for AWP-ODC.

Filename convention: IN3D.<site>.<x or y>

Format: Specified [https://scec.usc.edu/it/AWP-ODC-SGT#IN3D here (login required)].

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU, PostAWP

=== AWP SGT ===

Purpose: SGT file, created by AWP-ODC-SGT.

Filename convention: awp-strain-<site>-f<x or y>

Format: binary, 4-byte floats. Points are in the same order as in the AWP SGT coordinate file, which is fast Z, X, Y. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: AWP-ODC-SGT CPU and GPU

Used by: PostAWP, NanCheck

=== RWG SGT ===

Purpose: SGT file, created by PostAWP for use in post-processing.

Filename convention: <site>_f<x or y>_<run id>.sgt

Format: binary, 4-byte floats. Points are in the same order as in the RWG coordinate file, which is fast Z, Y, X. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: PostAWP

Used by: CheckSgt, DirectSynth

=== SGT header file ===

Purpose: SGT header information, used to parse and understand SGT files

Filename convention: <site>_f<x or y>_<run id>.sgthead

Format: binary. It consists of three sections:

<ol>
<li>The sgtmaster structure, described below in C. Its information can be used to set up data structures to read the rest of the SGTs.</li>
<pre>
struct sgtmaster
{
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int globnp; /* total number of SGT locations (entire model) */
int localnp; /* local number of SGT locations (this file only) */
int nt; /* number of time points */
};
</pre>
<li>The sgtindex structures, described below in C. There is one of these for each point in the SGTs, and they're used to determine the X/Y/Z indices of all the SGT points. Note that the current way of packing the X,Y,Z coordinates into the long allows for 6 digits (so maximum 1M grid points) for each component.</li>
<pre>
struct sgtindex /* indices for all 'globnp' SGT locations */
{
long long indx; /* indx= xsgt*1000000000000 + ysgt*1000000 + zsgt */
int xsgt; /* x grid location */
int ysgt; /* y grid location */
int zsgt; /* z grid location */
float h; /* grid spacing */
};
</pre>
<li>The sgtheader structures, described below in C. There is one of these for each point in the SGTs. They're used when we perform reciprocity.</li>
<pre>
struct sgtheader
{
long long indx; /* index of this SGT */
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int nt; /* number of time points */
float xazim; /* azimuth of X-axis in FD model (clockwise from north) */
float dt; /* time sampling */
float tst; /* start time of 1st point in GF */
float h; /* grid spacing */
float src_lat; /* site latitude */
float src_lon; /* site longitude */
float src_dep; /* site depth */
int xsrc; /* x grid location for source (station in recip. exp.) */
int ysrc; /* y grid location for source (station in recip. exp.) */
int zsrc; /* z grid location for source (station in recip. exp.) */
float sgt_lat; /* SGT location latitude */
float sgt_lon; /* SGT location longitude */
float sgt_dep; /* SGT location depth */
int xsgt; /* x grid location for output (source in recip. exp.) */
int ysgt; /* y grid location for output (source in recip. exp.) */
int zsgt; /* z grid location for output (source in recip. exp.) */
float cdist; /* straight-line distance btw site and SGT location */
float lam; /* lambda [in dyne/(cm*cm)] at output point */
float mu; /* rigidity [in dyne/(cm*cm)] at output point */
float rho; /* density [in gm/(cm*cm*cm)] at output point */
float xmom; /* moment strength of x-oriented force in this run */
float ymom; /* moment strength of y-oriented force in this run */
float zmom; /* moment strength of z-oriented force in this run */
};
</pre>
</ol>

Overall, then, the format for the file is:
<pre>
<sgtmaster>
<sgtindex for point 1>
<sgtindex for point 2>
...
<sgtindex for point globnp>
<sgtheader for point 1>
<sgtheader for point 2>
...
<sgtheader for point globnp>
</pre>

Generated by: PostAWP

Used by: DirectSynth

=== Velocity Info file ===

Purpose: Contains the 3D velocity information needed for stochastic jobs

Filename convention: velocity_info_<site>.txt

Format: Text format, three lines:

<pre>
Vs30 = <Vs30 value>
Vs500 = <Vs500 value>
VsD500 = <VsD500 value>
</pre>

Generated by: Velocity Info job

Used by: Sub Stoch DAX generator, to add these values as command-line arguments to HF Synth and LF Site Response jobs.

=== rupture list file ===

Purpose: Contains a list of all the ruptures for which low-frequency seismograms should be synthesized. This file is used to construct the tasks in DirectSynth. The number of rows, columns, and magnitude are included because DirectSynth uses this information to determine how much memory the tasks will use. This file is constructed at abstract workflow creation time.

Filename convention: rupture_file_list_<site>_<run_id>

Format: Text format, with the number of ruptures and then 1 line per rupture:

<pre>
<number of ruptures N>
<rupture geometry filename 1> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
<rupture geometry filename 2> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
...
<rupture geometry filename N> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
</pre>

Used by: DirectSynth

=== rupture variation info file ===

Purpose: This file provides the rvfrac (rupture velocity speed as a fraction of shear wave velocity) and random seed for each rupture variation. It is constructed at abstract workflow creation time, using values from the database. It is highly recommended that these values are stored somewhere for reproducibility, and the same values should be used for all sites so that the rupture variations are the same for all sites.

Filename convention: rvfrac_seed_values_<site>_<run_id>

Format: Text format, with the number of rupture variations and then 1 line per rupture variation:

<pre>
<number of rupture variations N>
<source ID 1> <rupture ID 1> <rupture variation ID 1> <rvfrac> <random seed>
<source ID 2> <rupture ID 2> <rupture variation ID 2> <rvfrac> <random seed>
...
<source ID N> <rupture ID N> <rupture variation ID N> <rvfrac> <random seed>
</pre>

Used by: DirectSynth, when linked with RupGen-v5.5.2 or later

=== BBP 1D Velocity file ===

Purpose: Contains 1D velocity profile information

Filename convention: The only one currently in use in CyberShake is /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <not used> <not used>
<layer 2 thickness in km> <Vp> <Vs> <density> <not used> <not used>
...
<layer L thickness in km> <Vp> <Vs> <density> <not used> <not used>
</pre>

Note that the last layer has thickness 999.0.

Generated by: Rob Graves

Used by: Local VM job

=== Local VM file ===

Purpose: Contains 1D velocity profile information for use with stochastic codes

Filename convention: The only one currently in use in CyberShake is LA_Basin_BBP_14.3.0.local .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
<layer 2 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
...
<layer L thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
</pre>

Note that the last layer has thickness '0.0', indicating it has no bottom.

Generated by: Local VM Job

Used by:

=== Missing variations file ===

Purpose: Lists the variations which the Check DB stage has found are missing.

Filename convention: DB_Check_Out_<PSA or RotD or Duration>_<site>

Format: For each source and rupture pair with missing variations, the following record is output in text format:

<pre>
<source ID> <rupture ID> <number N of missing rupture variations>
<ID of first missing rupture variation>
<ID of second missing rupture variation>
...
<ID of Nth missing rupture variation>
</pre>

Originally, a file in this format could be directly fed back into the DAX generator, but that capability has not been used for many years and may not still be functional.

Generated by: Check DB Site

Used by: none

=== DB Report file ===

Purpose: Provides PSA data for a run in a text format.

Filename convention: <site>_ERF<erf id>_report_<date>.txt

Format: It's a text file with the following header:
Site_Name ERF_ID Source_ID Rupture_ID Rup_Var_ID Rup_Var_Scenario_ID Mag Prob Grid_Spacing Num_Rows Num_Columns Period Component SA
The file is sorted by fast Rup_Var_ID, Rupture_ID, Source_ID, Period, slow Component.

Generated by: DB Report

Used by: none, output data product

=== Hazard Curve ===

Purpose: Contains a hazard curve, either in text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run id>_<IM type>_<period>sec_<IM component>_<date run completed>.<pdf|txt|png>

Format: The PNG and PDF formats contain an image of the curve. The PDF format also has an extended legend. The TXT file contains a list of (X,Y) points which describe the curve.

Generated by: Curve Calc

Used by: none, output data product

=== Disaggregation file ===

Purpose: Contains disaggregation results for a single run, in either text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run_id>_Disagg<POE|IM>_<disagg level>_<IM type>_<period>sec_<run date>.<txt|png|pdf>

Format: The PNG and PDF formats contain a plot of the disaggregation results, showing magnitude vs distance and color-coding based on epsilon. The PDF and TXT formats contain additional information about individual source contributions, in the following format:

<pre>Summary data
Parameters used to create disaggregation
Disaggregation bin data:
Dist Mag <breakout by epsilon values>
<Breakdown of contribution by distance, magnitude, and epsilon range>

Disaggregation Source List Info:
Source# %Contribution TotExceedRate SourceName DistRup DistX DistSeis DistJB
<list of contributing sources, in decreasing order of % contribution>
</pre>

Generated by: Disaggregation

Used by: none, output data product

== Dependencies ==

The following are external software dependencies used by CyberShake software modules.

=== Getpar ===

Purpose: A library written in C which enables parsing of key-value command-line parameters, and enforcement of required parameters. Rob Graves uses it in his codes.

How to obtain: Rob supplied a copy; it is in the CyberShake repository at https://github.com/SCECcode/cybershake-core/tree/main/Getpar .

Special installation instructions: Run 'make' in Getpar/getpar/src; this will make the library, libget.a, and install it in the lib directory, where CyberShake codes will expect it.

=== MySQLdb ===

This library has been deprecated in favor of pymysql.

=== pymysql ===

Purpose: MySQL bindings for Python.

How to obtain: pip3 install pymysql . Documentation is at https://pypi.org/project/PyMySQL/ .

Special installation instructions: None; pip3 shouldn't have any issues.

=== UCVM ===

Purpose: Supplies the query tools needed to populate a mesh with velocity information.

How to obtain: The most recent version of UCVM can be found at [[UCVM#Current_UCVM_Software_Releases|Current UCVM Software Releases]]. As of October 2017, we have only integrated the C version of UCVM into CyberShake.

Special installation instructions: Following the standard installation instructions for a cluster should work (running ./ucvm_setup.py). You will want to install CVM-S4, CVM-S426, CVM-S4.M01, CVM-H, CenCal, CCA-06, and CCA 1D velocity models for CyberShake.

=== libcfu ===

Purpose: Provides a hash table library for a variety of CyberShake codes.

How to obtain: https://sourceforge.net/projects/libcfu/ . Documentation is at http://libcfu.sourceforge.net/libcfu.html .

Special installation instructions: Follow the instructions, and install into the utils directory.

=== FFTW ===

Purpose: Library which provides FFTs.

How to obtain: Typically installed on supercomputers already, though you may need to load a module to activate it.

Special installation instructions: Doesn't need to be installed in user space.

=== memcached ===

Purpose: Server library for running a memory caching system, using key-value pairs.

How to obtain: Download from https://memcached.org/ .

Special installation instructions: Follow instructions and install in utils directory. It has a dependency on libevent, which you may have to install also.

=== libmemcached ===

Purpose: Client library and tools for memcached server.

How to obtain: Download from http://libmemcached.org/libMemcached.html . Install memcached first.

Special installation instructions: Sometimes installing can be a challenge, because it can't find the memcached install. You may have to set the path to memcached either as an argument to configure, or you may even need to edit the configuration and makefiles directory. Install into the utils directory.

=== RupGen-api ===

Purpose: To generate rupture variations from a rupture geometry for a given hypocenter and slip using the Graves & Pitarka rupture generator. The current version is 5.5.2.

How to obtain: Check out from https://github.com/SCECcode/cybershake-core/tree/main/RuptureCodes/RupGen-api-5.5.2 .

Special installation instructions:

#This code is dependent on FFTW. You may need to edit the makefile to point to the FFTW include files and libraries, since different clusters often use different environment variables to capture FFTW paths.
#If you want memcached support, edit the makefile in RuptureCodes/RupGen-api-5.5.2/src to uncomment lines 19-21 and edit line 19 to point to the libmemcached install directory. You'll need to do the same to RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.0/makefile, lines 35-37.
#You may need to edit CFLAGS in RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.5.2/makefile (lines 21-23) to point to the FFTW path; whether or not this is needed depends on the particular system.
#Run 'make' in RupGen-api-5.5.2 to make the librupgen.a library.

=== SCEC Broadband Platform ===

Purpose: To generate high-frequency stochastic seismograms for broadband CyberShake runs.

How to obtain: Follow installation instructions at https://github.com/SCECcode/bbp .

CyberShake Code Base

2025-11-26T19:46:28Z

Scottcal: /* DirectSynth */

This page details all the pieces of code which make up the CyberShake code base, as of November 2017. Note that this does not include the workflow middleware, or the workflow generators; that code is detailed at [[CyberShake Workflow Framework]].

Conceptually, we can divide up the CyberShake codes into three categories:

#Strain Green Tensor-related codes: These codes produce the input files needed to generate SGTs, actually calculate the SGTs, and do some reformatting and sanity checks on the results.
#Synthesis-related codes: These codes take the SGTs and perform seismogram synthesis and intensity measure calculations.
#Data product codes: These codes insert the results into the database, and use the database to generate a variety of output data products.

Below is a description of each piece of software we use, organized by these categories. For each piece of software, we include a description of where it is located, how to compile and use it, and what its inputs and outputs are. At the end, we provide a description of input and output files and formats.

== Code Installation ==

Historically, we have selected a root directory for CyberShake, then created the subdirectories 'software' for all the code, 'ruptures' for the rupture files, 'logs' for log files, and 'utils' for workflow tools. This is typically set up in unpurged storage space, so once installed purging isn't a worry. Each code listed below, along with the configuration file, should be checked out into the 'software' subdirectory.

In terms of compilers, you should use the GNU compilers unless specifically directed otherwise.

Most of the codes below contain a main directory. Inside that is a bin directory, with binaries; a src directory with code requiring compilation; and wrappers, in the main directory.

If you are looking for compilation instructions, a general guide is available [[CyberShake compilation guide | here]].

=== Configuration file ===

Many CyberShake codes use a configuration file, which specifies the root directory for the CyberShake installation, the command use to start an MPI executable, paths to a tmp and scratch space (which can be the same), and the path to the CyberShake rupture directory. We have done this instead of environment variables because it's more transparent and easier for multiple users. Both of these files should be stored in the 'software' subdirectory.

The configuration file is available at:
https://github.com/SCECcode/cybershake-core/cybershake.cfg
Obviously, this file must be edited to be correct for the install.

The keys that CyberShake currently expects to find are:
*CS_PATH = /path/to/CyberShake/software/directory
*SCRATCH_PATH = /path/to/shared/scratch
*TMP_PATH = /path/to/tmp (can be node-local, or shared with scratch
*RUPTURE_PATH = /path/to/CyberShake/rupture/directory
*MPI_CMD = ibrun or aprun or mpiexec
*LOG_PATH = /path/to/CyberShake/logs/directory

To interact with cybershake.cfg, the CyberShake codes use a Python script to deliver cybershake.cfg entries as key-value pairs, located here:
https://github.com/SCECcode/cybershake-core/config.py
Several CyberShake codes import config, then use it to read out the cybershake.cfg file.

=== Compiler file ===

A long time ago, Gideon Juve created a compiler file, Compilers.mk, which contains information about which compilers should be used for which system. This file should also be downloaded using 'svn export' and installed in the software directory, from
https://github.com/SCECcode/cybershake-core/Compilers.mk

Some of the makefiles reference this file. This can - and should - be updated to reflect new systems.

== SGT-related codes ==

[[File:SGT_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the SGT part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_SGT_workflow.odg source file (ODG)]]]

=== PreCVM ===

This code stands for "Pre-Community-Velocity-Model". It has to be run before the UCVM codes, since it generates input files required by UCVM.

Purpose: To determine the simulation volume for a particular CyberShake site.

Detailed description: PreCVM queries the CyberShake database to determine all of the ruptures which fall within a given cutoff for a certain site. From that information, padding is added around the edges to construct the CyberShake simulation volume for this site. Additional padding so the X and Y dimensions are multiples of 10, 20, or 40 might also be applied, depending on the input parameters. Using this volume, both the X/Y offset of each grid point, and then the latitude and longitude using a great circle projection, are determined and written to output files.

Needs to be changed if:
#The CyberShake volume depth needs to be changed, so as to have the right number of grid points. That is set in the genGrid() function in GenGrid_py/gen_grid.py, in km.
#X and Y padding needs to be altered. That is set using 'bound_pad' in Modelbox/get_modelbox.py, around line 70.
#The rotation of the simulation volume needs to be changed. That is set using 'model_rot' in Modelbox/get_modelbox.py, around line 70.
#The database access parameters have changed. That's in Modelbox/get_modelbox.py, around line 80.
#The divisibility needs for GPU simulations change (currently, we need the dimensions to be evenly divisible by the number of GPUs used in that dimension. That is in Modelbox/get_modelbox.py, around line 250.

Source code location: https://github.com/SCECcode/cybershake-core/PreCVM/

Author: Rob Graves, wrapped by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
pre_cvm.py
Modelbox/get_modelbox.py
Modelbox/bin/gcproj
GenGrid_py/gen_grid.py
GenGrid_py/bin/gen_model_cords

Compile instructions:Run 'make' in the Modelbox/src and the GenGrid_py/src directories.

Usage:
<pre>Usage: pre_cvm.py [options]
Options:
-h, --help show this help message and exit
--site=SITE Site name
--erf_id=ERF_ID ERF ID
--modelbox=MODELBOX Path to modelbox file (output)
--gridfile=GRIDFILE Path to gridfile (output)
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coorfile (output)
--paramsfile=PARAMSFILE
Path to paramsfile (output)
--boundsfile=BOUNDSFILE
Path to boundsfile (output)
--frequency=FREQUENCY
Frequency
--gpu Use GPU box settings.
--spacing=SPACING Override default spacing with this value.
--server=SERVER Address of server to query in creating modelbox,
default is focal.usc.edu.</pre>

Typical run configuration: Serial; requires 6 minutes for 100m spacing, 10 billion point volume

Input files: None; inputs are retrieved from the database

Output files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridfile|gridfile]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Params|params]], [[CyberShake_Code_Base#Coord|coord]], [[CyberShake_Code_Base#Bounds|bounds]]

=== UCVM ===

Purpose: To generate a populated velocity mesh for a CyberShake simulation volume.

Detailed description: UCVM takes the volume defined by PreCVM and queries the [[UCVM]] software, using the C API, to populate the volume. The resulting mesh is then checked for Vp/Vs ratio, minimum Vp/Vs/rho, and for no Infs or NaNs. The data is outputted in either Graves (RWG) format or AWP format. This code also produces log files, which will be written to the CyberShake logs directory/GenLog/site/v_mpi-<processor number>.log. This can be useful if there's an error and you aren't sure why.

Needs to be changed if:
#New velocity models are added. Velocity models are specified in the DAX and passed through the wrapper scripts into the C code and then ultimately to UCVM, so an if statement must be added to around line 250 (and around line 450 if it's applicable for no GTL).
#The backend UCVM substantially changes. If we move to the Python implementation, for example.
#If additional models are added, new libraries may need to be added to the makefile.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
single_exe.py
single_exe.csh
bin/ucvm-single-mpi

Compile instructions:The makefile needs to be edited so that "UCVM_HOME" points to the UCVM home directory. Then run 'make' in the UCVM/src directory.

Usage:
<pre>All of site, gridout, modelcords, models, and format must be specified.
Usage: single_exe.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coordfile (output)
--models=MODELS Comma-separated string on velocity models to use.
--format=FORMAT Specify awp or rwg format for output.
--frequency=FREQUENCY
Frequency
--spacing=SPACING Override default spacing with this value (km)
--min_vs=MIN_VS Override minimum Vs value. Minimum Vp and minimum
density will be 3.4 times this value.
</pre>

Typical run configuration: Parallel on ~4000 cores; for 10 billion points and the C version of UCVM, takes about 20 minutes. Typically only half the cores per node are used to get more memory per process.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#coords|coords]]

Output files: either [[CyberShake_Code_Base#RWG_format|RWG format]] or [[CyberShake_Code_Base#AWP_format|AWP format]], depending on the option selected.

=== Smoothing ===

Purpose: To smooth a velocity file along model interfaces.

Detailed description: The smoothing code takes in a velocity mesh, determines the surface coordinates of the interfaces between velocity models, gets a list of all the points which need to be smoothed, and then performs the smoothing by averaging in both the X and Y direction for a user-specified number of points (default of 10km in each direction).

Needs to be changed if:
#We change our version of UCVM. The LD_LIBRARY_PATH needs to be modified, in run_smoothing.py around line 98.
#The smoothing algorithm is modified. Currently that is specified in the average_point() function in smooth_mpi.c.
#We start using velocity models with boundaries aren't perpendicular to the earth's surface.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM/smoothing

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
smoothing/run_smoothing.py
bin/determine_surface_model
smoothing/determine_smoothing_points.py
smoothing/smooth_mpi

Compile instructions:Run 'make' in the smoothing directory, and make sure that determine_surface_model has been compiled in the UCVM/src directory. You may need to change the compiler; currently it uses 'cc'.

Usage:
<pre>Usage: run_smoothing.py [options]

Options:
-h, --help show this help message and exit
--gridout=GRIDOUT gridout file
--coords=COORDS coords file
--models=MODELSTRING comma-separated list of velocity models
--smoothing-dist=SMOOTHING_DIST
Number of grid points to smooth over. About 10km of
grid points is a good starting place.
--mesh=MESH AWP-format velocity mesh to smooth
--mesh-out=MESH_OUT Output smoothed mesh
</pre>

Typical run configuration: Parallel on ~1500 cores; for 5 billion points and the C version of UCVM, takes about 16 minutes.

Input files: [[CyberShake_Code_Base#AWP_format|AWP format velocity file]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#AWP_format|AWP format]] smoothed velocity file.

=== PreSGT ===

Purpose: To generate a series of input files which are used by the wave propagation codes.

Detailed description: PreSGT determines the X and Y coordinates of the site location (where the impulse will go for the wave propagation simulation) and determines, which mesh point (X and Y) maps most closely to every point on a fault surface which is within the cutoff. That information is combined with an adaptive mesh approach to create a list of all the points for which SGTs should be saved.

Needs to be changed if:
#We change our approach for saving adaptive mesh points.
#We change the location of the rupture geometry files, currently assumed to be <rupture root>/Ruptures_erf<erf ID> . This is specified in presgt.py, line 167.
#The directory hierarchy and naming scheme for rupture geometry files, currently <src id>/<rup id>/<src id>_<rup_id>.txt, changes. This is specified in faultlist_py/CreateFaultList.py, line 36.
#The number of header lines in the rupture geometry file changes. This would require changing the nheader value, currently 6, specified in faultlist_py/CreateFaultList.py, line 36.
#We switch to RSQSim ruptures, or other ruptures in which the geometry isn't planar. Modifications would be required to gen_sgtgrid.c.

Source code location: https://github.com/SCECcode/cybershake-core/PreSgt

Author: Rob Graves, heavily modified by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#libcfu|libcfu]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
presgt.py
faultlist_py/CreateFaultList.py
bin/gen_sgtgrid

Compile instructions:Run 'make' in the src directory.

Usage:
<pre>Usage: ./presgt.py <site> <erf_id> <modelbox> <gridout> <model_coords> <fdloc> <faultlist> <radiusfile> <sgtcords> <spacing> [frequency]
Example: ./presgt.py USC 33 USC.modelbox gridout_USC model_coords_GC_USC USC.fdloc USC.faultlist USC.radiusfile USC.cordfile 200.0 0.1
</pre>

Typical run configuration: Parallel on 8 nodes, 32 cores (gen_sgtgrid is a parallel code); for 200m spacing UCERF2, takes about 8 minutes.

Input files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#Faultlist|faultlist]], [[CyberShake_Code_Base#Radiusfile|radiusfile]], [[CyberShake_Code_Base#SgtCoords|sgtcoords]].

=== PreAWP ===

Purpose: To generate input files in a format that AWP-ODC expects.

Detailed description: PreAWP performs a number of steps:
#An IN3D parameter file is produced, needed for AWP-ODC.
#A file with the SGT coordinates to save in AWP format is produced. Since RWG and AWP use different coordinate systems, a coordinate transformation (X->Y, Y->X, zero-indexing->one-indexing) is performed on the SGT coordinates file.
#The velocity file in translated to AWP format, if it isn't in AWP format already.
#The correct source, based on the dt and nt, is selected. The source must be generated manually ahead of time. Details about source generation are given [[CyberShake Code Base#Impulse source descriptions | here]].
#Striping for the output file is also set up here.
#Files are symlinked into the directory structure that AWP expects. Note that slightly different versions of this exist for the CPU and GPU implementations of AWP-ODC-SGT.

Needs to be changed if:
#The path to the Lustre striping command (lfs) changes. This path is hard-coded in build_awp_inputs.py, line 14. Note that this is the path to lfs on the compute node, NOT the login node.
#The AWP code changes its input format.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/ (HIP GPU) or https://github.com/SCECcode/cybershake-core/AWP-GPU-SGT/utils/ (CUDA GPU) or https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT/utils/ (CPU), AND also https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: SgtHead

Executable chain:
build_awp_inputs.py
build_IN3D.py
build_src.py
build_cordfile.py
SgtHead/gen_awp_cordfile.py
build_media.py
SgtHead/bin/reformat_velocity

Compile instructions:Run 'make' in the SgtHead/src directory.

Usage:
<pre>Usage: build_awp_inputs.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout input file
--fdloc=FDLOC Path to fdloc input file
--cordfile=CORDFILE Path to cordfile input file
--velocity-prefix=VEL_PREFIX
RWG velocity prefix. If omitted, will not reformat
velocity file, just symlink.
--frequency=FREQUENCY
Frequency of SGT run, 0.5 Hz by default.
--px=PX Number of processors in X-direction.
--py=PY Number of processors in Y-direction.
--pz=PZ Number of processors in Z-direction.
--source-frequency=SOURCE_FREQ
Low-pass filter frequency to use on the source,
default is same frequency as the frequency of the run.
--spacing=SPACING Override default spacing, derived from frequency.
--velocity-mesh=VEL_MESH
Provide path to velocity mesh. If omitted, will
assume mesh is named awp.<site>.media.
</pre>

Typical run configuration: Serial; for 1 Hz run, takes about 11 minutes.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#SgtCoords|cordfile]], velocity mesh (if in [[CyberShake_Code_Base#RWG_format|RWG format]], will be converted to [[CyberShake_Code_Base#AWP_format|AWP]]), [[CyberShake_Code_Base#RWG_source|RWG source]]

Output files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP source|AWP source]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]].

=== AWP-ODC-SGT, CPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the CPU version. It uses the IN3D file for its parameters.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: iobuf module

Executable chain:
awp_odc_wrapper.sh
bin/pmcl3d

Compile instructions:Using the GNU compilers, run 'make' in the src directory.

Usage:
<pre> pmcl3d <IN3D parameter file>
</pre>

Typical run configuration: Parallel; for 0.5 Hz run (2 billion points, 20k timesteps), takes about 45 minutes on 10,000 cores.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== AWP-ODC-SGT, CUDA GPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the GPU version. It takes parameters on the command-line, so the wrapper converts the IN3D file into command-line arguments and invokes it.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: hhttps://github.com/SCECcode/cybershake-core/AWP-GPU-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: CUDA toolkit module

Executable chain:
gpu_wrapper.py
bin/pmcl3d

Compile instructions:modules PrgEnv-gnu and module cudatoolkit must be loaded first. Then, run 'make' in the src directory.

Usage:
<pre>Usage: ./pmcl3d
Options:
[(-T | --TMAX) <TMAX>]
[(-H | --DH) <DH>]
[(-t | --DT) <DT>]
[(-A | --ARBC) <ARBC>]
[(-P | --PHT) <PHT>]
[(-M | --NPC) <NPC>]
[(-D | --ND) <ND>]
[(-S | --NSRC) <NSRC>]
[(-N | --NST) <NST>]

[(-V | --NVE) <NVE>]
[(-B | --MEDIASTART) <MEDIASTART>]
[(-n | --NVAR) <NVAR>]
[(-I | --IFAULT) <IFAULT>]
[(-R | --READ_STEP) <x READ_STEP]

[(-X | --NX) <x length]
[(-Y | --NY) <y length>]
[(-Z | --NZ) <z length]
[(-x | --NPX) <x processors]
[(-y | --NPY) <y processors>]
[(-z | --NPZ) <z processors>]

[(-1 | --NBGX) <starting point to record in X>]
[(-2 | --NEDX) <ending point to record in X>]
[(-3 | --NSKPX) <skipping points to record in X>]
[(-11 | --NBGY) <starting point to record in Y>]
[(-12 | --NEDY) <ending point to record in Y>]
[(-13 | --NSKPY) <skipping points to record in Y>]
[(-21 | --NBGZ) <starting point to record in Z>]
[(-22 | --NEDZ) <ending point to record in Z>]
[(-23 | --NSKPZ) <skipping points to record in Z>]

[(-i | --IDYNA) ]
[(-s | --SoCalQ) <s SoCalQ>]
[(-l | --FL) <l FL>]
[(-h | --FH) ]
[(-p | --FP) ]
[(-r | --NTISKP) <time skipping in writing>]
[(-W | --WRITE_STEP) <time aggregation in writing>]

[(-100 | --INSRC) <source file>]
[(-101 | --INVEL) <mesh file>]
[(-o | --OUT) <output file>]
[(-c | --CHKFILE) <checkpoint file to write statistics>]

[(-G | --IGREEN) <IGREEN for SGT>]
[(-200 | --NTISKP_SGT) <NTISKP for SGT>]
[(-201 | --INSGT) <SGT input file>]
</pre>

Typical run configuration: Parallel; for 1 Hz run (10 billion points, 40k timesteps), takes about 55 minutes on 800 GPUs.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== PostAWP ===

Purpose: To prepare the AWP results for use in post-processing.

Detailed description: PostAWP prepares the outputs of AWP so that they can be used with the RWG-authored post-processing code. Specifically, it undoes the AWP coordinate transformation and reformats the AWP output files into the SGT component order expected by RWG (XX->YY, YY->XX, XZ->-YZ, YZ->-XZ, and all SGTs are doubled if we are calculating the Z-component), creates separate SGT header files, and calculates MD5 sums on the SGT files. Calculating the header information requires a number of input files, since lambda, mu, and the location of the impulse must all be included. The MD5 sums can be calculated separately, using the MD5 wrapper RunMD5sum.

Needs to be changed if:
#The AWP code is modified to produce outputs in exactly RWG order
#The header format for the post-processing code changes
#We decide not to calculate MD5 sums

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/prepare_for_pp.py (this will work for the CPU version of AWP also, despite the path); https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
AWP-GPU-SGT/utils/prepare_for_pp.py
SgtHead/bin/reformat_awp_mpi
SgtHead/bin/write_head

Compile instructions:Run 'make write_head' and 'make reformat_awp_mpi' in the SgtHead/src directory.

Usage:
<pre>Usage: ./prepare_for_pp.py <site> <AWP SGT> <reformatted SGT filename> <modelbox file> <rwg cordfile> <fdloc file> <gridout file> <IN3D file> <AWP media file> <component> <run_id> <header> [frequency]
</pre>

Typical run configuration: Parallel, 4 processors on 2 nodes; for a 750 GB SGT, takes about 100 minutes without the MD5 sums.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#SgtCoords|RWG cordfile]]), [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]

Output files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]], [[CyberShake_Code_Base#SGT header file|SGT header file]]

=== RunMD5sum ===

Purpose: Wrapper for performing MD5sums.

Detailed description: On Titan, we ran into wallclock issues when bundling the MD5sums along with PostAWP. This wrapper supports performing the MD5 sums separately.

Needs to be changed if:
#We change hash algorithms

Source code location: https://github.com/SCECcode/cybershake-core/SgtHead/run_md5sum.sh

Author: Scott Callaghan

Dependencies: none

Executable chain:
run_md5sum.sh

Compile instructions: none

Usage:
<pre>Usage: ./run_md5sum.sh <file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 70 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]]

Output files: MD5sum, with filename <RWG SGT filename>.md5

=== NanCheck ===

Purpose: Check the SGTs for anomalies before the post-processing.

Detailed description: This code checks to be sure the SGTs are the expected size, then checks for NaNs or too many consecutive zeros in the SGT files.

Needs to be changed if:
#We change the number of timesteps in the SGT file. Currently this is hardcoded, but it should be a command-line parameter.
#We want to add additional checks.

Source code location: https://github.com/SCECcode/cybershake-core/SgtTest/

Author: Rob Graves, Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
perform_checks.py
bin/check_for_nans

Compile instructions: Run 'make' in SgtTest/src .

Usage:
<pre>Usage: ./perform_checks.py <SGT file> <SGT header file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 45 minutes.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Sgt Coords|RWG coordinate file]], [[CyberShake_Code_Base#IN3D | IN3D file]]

Output files: none

== PP-related codes ==

The following codes are related to the post-processing part of the workflow.

[[File:PP_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the PP part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_PP_workflow.odg source file (ODG)]]]

=== CheckSgt ===

Purpose: To check the MD5 sums of the SGT files to be sure they match.

Detailed description: CheckSgt takes the SGT files and their corresponding MD5 sums and checks for agreement.

Needs to be changed if:
#We change hashing algorithms.
#We decide to add additional sanity checks to the beginning of the post-processing.

Source code location: https://github.com/SCECcode/cybershake-core/CheckSgt

Author: Scott Callaghan

Dependencies: none

Executable chain:
CheckSgt.py

Compile instructions: none

Usage:
<pre>Usage: ./CheckSgt.py <sgt file> <md5 file>
</pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 90 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], SGT MD5 sums

Output files: None

=== DirectSynth ===

DirectSynth is the code we currently use to perform the post-processing. For historical reasons, all of the codes used for CyberShake post-processing are documented here: [https://scec.usc.edu/it/Post-processing_options CyberShake post-processing options] (login required).

Purpose: To perform reciprocity calculations and produce seismograms, intensity measures, and duration measures.

Detailed description: DirectSynth reads in the SGTs across a group of processes, and hands out tasks (synthesis jobs) to worker processes. These worker processes read in rupture geometry information from disk and call the RupGen-api to generate full slip histories in memory. The workers request SGTs from the reader processes over MPI. X and Y component PSA calculations are performed from the resultant seismograms, and RotD and duration calculations are also performed, if requested. More details about the approach used are available at [[DirectSynth]].

Needs to be changed if:
#We have new intensity measures or other calculations per seismogram to perform.
#We decide to change the post-processing algorithm.
#The wrapper needs to be modified if we want to set different custom environment variables.

Source code location: https://github.com/SCECcode/cybershake-core/DirectSynth

Author: Scott Callaghan, original seismogram synthesis code by Rob Graves, X and Y component PSA code by David Okaya, RotD code by Christine Goulet

Dependencies: [[CyberShake Code Base#Getpar | Getpar]], [[CyberShake Code Base#libcfu | libcfu]], [[CyberShake Code Base#RupGen-api-v3.3.1 | RupGen-api-v3.3.1, [[CyberShake Code Base#FFTW | FFTW]], [[CyberShake Code Base#libmemcached | libmemcached]] (optional) and [[CyberShake Code Base#memcached | memcached]] (optional)

Executable chain:
direct_synth_v3.3.1.py (current version, uses the Graves & Pitarka (2014) rupture generator)
utils/pegasus_wrappers/invoke_memcached.sh
memcached
bin/direct_synth

Compile instructions:
#Compile RupGen-api first.
#Edit the makefile in DirectSynth/src . Check the following variables:
##BASE_DIR should point to the top-level CyberShake install directory
##LIBCFU should point to the libcfu install directory
##V3_3_1_RG_LIB should point to the RupGen-api-3.3.1/lib directory
##LDLIBS should have the correct paths to the libcfu and libmemcached lib directories
##V3_3_1_RG_INC should point to the RupGen-api-3.3.1/include directory
##IFLAGS should have the correct paths to the libcfu and libmemcached include directories
#Run 'make direct_synth_v3.3.1' in DirectSynth/src.

You will also need to edit the hard-coded paths to memcached in direct_synth_v3.3.1.py, in lines 15 and 24.

Usage:
<pre>
direct_synth_v3.3.1.py
stat=<site short name>
slat=<site lat>
slon=<site lon>
run_id=<run id>
sgt_handlers=<number of SGT handler processes; must be enough for the SGTs to be read into memory>
debug=<print logs for each process; 1 is yes, 0 no>
max_buf_mb=<buffer size in MB for each worker to use for storing SGT information>
rupture_spacing=<'uniform' or 'random' hypocenter spacing>
ntout=<nt for seismograms>
dtout=<dt for seismograms>
rup_list_file=<input file containing ruptures to process>
sgt_xfile=<input SGT X file>
sgt_yfile=<input SGT Y file>
x_header=<input SGT X header>
y_header=<input SGT Y header>
det_max_freq=<maximum frequency of deterministic part>
stoch_max_freq=<maximum frequency of stochastic part>
run_psa=<'1' to run X and Y component PSA, '0' to not>
run_rotd=<'1' to run RotD calculations, '0' to not>
run_durations=<'1' to run duration calculation, '0' to not>
simulation_out_pointsX=<'2', the number of components>
simulation_out_pointsY=1
simulation_out_timesamples=<same as ntout>
simulation_out_timeskip=<same as dtout>
surfseis_rspectra_seismogram_units=cmpersec
surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa
surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=<high filter, 5.0 for 1 Hz runs, 20.0 or higher for 10 Hz runs>
surfseis_rspectra_apply_byteswap=no
</pre>

Typical run configuration: Parallel, typically on 3840 processors; for 750 GB SGTs with ~7000 ruptures, takes about 12 hours.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], [[CyberShake_Code_Base#SGT header file|SGT headers]], [[CyberShake_Code_Base#rupture list file|rupture list file]], [[CyberShake_Code_Base#rupture variation info file|rupture variation info file]], [[CyberShake_Rupture_Files|rupture geometry files]]

Output files: [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | Seismograms]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

== Data Product Codes ==

The software in this section takes the data products produced by the SGT and post-processing stages, adds some of it to the database, and creates final data products. Note that all these codes should be installed on a server close to the database, to reduce insertion and query time. Currently these are all installed on SCEC disks and accessed from shock.usc.edu.

[[File:Data_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the data product of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_data_workflow.odg source file (ODG)]]]

=== Load Amps ===

Purpose: Load data from output files into the database.

Detailed description: This code loads either PSA, RotD, or Duration data into the database, depending on command-line options. It also performs sanity checks on the PSA data being inserted: values must be between 0.008 and 8400 cm/s2. If they are less than 0.008, some will still be passed through if it's a small magnitude event at large distances. If this constraint is violated, it will abort. Note that if LoadAmps needs to be rerun, sometimes the database must be cleaned out first, as data from the previous attempt may have inserted successfully and will cause duplicate key errors if you try to insert the same data again.

Needs to be changed if:
#We change the sanity checks on data inserts.
#We modify the format of the PSA, RotD, or Duration files.
#We add new types of data to insert.
#We change the database schema.
#We add a new server. To add a new server, in addition to providing a command-line option for it, you will need to create a Hibernate config file. You can start with moment.cfg.xml or focal.cfg.xml and edit lines 7-16 appropriately.

Source code location: https://github.com/SCECcode/cybershake-core/CyberCommands

Author: Joshua Garcia, Scott Callaghan

Dependencies: LoadAmps calls CyberCommands, a Java code with a long list of dependencies (all of these are checked into the Java project):

*Ant
*Apache Commons
*Hibernate
*MySQL bindings
*Xerces
*DOM4J
*Log4J
*Java 1.6+

Executable chain:
insert_dir.sh
CyberLoadAmps_SC
cybercommands_SC.jar
CyberLoadamps.java

Compile instructions: Check out CyberCommands into Eclipse. Create the cybercommands_SC.jar file using Eclipse's JAR build framework and the cybercommands_SC.jardesc description file. Install cybercommand_SC.jar and the required JAR files on the server. Point insert_dir.sh to CyberLoadAmps_SC to cybercommands_SC.jar.

Usage:
<pre>Usage: CyberLoadAmps [-r | -d | -z | -u][-c] [-d] [-periods periods] [-run RunID] [-p directory] [-server name] [-z] [-help] [-i insertion_values]
[-u] [-f]
-i <insertion_values> Which values to insert -
gm: geometric mean PSA data (default)
xy: X and Y component PSA data
gmxy: Geometric mean and X and Y components
-run <RunID> Run ID - this option is required
-p <directory> file path with spectral acceleration files,
either top-level directory or zip file - this option is required
-server <name> server name (focal, surface, intensity, moment,
or csep-x) - this option is required
-periods <periods> Comma-delimited periods to insert
-c Convert values from g to cm/sec^2
-d Assume one BSA file per rupture, with embedded
header information.
-f Don't apply value checks to insertion values; use
with care!.
-help print this message
-r Read rotd files (instead of bsa.)
-u Read duration files (instead of bsa.)
-z Read zip files instead of bsa.</pre>

Typical run configuration: Serial; for 5 periods, takes about 10 minutes. It's wildly dependent on the database and contention from other database processes.

Input files: [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

Output files: none

=== Check DB Site ===

Purpose: Verify that data was correctly loaded into the database.

Detailed description: This code takes a list of components (or type IDs) to check for a run ID, and verifies that there is one entry for every rupture variation. If some rupture variations are missing, a file is produced which lists the missing source, rupture, rupture variation tuples.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/db/CheckDBDataForSite.java and DBConnect.java

Author: Scott Callaghan (CheckDBDataForSite.java), Nitin Gupta, Vipin Gupta, Phil Maechling (DBConnect.java)

Dependencies: Both are checked into the CyberShake project:

*Apache Commons
*MySQL bindings

Executable chain:
check_db.sh
CheckDBDataForSite.java

Compile instructions: Check out CheckDBDataForSite.java and DBConnect.java. Compile them by running 'javac -classpath mysql-connector-java-5.0.5-bin.jar:commons-cli-1.0.jar DBConnect.java CheckDBDataForSite.java'. The paths to the MySQL bindings jar and the Apache Commons jar may be different depending on your installation.

Usage:
<pre>usage: CheckDBDataForSite
-p <periods> Comma-separated list of periods to check, for geometric
and rotd.
-t <type_ids> Comma-separated list of type IDs to check, for duration.
-c <component> Component type (geometric, rotd, duration) to check.
-h,--help Print help for CheckDBDataForSite
-o <output> Path to output file, if something is missing (required).
-r <run_id> Run ID to check (required).
-s <server> DB server to query against.
</pre>

Typical run configuration: Serial; typically takes just a few seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Missing variations file | Missing variations file]]

=== DB Report ===

Purpose: Produce a database report, a data product which Rob Graves used for a time.

Detailed description: This code takes a run ID, queries the database for PSA values for all components, and writes the output to a text file. The list of periods and the DB config parameters are specified in an XML config file.

Needs to be changed if:
#Username, password, or database host are changed: the DB connection parameters in default.xml would need to be edited.
#We want results for different periods: edit default.xml.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/reports/db_report_gen.py . default.xml in the same directory is also needed, and can be generated by editing and running conf_get.py, also in the same directory.

Author: Kevin Milner

Dependencies: MySQLdb

Executable chain:
db_report_gen.py

Compile instructions: None, all code is Python.

Usage:
<pre>Usage: db_report_gen.py [options] SITE_SHORT_NAME

NOTE: defaults are loaded from defaults.xml and can be edited manually
or overridden with conf_gen.py

Options:
-h, --help show this help message and exit
-e ERF_ID, --erfID=ERF_ID
ERF ID for Report (default = none)
-f FILENAME, --file=FILENAME
Store Results to a file instead of STDOUT. If a
directory is given, a name will be auto generated.
-i, --id Flag for specifying site ID instead of Short Name
(default uses Short Name)
--hypo, --hpyocenter Flag for appending hypocenter locations to result
-l LIMIT, --limit=LIMIT
Limit the total number of rusults, or 0 for no limit
(default = 0)
-o, --sort SLOW: Force SQL Order By statement for sorting. It
will probably come out sorted, but if it doesn't, you
can use this. (default will not sort)
-p PERIODS, --periods=PERIODS
Comma separated period values (default = 3.0,5.0,10.0)
--pr, --print-runs Print run IDs for site and optionally ERF/Rup Var
Scen/SGT Var IDs
-r RUP_VAR_SCENARIO_ID, --rupVarID=RUP_VAR_SCENARIO_ID
Rupture Variation Scenario ID for Report (default =
none)
--ri=RUN_ID, --runID=RUN_ID
Allows you to specify a run ID to use (default uses
latest compatible run ID)
-R RUPTURE, --rupture=RUPTURE
Only give information on specified rupture. Must be
acompanied by -S/--source flag (default shows all
ruptures)
-s SGT_VAR_ID, --sgtVarID=SGT_VAR_ID
SGT Variation ID for Report (default = none)
-S SOURCE, --source=SOURCE
Only give information on specified source. To specify
rupture, see -R option (default shows all sources)
--s_im, --sort-ims Sort output by IM value (increasing)...may be slow!
-v, --verbose Verbosity Flag (default = False)
</pre>

Typical run configuration: Serial; about 1 minute. It's wildly dependent on the database and contention from other database processes.

Input files: default.xml

Output files: [[CyberShake_Code_Base#DB Report file | DB Report file]]

=== Curve Calc ===

Purpose: Calculate CyberShake hazard curves alongside comparison GMPEs.

Detailed description: This code takes a run ID, component, and period, queries the database for the appropriate IM values, and calculates a hazard curve in the desired format. Comparison GMPE curves can also be plotted.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#New IM types need to be supported.

Source code location: The CyberShake curve calculator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.HazardCurvePlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by curve_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/curve_plot_wrapper.sh .

The OpenSHA project also has configuration files for various GMPEs, config files for UCERF2, and configuration files for output formats preferred by Tom and Rob, in src/org/opensha/sha/cybershake/conf.

Author: Kevin Milner

Dependencies: Standard OpenSHA dependencies

Executable chain:
curve_plot_wrapper.sh
HazardCurvePlotter.java

Compile instructions: Use the OpenSHA build process if building from source.

Usage:
<pre>
usage: HazardCurvePlotter [-?] [-af <arg>] [-benchmark] [-c] [-cmp <arg>]
[-comp <arg>] [-cvmvs] [-e <arg>] [-ef <arg>] [-f] [-fvs <arg>] [-h
<arg>] [-imid <arg>] [-imt <arg>] [-n] [-novm] [-o <arg>] [-p
<arg>] [-pf <arg>] [-pl <arg>] [-R <arg>] [-r <arg>] [-s <arg>]
[-sgt <arg>] [-sgtsym] [-t <arg>] [-v <arg>] [-vel <arg>] [-w
<arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship
description file(s) for comparison.
Multiple files should be comma
separated
-benchmark,--benchmark-test-recalc Forces recalculation of hazard
curves to test calculation speed.
Newly recalculated curves are not
kept and the original curves are
plotted.
-c,--calc-only Only calculate and insert the
CyberShake curves, don't make plots.
If a curve already exists, it will
be skipped.
-cmp,--component <arg> Intensity measure component.
Options: GEOM,X,Y,RotD100,RotD50,
Default: GEOM
-comp,--compare-to <arg> Compare to aspecific Run ID (or
multiple IDs, comma separated)
-cvmvs,--cvm-vs30 Option to use Vs30 value from the
velocity model itself in GMPE
calculations rather than, for
example, the Wills 2006 value.
-e,--erf-id <arg> ERF ID
-ef,--erf-file <arg> XML ERF description file for
comparison
-f,--force-add Flag to add curves to db without
prompt
-fvs,--force-vs30 <arg> Option to force the given Vs30 value
to be used in GMPE calculations.
-h,--height <arg> Plot height (default = 500)
-imid,--im-type-id <arg> Intensity measure type ID. If not
supplied, will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-n,--no-add Flag to not automatically calculate
curves not in the database
-novm,--no-vm-colors Disables Velocity Model coloring
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple
periods should be comma separated
(default: 3)
-pf,--password-file <arg> Path to a file that contains the
username and password for inserting
curves into the database. Format
should be "user:pass"
-pl,--plot-chars-file <arg> Specify the path to a plot
characteristics XML file
-R,--run-id <arg> Run ID
-r,--rv-id <arg> Rupture Variation ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-sgtsym,--sgt-colors Enables SGT specific symbols
-t,--type <arg> Plot save type. Options are png,
pdf, jpg, and txt. Multiple types
can be comma separated (default is
pdf)
-v,--vs30 <arg> Specify default Vs30 for sites with
no Vs30 data, or leave blank for
default value. Otherwise, you will
be prompted to enter vs30
interactively if needed.
-vel,--vel-model-id <arg> Velocity Model ID
-w,--width <arg> Plot width (default = 600)
</pre>

Typical run configuration: Serial; about 30 seconds per curve. It's wildly dependent on the database and contention from other database processes.

Input files: ERF config file, GMPE config files

Output files: [[CyberShake_Code_Base#Hazard Curve | Hazard Curve]]

=== Disaggregate ===

Purpose: Disaggregate the curve results to determine the largest contributing sources.

Detailed description: This code takes a run ID, a probability or IM level, and a period to disaggregate at. It produces disaggregation distance-magnitude plots and also a list of the % contribution of each source.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#We want to support different kinds of disaggregation, or for a different kind of ERF.

Source code location: The Disaggregator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.DisaggregationPlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by disagg_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/disagg_plot_wrapper.sh .

Author: Kevin Milner, Nitin Gupta, Vipin Gupta

Dependencies: Standard OpenSHA dependencies

Executable chain:
disagg_plot_wrapper.sh
DisaggregationPlotter.java

Compile instructions: Use the standard OpenSHA building process if building from source.

Usage:
<pre>usage: DisaggregationPlotter [-?] [-af <arg>] [-cmp <arg>] [-e <arg>]
[-fvs <arg>] [-i <arg>] [-imid <arg>] [-imt <arg>] [-o <arg>] [-p
<arg>] [-pr <arg>] [-r <arg>] [-R <arg>] [-s <arg>] [-sgt <arg>]
[-t <arg>] [-vel <arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship description
file(s) for comparison. Multiple files
should be comma separated
-cmp,--component <arg> Intensity measure component. Options:
GEOM,X,Y,RotD100,RotD50, Default: GEOM
-e,--erf-id <arg> ERF ID
-fvs,--force-vs30 <arg> Option to force the given Vs30 value to be
used in GMPE calculations.
-i,--imls <arg> Intensity Measure Levels (IMLs) to
disaggregate at. Multiple IMLs should be
comma separated.
-imid,--im-type-id <arg> Intensity measure type ID. If not supplied,
will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple periods
should be comma separated (default: 3)
-pr,--probs <arg> Probabilities (1 year) to disaggregate at.
Multiple probabilities should be comma
separated.
-r,--rv-id <arg> Rupture Variation ID
-R,--run-id <arg> Run ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-t,--type <arg> Plot save type. Options are png, pdf, and
txt. Multiple types can be comma separated
(default is pdf)
-vel,--vel-model-id <arg> Velocity Model ID
</pre>

Typical run configuration: Serial; typically takes about 30 seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Disaggregation file | Disaggregation file]]

== Stochastic codes ==

With CyberShake, we also have the option to augment a completed run with stochastic seismograms. The following codes are used to add stochastic high-frequency content to an already-completed low-frequency deterministic run.

[[File:stochastic workflow overview.png|thumb|right|300px|Overview of the codes involved in the stochastic part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/stochastic_workflow_overview.odg source file (ODG)]]]

=== Velocity Info ===

Purpose: To determine slowness-averaged VsX values for a CyberShake site, from UCVM.

Detailed description: Velocity Info takes a location, a velocity model, and grid spacing information and queries UCVM to generate three VsX values needed by the site response:
#Vs30, calculated as: 30 / sum( 1 / (Vs sampled from [0.5, 29.5] at 1 meter increments, for 30 values) )
#Vs5H, like Vs30 but calculated over the shallowest 5*gridspacing meters. So if gridspacing=100m, Vs5H = 500 / sum( 1 / (Vs sampled from [0.5, 499.5] at 1 meter increments, for 500 values) )
#VsD5H, like Vs30, but calculated over gridspacing increments, instead of 1 meter. The start and end are weighted half as much. So if gridspacing=100m, VsD5H = 5 / sum( 0 / (Vs sampled from [0, 500] at 1 meter increments, for 500 values) )

Needs to be changed if:
#We need to support more than one model - for instance, if the CyberShake site box (not simulation volume) spans multiple models. The code to parse the model string and load models in initialize_ucvm() would need to be changed.
#We want to support new kinds of velocity values.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/src/retrieve_vs.c

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM | UCVM]]

Executable chain:
retrieve_vs

Compile instructions:Run 'make retrieve_vs'

Usage:
<pre>Usage: ./retrieve_vs <lon> <lat> <model> <gridspacing> <out filename></pre>

Typical run configuration: Serial; takes about 15 seconds.

Input files: None

Output files: [[CyberShake_Code_Base#Velocity_Info file|Velocity Info file]]

=== Local VM ===

Purpose: To generate a "local" 1D velocity file, required for the high-frequency codes.

Detailed description: Local VM takes in an input file containing a 1D velocity model. It then calculates Qs from these values and writes all the velocity data to a new file. For all Study 15.12 runs, we used the LA Basin 1D model from the BBP, v14.3.0. It's registered in the RLS, and is located at /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod.

Needs to be changed if:
#We change the algorithm for calculating Vs.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/gen_local_vel.py

Author: Scott Callaghan, modified from Rob Graves' code

Dependencies: None

Executable chain:
gen_local_vel.py

Compile instructions: None

Usage:

<pre>Usage: ./gen_local_vel.py <1D velocity model> <output></pre>

Typical run configuration: Serial; takes less than a second.

Input files: [[CyberShake_Code_Base#BBP velocity file|BBP 1D velocity file]]

Output files: [[CyberShake_Code_Base#Local VM file|Local VM file]]

=== Create Dirs ===

Purpose: To create a directory for each source.

Detailed description: The high-frequency codes produce many intermediate files. To avoid overloading the filesystem, Create Dirs creates a separate directory for every source.

Needs to be changed if: This code is basically just a wrapper around mkdir, and is unlikely to need changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/create_dirs.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
create_dirs.py

Compile instructions: None

Usage:
<pre>
Usage: ./create_dirs.py <file with list of dirs>
</pre>

Typical run configuration: Serial, takes just a few seconds.

Input files: File with a directory to create (a source ID) on each line.

Output files: None.

=== HF Synth ===

Purpose: HF Synth generates a high-frequency stochastic seismogram for one or more rupture variations.

Detailed description: This code wraps multiple broadband platform codes to reduce the number of invocations required. Specifically, it calls:
#srf2stoch_lite(), a reduced-memory version of srf2stoch. We have modified it to call rupgen_genslip() to generate the SRF, rather than reading it in from disk.
#hfsim(), a wrapper for:
##hb_high(), Rob Graves's original BBP code to produce the seismograms
##wcc_getpeak(), which calculates PGA for the seismogram
##wcc_siteamp14(), which performs site amplification.

Vs30 is required, so if it is not passed as a command-line argument, UCVM is called to determine it.

Additionally, hf_synth_lite is able to handle processing on multiple rupture variations, to further reduce the number of invocations.

Needs to be changed if:
#A new version of one of Rob's codes - the high-frequency generator or the site amplification - is needed. We have tried to use whatever the most recent version is on the BBP, for consistency.
#New velocity parameters are needed for the site amplification.
#The format of the rupture geometry files changes.

The makefile needs to be changed if the path to libmemcached, UCVM, Getpar, or the rupture generator changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem

Author: wrapper by Scott Callaghan, hb_high(), wcc_getpeak(), and wcc_siteamp14() by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
hf_synth_lite

Compile instructions: Run 'make' in src.

Usage: There is no 'help' usage string, but here's a sample invocation:
<pre>
/projects/sciteam/jmz/CyberShake/software/HFSim_mem/bin/hf_synth_lite
stat=OSI slat=34.6145 slon=-118.7235
rup_geom_file=e36_rv6_121_0.txt source_id=121 rupture_id=0
num_rup_vars=5 rup_vars=(0,0,0);(1,1,0);(2,2,0);(3,3,0);(4,4,0)
outfile=121/Seismogram_OSI_4331_121_0_hf_t0.grm
dx=2.0 dy=2.0 tlen=300.0 dt=0.025
do_site_response=1 vs30=359.1 debug=0 vmod=LA_Basin_BBP_14.3.0.local
</pre>

Typical run configuration: Serial; takes a few seconds per rupture variation up to a minute, depending on the size of the fault surface.

Input files: [[CyberShake_Code_Base#Local_VM_file | Local velocity file]], [[CyberShake_Rupture_Files#UCERF2_Rupture_Geometry_Files | rupture geometry file]]

Output files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Combine HF Synth ===

Purpose: This code combines the seismograms produced by HF Synth so that there is just 1 seismogram per source/rupture combo.

Detailed description: Since we split up work so that each HF Synth job takes a chunk of rupture variations, we may end up with multiple seismogram files per rupture, each containing some of the rupture variations. This script concatenates the files, using cat, into a single file, ready to be worked on later in the workflow.

Needs to be changed if: I can't think of a circumstance where we would need to change this.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/combine_seis.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
combine_seis.py
cat

Compile instructions: None

Usage:
<pre>
Usage: ./combine_seis.py <seis 0> <seis 1> ... <seis N> <output seis name>
</pre>

Typical run configuration: Serial; takes a few seconds.

Input files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A single high-frequency seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== LF Site Response ===

Purpose: This code performs site response modifications to the CyberShake low-frequency seismograms.

Detailed description: The LF Site Response code takes a low-frequency seismogram and some velocity parameters, and outputs a seismogram with site response applied. In Study 15.12, this was a necessary step before combining the low and high frequency seismograms together. Since Vs30 is required, if it's not passed as a command-line argument, then UCVM is called to determine it.

The reason we calculate site response for the low-frequency deterministic seismograms is that we want both the low- and high-frequency results to be for the same site-response condition. For the HF, we used Vs30 directly
for the site-response adjustment, but for the LF we had to use an adjusted VsX value since the grid spacing was 100 m (so Vs30 doesn't make sense).

Needs to be changed if:
#We change the site response algorithm.
#We decide to use different velocity parameters for setting site response.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/LF_Site_Response

Author: wrapper by Scott Callaghan, site response by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
lf_site_response

Compile instructions: Edit the makefile to point to RupGen, libmemcached, and Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./lf_site_response
seis_in=Seismogram_OSI_3923_263_3.grm seis_out=263/Seismogram_OSI_3923_263_3_site_response.grm
slat=34.6145 slon=-118.7235
module=cb2014
vs30=359.1 vref=344.7
</pre>

Typical run configuration: Serial; takes less than a second.

Input files: A low-frequency deterministic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A low-frequency deterministic seismogram with site response, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Merge IM ===

Purpose: This code combines low-frequency deterministic and high-frequency stochastic seismograms, then processes them to obtain intensity measures.

Detailed description: The Merge IM code takes an LF and HF seismogram and performs the following processing:
#A high-pass filter is applied to the HF seismogram.
#The LF seismogram is resampled to the same dt as the HF seismogram.
#The two seismograms are combined into a single broadband (BB) seismogram.
#The PSA code is run on the resulting seismogram.
#If desired, the RotD and duration codes are also run on the seismogram.

Merge IM works on a seismogram file at the rupture level, so it assumes that the input files contain multiple rupture variations.

Needs to be changed if:
#We change the filter-and-combine algorithm.
#We decide to modify the post-processing and IM types we want to capture.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/MergeIM

Author: Scott Callaghan, Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]]

Executable chain:
merge_psa

Compile instructions: Edit the makefile to point to Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./merge_psa
lf_seis=182/Seismogram_OSI_3923_182_23_site_response.grm hf_seis=182/Seismogram_OSI_4331_182_23_hf.grm seis_out=182/Seismogram_OSI_4331_182_23_bb.grm
freq=1.0 comps=2 num_rup_vars=16
simulation_out_pointsX=2 simulation_out_pointsY=1
simulation_out_timesamples=12000 simulation_out_timeskip=0.025
surfseis_rspectra_seismogram_units=cmpersec surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=20.0 surfseis_rspectra_apply_byteswap=no
out=182/PeakVals_OSI_4331_182_23_bb.bsa
run_rotd=1 rotd_out=182/RotD_OSI_4331_182_23_bb.rotd
run_duration=1 duration_out=182/Duration_OSI_4331_182_23_bb.dur
</pre>

Typical run configuration: Serial; takes 5-30 seconds, depending on the number of rupture variations in the files.

Input files: LF deterministic seismogram and HF stochastic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: BB seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]]; also [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], and [[Accessing_CyberShake_Duration_Data | Duration files]]

== File types ==

=== Modelbox ===

Purpose: Contains a description of the simulation box, at the surface.

Filename convention: <site>.modelbox

Format:
<pre>
<site name>
APPROXIMATE CENTROID:
clon= <centroid lon> clat =<centroid lat>
MODEL PARAMETERS:
mlon= <model lon> mlat =<model lat> mrot=<model rot, default -55> xlen= <x-length in km> ylen= <y-length in km>
MODEL CORNERS:
<lon 1> <lat 1> (x= 0.000 y= 0.000)
<lon 2> <lat 2> (x= <max x> y= 0.000)
<lon 3> <lat 3> (x= <max x> y= <max y>)
<lon 4> <lat 4> (x= 0.000 y= <max y>)
</pre>

Generated by: PreCVM

Used by: PreSGT, PostAWP

=== Gridfile ===

Purpose: Specify the three dimensions, and gridspacing in each dimension, of the volume.

Filename convention: gridfile_<site>

Format:
<pre>
xlen=<x-length in km>
0.0 <x-length> <grid spacing in km>
ylen=<y-length in km>
0.0 <y-length> <grid spacing in km>
zlen=<z-length in km>
0.0 <z-length> <grid spacing in km>
</pre>

=== Gridout ===

Purpose: Specify the km offsets for each grid index, in X, Y, and Z, from the upper southwest corner.

Filename convention: gridout_<site>

Format:
<pre>
xlen=<x-length in km>
nx=<number of gridpoints in X direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
2 <2*grid spacing> <grid spacing>
3 <3*grid spacing> <grid spacing>
...
nx-1 <(nx-1)*grid spacing> <grid spacing>
ylen=<y-length in km>
ny=<number of gridpoints in Y direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
ny-1 <(ny-1)*grid spacing> <grid spacing>
zlen=<z-length in km>
nz=<number of gridpoints in Z direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
nz-1 <(nz-1)*grid spacing> <grid spacing>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT, PreAWP

=== Params ===

Purpose: Succinctly specify the parameters for the CyberShake volume. Similar information to the modelbox file, but in a different format.

Filename convention: model_params_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
Model origin coordinates:
lon= <model lon> lat= <model lat> rotate= <model rotation, default -55>

Model origin shift (cartesian vs. geographic):
xshift(km)= <x shift, usually half the x-length minus 1 grid spacing> yshift(km)= <y-shift, usually half the y-length minus 1 grid spacing>

Model corners:
c1= <nw lon> <nw lat>
c2= <ne lon> <ne lat>
c3= <se lon> <se lat>
c4= <sw lon> <sw lat>

Model Dimensions:
xlen= <x-length> km
ylen= <y-length> km
zlen= <z-length> km
</pre>

Generated by: PreCVM

Used by:

=== Coord ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, for each point on the surface.

Filename convention: model_coords_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
...
<lon> <lat> <nx-1> 1
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT

=== Bounds ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, but only for the points along the boundary. A subset of the coord file.

Filename convention: model_bounds_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
<lon> <lat> <nx-1> 1
<lon> <lat> 0 2
<lon> <lat> <nx-1> 2
...
<lon> <lat> 0 <ny-1>
<lon> <lat> 1 <ny-1>
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by:

=== Velocity files ===

==== RWG format ====

Purpose: Input velocity files for the RWG wave propagation code, emod3d.

Filename convention: v_sgt-<site>.<p, s, or d>

Format: 3 files, one each for Vp (*.p), Vs (*.s), and rho (*.d). Each is binary, with 4-byte floats, in fast X, Z (surface->down), slow Y order.

Generated by: UCVM

Used by: PreAWP

==== AWP format ====

Purpose: Input velocity file for the AWP-ODC wave propagation code.

Filename convention: awp.<site>.media

Format: Binary, with 4-byte floats, in fast Y, X, slow Z (surface down) order.

Generated by: UCVM

Used by: Smoothing, PreAWP, PostAWP

=== Fdloc ===

Purpose: Coordinates of the site, in X Y grid indices, and therefore the coordinates where the SGT impulse should be placed.

Filename convention: <site>.fdloc

Format:
<pre>
<X grid index of site> <Y grid index of site>
</pre>

Generated by: PreSGT

Used by: PreAWP, PostAWP

=== Faultlist ===

Purpose: List of paths to all the rupture geometry files for all ruptures which are within the cutoff for this site. Used to produce a list of points to save SGTs for.

Filename convention: <site>.faultlist

Format:
<pre>
<path to rupture file> nheader=<number of header lines, usually 6> latfirst=<1, to signify that latitude comes first in the rupture files>
...
</pre>

Generated by: PreSGT

Used by: PreSGT

=== Radiusfile ===

Purpose: Describe the adaptive mesh SGTs will be saved for.

Filename convention: <site>.radiusfile

Format:
<pre>
<number of gradations in X and Y>
<radius 1> <radius 2> <radius 3> <radius 4>
<decimation less than radius 1> <decimation between radius 1 and 2> <between 2 and 3> <between 3 and 4>
<number of gradations in Z>
<depth 1> <depth 2> <depth 3> <depth 4>
<decimation less than depth 1> <decimation between depth 1 and 2> <between 2 and 3> <between 3 and 4>
</pre>

Generated by: PreSGT

Used by: PreSGT

=== SGT Coordinate files ===

There are two formats for the list of points to save SGTs for, one for Rob's codes and one for AWP-ODC. As with other coordinate transformations between the two systems, to convert X and Y offsets from RWG to AWP you have to flip the X and Y and add 1 to each, since RWG is 0-indexed and AWP is 1-indexed.

==== SgtCoords ====

Purpose: List of all the points to save SGTs for.

Filename convention: <site>.cordfile

Format: Z changes fastest, then Y, then X slowest.
<pre>
# geoproj= <projection; we usually use 1 for great circle>
# modellon= <model lon> modellat= <model lat> modelrot= <model rot, usually -55>
# xlen= <x-length> ylen= <y-length>
#
<total number of points>
<X index> <Y index> <Z index> <Single long to capture the index, in the form XXXXYYYYZZZZ> <lon> <lat> <depth in km>
...
</pre>

Generated by: PreSGT

Used by: PreSGT, PreAWP, PostAWP

==== AWP cordfile ====

Purpose: List of SGT points to save in a format usable by AWP-ODC-SGT.

Filename convention: awp.<site>.cordfile

Format: Remember that X and Y are flipped and have 1 added from RWG. The points are sorted by Y, then X, then Z, so Y changes slowest and Z changes fastest. This is flipped from the RWG cordfile because X and Y components are swapped.
<pre>
<number of points>
<X coordinate> <Y coordinate> <Z coordinate>
...
</pre>

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== Impulse source descriptions ===

We generate the initial source description for CyberShake, with the required dt, nt, and filtering, using gen_source, in https://github.com/SCECcode/cybershake-core/SimSgt_V3.0.3/src/ (run 'make get_source'). gen_source hard-codes its parameters, but you should only change 'nt', 'dt', and 'flo'. We have been setting flo to twice the CyberShake maximum frequency, to reduce filtering affects at the frequency of interest. gen_source wraps Rob Graves's source generator, which we use for consistency.

To generate a source for a component, run
<pre>
$>./gen_source xsrc=0 ysrc=0 zsrc=0 <fxsrc|fysrc|fzsrc>=1 moment=1e20
</pre>

Once this RWG source is generated, we then use AWP-GPU-SGT/utils/data/format_source.py to reprocess the RWG source into an AWP-source friendly format. This involves reformatting the file and multiplying all values by 1e15 for unit conversion. Different files must be produced for X and Y coordinates, since in the AWP format different columns are used for different components.

Finally, AWP-GPU-SGT/utils/build_src.py takes the correct AWP-friendly source (nt and dt) for a run and adds the impulse location coordinates, producing a complete AWP format source description.

==== RWG source ====

Purpose: Source description for the SGT impulse.

Filename convention: source_cos0.10_<frequency>hz

Format:
<pre>
source cos
<nt> <dt> 0 0 0.0 0.0 0.0 0.0
<value at ts0> <value at ts1> <value at ts2> <value at ts3> <value at ts4> <value at ts5>
<value at ts6> <value at ts7> <value at ts8> <value at ts9> <value at ts10> <value at ts11>
...
</pre>

Generated by: gen_source (see above)

Used by: PreAWP

==== AWP source ====

Purpose: Source description which can be used by AWP-ODC.

Filename convention: <site>_f<x or y>_src

Format: Note that X and Y coordinates are swapped between RWG and AWP format, because of how the box is defined. Additionally, RWG is 0-indexed, and AWP is 1-indexed, and the RWG values must be multiplied by 1e15 for unit conversion.
<pre>
<X index of source, same as site X index> <Y index of source, same as site Y index>
<XX impulse at ts0> <YY at ts0> <ZZ at ts0> <XY at ts0> <XZ at ts0> <YZ at ts0>
...
</pre>
Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== IN3D ===

Purpose: Input file for AWP-ODC.

Filename convention: IN3D.<site>.<x or y>

Format: Specified [https://scec.usc.edu/it/AWP-ODC-SGT#IN3D here (login required)].

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU, PostAWP

=== AWP SGT ===

Purpose: SGT file, created by AWP-ODC-SGT.

Filename convention: awp-strain-<site>-f<x or y>

Format: binary, 4-byte floats. Points are in the same order as in the AWP SGT coordinate file, which is fast Z, X, Y. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: AWP-ODC-SGT CPU and GPU

Used by: PostAWP, NanCheck

=== RWG SGT ===

Purpose: SGT file, created by PostAWP for use in post-processing.

Filename convention: <site>_f<x or y>_<run id>.sgt

Format: binary, 4-byte floats. Points are in the same order as in the RWG coordinate file, which is fast Z, Y, X. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: PostAWP

Used by: CheckSgt, DirectSynth

=== SGT header file ===

Purpose: SGT header information, used to parse and understand SGT files

Filename convention: <site>_f<x or y>_<run id>.sgthead

Format: binary. It consists of three sections:

<ol>
<li>The sgtmaster structure, described below in C. Its information can be used to set up data structures to read the rest of the SGTs.</li>
<pre>
struct sgtmaster
{
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int globnp; /* total number of SGT locations (entire model) */
int localnp; /* local number of SGT locations (this file only) */
int nt; /* number of time points */
};
</pre>
<li>The sgtindex structures, described below in C. There is one of these for each point in the SGTs, and they're used to determine the X/Y/Z indices of all the SGT points. Note that the current way of packing the X,Y,Z coordinates into the long allows for 6 digits (so maximum 1M grid points) for each component.</li>
<pre>
struct sgtindex /* indices for all 'globnp' SGT locations */
{
long long indx; /* indx= xsgt*1000000000000 + ysgt*1000000 + zsgt */
int xsgt; /* x grid location */
int ysgt; /* y grid location */
int zsgt; /* z grid location */
float h; /* grid spacing */
};
</pre>
<li>The sgtheader structures, described below in C. There is one of these for each point in the SGTs. They're used when we perform reciprocity.</li>
<pre>
struct sgtheader
{
long long indx; /* index of this SGT */
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int nt; /* number of time points */
float xazim; /* azimuth of X-axis in FD model (clockwise from north) */
float dt; /* time sampling */
float tst; /* start time of 1st point in GF */
float h; /* grid spacing */
float src_lat; /* site latitude */
float src_lon; /* site longitude */
float src_dep; /* site depth */
int xsrc; /* x grid location for source (station in recip. exp.) */
int ysrc; /* y grid location for source (station in recip. exp.) */
int zsrc; /* z grid location for source (station in recip. exp.) */
float sgt_lat; /* SGT location latitude */
float sgt_lon; /* SGT location longitude */
float sgt_dep; /* SGT location depth */
int xsgt; /* x grid location for output (source in recip. exp.) */
int ysgt; /* y grid location for output (source in recip. exp.) */
int zsgt; /* z grid location for output (source in recip. exp.) */
float cdist; /* straight-line distance btw site and SGT location */
float lam; /* lambda [in dyne/(cm*cm)] at output point */
float mu; /* rigidity [in dyne/(cm*cm)] at output point */
float rho; /* density [in gm/(cm*cm*cm)] at output point */
float xmom; /* moment strength of x-oriented force in this run */
float ymom; /* moment strength of y-oriented force in this run */
float zmom; /* moment strength of z-oriented force in this run */
};
</pre>
</ol>

Overall, then, the format for the file is:
<pre>
<sgtmaster>
<sgtindex for point 1>
<sgtindex for point 2>
...
<sgtindex for point globnp>
<sgtheader for point 1>
<sgtheader for point 2>
...
<sgtheader for point globnp>
</pre>

Generated by: PostAWP

Used by: DirectSynth

=== Velocity Info file ===

Purpose: Contains the 3D velocity information needed for stochastic jobs

Filename convention: velocity_info_<site>.txt

Format: Text format, three lines:

<pre>
Vs30 = <Vs30 value>
Vs500 = <Vs500 value>
VsD500 = <VsD500 value>
</pre>

Generated by: Velocity Info job

Used by: Sub Stoch DAX generator, to add these values as command-line arguments to HF Synth and LF Site Response jobs.

=== rupture list file ===

Purpose: Contains a list of all the ruptures for which low-frequency seismograms should be synthesized. This file is used to construct the tasks in DirectSynth. The number of rows, columns, and magnitude are included because DirectSynth uses this information to determine how much memory the tasks will use. This file is constructed at abstract workflow creation time.

Filename convention: rupture_file_list_<site>_<run_id>

Format: Text format, with the number of ruptures and then 1 line per rupture:

<pre>
<number of ruptures N>
<rupture geometry filename 1> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
<rupture geometry filename 2> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
...
<rupture geometry filename N> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
</pre>

Used by: DirectSynth

=== rupture variation info file ===

Purpose: This file provides the rvfrac (rupture velocity speed as a fraction of shear wave velocity) and random seed for each rupture variation. It is constructed at abstract workflow creation time, using values from the database. It is highly recommended that these values are stored somewhere for reproducibility, and the same values should be used for all sites so that the rupture variations are the same for all sites.

Filename convention: rvfrac_seed_values_<site>_<run_id>

Format: Text format, with the number of rupture variations and then 1 line per rupture variation:

<pre>
<number of rupture variations N>
<source ID 1> <rupture ID 1> <rupture variation ID 1> <rvfrac> <random seed>
<source ID 2> <rupture ID 2> <rupture variation ID 2> <rvfrac> <random seed>
...
<source ID N> <rupture ID N> <rupture variation ID N> <rvfrac> <random seed>
</pre>

Used by: DirectSynth, when linked with RupGen-v5.5.2 or later

=== BBP 1D Velocity file ===

Purpose: Contains 1D velocity profile information

Filename convention: The only one currently in use in CyberShake is /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <not used> <not used>
<layer 2 thickness in km> <Vp> <Vs> <density> <not used> <not used>
...
<layer L thickness in km> <Vp> <Vs> <density> <not used> <not used>
</pre>

Note that the last layer has thickness 999.0.

Generated by: Rob Graves

Used by: Local VM job

=== Local VM file ===

Purpose: Contains 1D velocity profile information for use with stochastic codes

Filename convention: The only one currently in use in CyberShake is LA_Basin_BBP_14.3.0.local .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
<layer 2 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
...
<layer L thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
</pre>

Note that the last layer has thickness '0.0', indicating it has no bottom.

Generated by: Local VM Job

Used by:

=== Missing variations file ===

Purpose: Lists the variations which the Check DB stage has found are missing.

Filename convention: DB_Check_Out_<PSA or RotD or Duration>_<site>

Format: For each source and rupture pair with missing variations, the following record is output in text format:

<pre>
<source ID> <rupture ID> <number N of missing rupture variations>
<ID of first missing rupture variation>
<ID of second missing rupture variation>
...
<ID of Nth missing rupture variation>
</pre>

Originally, a file in this format could be directly fed back into the DAX generator, but that capability has not been used for many years and may not still be functional.

Generated by: Check DB Site

Used by: none

=== DB Report file ===

Purpose: Provides PSA data for a run in a text format.

Filename convention: <site>_ERF<erf id>_report_<date>.txt

Format: It's a text file with the following header:
Site_Name ERF_ID Source_ID Rupture_ID Rup_Var_ID Rup_Var_Scenario_ID Mag Prob Grid_Spacing Num_Rows Num_Columns Period Component SA
The file is sorted by fast Rup_Var_ID, Rupture_ID, Source_ID, Period, slow Component.

Generated by: DB Report

Used by: none, output data product

=== Hazard Curve ===

Purpose: Contains a hazard curve, either in text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run id>_<IM type>_<period>sec_<IM component>_<date run completed>.<pdf|txt|png>

Format: The PNG and PDF formats contain an image of the curve. The PDF format also has an extended legend. The TXT file contains a list of (X,Y) points which describe the curve.

Generated by: Curve Calc

Used by: none, output data product

=== Disaggregation file ===

Purpose: Contains disaggregation results for a single run, in either text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run_id>_Disagg<POE|IM>_<disagg level>_<IM type>_<period>sec_<run date>.<txt|png|pdf>

Format: The PNG and PDF formats contain a plot of the disaggregation results, showing magnitude vs distance and color-coding based on epsilon. The PDF and TXT formats contain additional information about individual source contributions, in the following format:

<pre>Summary data
Parameters used to create disaggregation
Disaggregation bin data:
Dist Mag <breakout by epsilon values>
<Breakdown of contribution by distance, magnitude, and epsilon range>

Disaggregation Source List Info:
Source# %Contribution TotExceedRate SourceName DistRup DistX DistSeis DistJB
<list of contributing sources, in decreasing order of % contribution>
</pre>

Generated by: Disaggregation

Used by: none, output data product

== Dependencies ==

The following are external software dependencies used by CyberShake software modules.

=== Getpar ===

Purpose: A library written in C which enables parsing of key-value command-line parameters, and enforcement of required parameters. Rob Graves uses it in his codes.

How to obtain: Rob supplied a copy; it is in the CyberShake repository at https://github.com/SCECcode/cybershake-core/tree/main/Getpar .

Special installation instructions: Run 'make' in Getpar/getpar/src; this will make the library, libget.a, and install it in the lib directory, where CyberShake codes will expect it.

=== MySQLdb ===

This library has been deprecated in favor of pymysql.

=== pymysql ===

Purpose: MySQL bindings for Python.

How to obtain: pip3 install pymysql . Documentation is at https://pypi.org/project/PyMySQL/ .

Special installation instructions: None; pip3 shouldn't have any issues.

=== UCVM ===

Purpose: Supplies the query tools needed to populate a mesh with velocity information.

How to obtain: The most recent version of UCVM can be found at [[UCVM#Current_UCVM_Software_Releases|Current UCVM Software Releases]]. As of October 2017, we have only integrated the C version of UCVM into CyberShake.

Special installation instructions: Following the standard installation instructions for a cluster should work (running ./ucvm_setup.py). You will want to install CVM-S4, CVM-S426, CVM-S4.M01, CVM-H, CenCal, CCA-06, and CCA 1D velocity models for CyberShake.

=== libcfu ===

Purpose: Provides a hash table library for a variety of CyberShake codes.

How to obtain: https://sourceforge.net/projects/libcfu/ . Documentation is at http://libcfu.sourceforge.net/libcfu.html .

Special installation instructions: Follow the instructions, and install into the utils directory.

=== FFTW ===

Purpose: Library which provides FFTs.

How to obtain: Typically installed on supercomputers already, though you may need to load a module to activate it.

Special installation instructions: Doesn't need to be installed in user space.

=== memcached ===

Purpose: Server library for running a memory caching system, using key-value pairs.

How to obtain: Download from https://memcached.org/ .

Special installation instructions: Follow instructions and install in utils directory. It has a dependency on libevent, which you may have to install also.

=== libmemcached ===

Purpose: Client library and tools for memcached server.

How to obtain: Download from http://libmemcached.org/libMemcached.html . Install memcached first.

Special installation instructions: Sometimes installing can be a challenge, because it can't find the memcached install. You may have to set the path to memcached either as an argument to configure, or you may even need to edit the configuration and makefiles directory. Install into the utils directory.

=== RupGen-api ===

Purpose: To generate rupture variations from a rupture geometry for a given hypocenter and slip using the Graves & Pitarka rupture generator. The current version is 5.5.2.

How to obtain: Check out from https://github.com/SCECcode/cybershake-core/tree/main/RuptureCodes/RupGen-api-5.5.2 .

Special installation instructions:

#This code is dependent on FFTW. You may need to edit the makefile to point to the FFTW include files and libraries, since different clusters often use different environment variables to capture FFTW paths.
#If you want memcached support, edit the makefile in RuptureCodes/RupGen-api-5.5.2/src to uncomment lines 19-21 and edit line 19 to point to the libmemcached install directory. You'll need to do the same to RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.0/makefile, lines 35-37.
#You may need to edit CFLAGS in RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.5.2/makefile (lines 21-23) to point to the FFTW path; whether or not this is needed depends on the particular system.
#Run 'make' in RupGen-api-5.5.2 to make the librupgen.a library.

=== SCEC Broadband Platform ===

Purpose: To generate high-frequency stochastic seismograms for broadband CyberShake runs.

How to obtain: Follow installation instructions at https://github.com/SCECcode/bbp .

CyberShake Code Base

2025-11-26T19:44:04Z

Scottcal: /* File types */

This page details all the pieces of code which make up the CyberShake code base, as of November 2017. Note that this does not include the workflow middleware, or the workflow generators; that code is detailed at [[CyberShake Workflow Framework]].

Conceptually, we can divide up the CyberShake codes into three categories:

#Strain Green Tensor-related codes: These codes produce the input files needed to generate SGTs, actually calculate the SGTs, and do some reformatting and sanity checks on the results.
#Synthesis-related codes: These codes take the SGTs and perform seismogram synthesis and intensity measure calculations.
#Data product codes: These codes insert the results into the database, and use the database to generate a variety of output data products.

Below is a description of each piece of software we use, organized by these categories. For each piece of software, we include a description of where it is located, how to compile and use it, and what its inputs and outputs are. At the end, we provide a description of input and output files and formats.

== Code Installation ==

Historically, we have selected a root directory for CyberShake, then created the subdirectories 'software' for all the code, 'ruptures' for the rupture files, 'logs' for log files, and 'utils' for workflow tools. This is typically set up in unpurged storage space, so once installed purging isn't a worry. Each code listed below, along with the configuration file, should be checked out into the 'software' subdirectory.

In terms of compilers, you should use the GNU compilers unless specifically directed otherwise.

Most of the codes below contain a main directory. Inside that is a bin directory, with binaries; a src directory with code requiring compilation; and wrappers, in the main directory.

If you are looking for compilation instructions, a general guide is available [[CyberShake compilation guide | here]].

=== Configuration file ===

Many CyberShake codes use a configuration file, which specifies the root directory for the CyberShake installation, the command use to start an MPI executable, paths to a tmp and scratch space (which can be the same), and the path to the CyberShake rupture directory. We have done this instead of environment variables because it's more transparent and easier for multiple users. Both of these files should be stored in the 'software' subdirectory.

The configuration file is available at:
https://github.com/SCECcode/cybershake-core/cybershake.cfg
Obviously, this file must be edited to be correct for the install.

The keys that CyberShake currently expects to find are:
*CS_PATH = /path/to/CyberShake/software/directory
*SCRATCH_PATH = /path/to/shared/scratch
*TMP_PATH = /path/to/tmp (can be node-local, or shared with scratch
*RUPTURE_PATH = /path/to/CyberShake/rupture/directory
*MPI_CMD = ibrun or aprun or mpiexec
*LOG_PATH = /path/to/CyberShake/logs/directory

To interact with cybershake.cfg, the CyberShake codes use a Python script to deliver cybershake.cfg entries as key-value pairs, located here:
https://github.com/SCECcode/cybershake-core/config.py
Several CyberShake codes import config, then use it to read out the cybershake.cfg file.

=== Compiler file ===

A long time ago, Gideon Juve created a compiler file, Compilers.mk, which contains information about which compilers should be used for which system. This file should also be downloaded using 'svn export' and installed in the software directory, from
https://github.com/SCECcode/cybershake-core/Compilers.mk

Some of the makefiles reference this file. This can - and should - be updated to reflect new systems.

== SGT-related codes ==

[[File:SGT_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the SGT part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_SGT_workflow.odg source file (ODG)]]]

=== PreCVM ===

This code stands for "Pre-Community-Velocity-Model". It has to be run before the UCVM codes, since it generates input files required by UCVM.

Purpose: To determine the simulation volume for a particular CyberShake site.

Detailed description: PreCVM queries the CyberShake database to determine all of the ruptures which fall within a given cutoff for a certain site. From that information, padding is added around the edges to construct the CyberShake simulation volume for this site. Additional padding so the X and Y dimensions are multiples of 10, 20, or 40 might also be applied, depending on the input parameters. Using this volume, both the X/Y offset of each grid point, and then the latitude and longitude using a great circle projection, are determined and written to output files.

Needs to be changed if:
#The CyberShake volume depth needs to be changed, so as to have the right number of grid points. That is set in the genGrid() function in GenGrid_py/gen_grid.py, in km.
#X and Y padding needs to be altered. That is set using 'bound_pad' in Modelbox/get_modelbox.py, around line 70.
#The rotation of the simulation volume needs to be changed. That is set using 'model_rot' in Modelbox/get_modelbox.py, around line 70.
#The database access parameters have changed. That's in Modelbox/get_modelbox.py, around line 80.
#The divisibility needs for GPU simulations change (currently, we need the dimensions to be evenly divisible by the number of GPUs used in that dimension. That is in Modelbox/get_modelbox.py, around line 250.

Source code location: https://github.com/SCECcode/cybershake-core/PreCVM/

Author: Rob Graves, wrapped by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
pre_cvm.py
Modelbox/get_modelbox.py
Modelbox/bin/gcproj
GenGrid_py/gen_grid.py
GenGrid_py/bin/gen_model_cords

Compile instructions:Run 'make' in the Modelbox/src and the GenGrid_py/src directories.

Usage:
<pre>Usage: pre_cvm.py [options]
Options:
-h, --help show this help message and exit
--site=SITE Site name
--erf_id=ERF_ID ERF ID
--modelbox=MODELBOX Path to modelbox file (output)
--gridfile=GRIDFILE Path to gridfile (output)
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coorfile (output)
--paramsfile=PARAMSFILE
Path to paramsfile (output)
--boundsfile=BOUNDSFILE
Path to boundsfile (output)
--frequency=FREQUENCY
Frequency
--gpu Use GPU box settings.
--spacing=SPACING Override default spacing with this value.
--server=SERVER Address of server to query in creating modelbox,
default is focal.usc.edu.</pre>

Typical run configuration: Serial; requires 6 minutes for 100m spacing, 10 billion point volume

Input files: None; inputs are retrieved from the database

Output files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridfile|gridfile]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Params|params]], [[CyberShake_Code_Base#Coord|coord]], [[CyberShake_Code_Base#Bounds|bounds]]

=== UCVM ===

Purpose: To generate a populated velocity mesh for a CyberShake simulation volume.

Detailed description: UCVM takes the volume defined by PreCVM and queries the [[UCVM]] software, using the C API, to populate the volume. The resulting mesh is then checked for Vp/Vs ratio, minimum Vp/Vs/rho, and for no Infs or NaNs. The data is outputted in either Graves (RWG) format or AWP format. This code also produces log files, which will be written to the CyberShake logs directory/GenLog/site/v_mpi-<processor number>.log. This can be useful if there's an error and you aren't sure why.

Needs to be changed if:
#New velocity models are added. Velocity models are specified in the DAX and passed through the wrapper scripts into the C code and then ultimately to UCVM, so an if statement must be added to around line 250 (and around line 450 if it's applicable for no GTL).
#The backend UCVM substantially changes. If we move to the Python implementation, for example.
#If additional models are added, new libraries may need to be added to the makefile.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
single_exe.py
single_exe.csh
bin/ucvm-single-mpi

Compile instructions:The makefile needs to be edited so that "UCVM_HOME" points to the UCVM home directory. Then run 'make' in the UCVM/src directory.

Usage:
<pre>All of site, gridout, modelcords, models, and format must be specified.
Usage: single_exe.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout (output)
--coordfile=COORDSFILE
Path to coordfile (output)
--models=MODELS Comma-separated string on velocity models to use.
--format=FORMAT Specify awp or rwg format for output.
--frequency=FREQUENCY
Frequency
--spacing=SPACING Override default spacing with this value (km)
--min_vs=MIN_VS Override minimum Vs value. Minimum Vp and minimum
density will be 3.4 times this value.
</pre>

Typical run configuration: Parallel on ~4000 cores; for 10 billion points and the C version of UCVM, takes about 20 minutes. Typically only half the cores per node are used to get more memory per process.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#coords|coords]]

Output files: either [[CyberShake_Code_Base#RWG_format|RWG format]] or [[CyberShake_Code_Base#AWP_format|AWP format]], depending on the option selected.

=== Smoothing ===

Purpose: To smooth a velocity file along model interfaces.

Detailed description: The smoothing code takes in a velocity mesh, determines the surface coordinates of the interfaces between velocity models, gets a list of all the points which need to be smoothed, and then performs the smoothing by averaging in both the X and Y direction for a user-specified number of points (default of 10km in each direction).

Needs to be changed if:
#We change our version of UCVM. The LD_LIBRARY_PATH needs to be modified, in run_smoothing.py around line 98.
#The smoothing algorithm is modified. Currently that is specified in the average_point() function in smooth_mpi.c.
#We start using velocity models with boundaries aren't perpendicular to the earth's surface.

Source code location: https://github.com/SCECcode/cybershake-core/UCVM/smoothing

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM|UCVM]]

Executable chain:
smoothing/run_smoothing.py
bin/determine_surface_model
smoothing/determine_smoothing_points.py
smoothing/smooth_mpi

Compile instructions:Run 'make' in the smoothing directory, and make sure that determine_surface_model has been compiled in the UCVM/src directory. You may need to change the compiler; currently it uses 'cc'.

Usage:
<pre>Usage: run_smoothing.py [options]

Options:
-h, --help show this help message and exit
--gridout=GRIDOUT gridout file
--coords=COORDS coords file
--models=MODELSTRING comma-separated list of velocity models
--smoothing-dist=SMOOTHING_DIST
Number of grid points to smooth over. About 10km of
grid points is a good starting place.
--mesh=MESH AWP-format velocity mesh to smooth
--mesh-out=MESH_OUT Output smoothed mesh
</pre>

Typical run configuration: Parallel on ~1500 cores; for 5 billion points and the C version of UCVM, takes about 16 minutes.

Input files: [[CyberShake_Code_Base#AWP_format|AWP format velocity file]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#AWP_format|AWP format]] smoothed velocity file.

=== PreSGT ===

Purpose: To generate a series of input files which are used by the wave propagation codes.

Detailed description: PreSGT determines the X and Y coordinates of the site location (where the impulse will go for the wave propagation simulation) and determines, which mesh point (X and Y) maps most closely to every point on a fault surface which is within the cutoff. That information is combined with an adaptive mesh approach to create a list of all the points for which SGTs should be saved.

Needs to be changed if:
#We change our approach for saving adaptive mesh points.
#We change the location of the rupture geometry files, currently assumed to be <rupture root>/Ruptures_erf<erf ID> . This is specified in presgt.py, line 167.
#The directory hierarchy and naming scheme for rupture geometry files, currently <src id>/<rup id>/<src id>_<rup_id>.txt, changes. This is specified in faultlist_py/CreateFaultList.py, line 36.
#The number of header lines in the rupture geometry file changes. This would require changing the nheader value, currently 6, specified in faultlist_py/CreateFaultList.py, line 36.
#We switch to RSQSim ruptures, or other ruptures in which the geometry isn't planar. Modifications would be required to gen_sgtgrid.c.

Source code location: https://github.com/SCECcode/cybershake-core/PreSgt

Author: Rob Graves, heavily modified by Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]], [[CyberShake_Code_Base#libcfu|libcfu]], [[CyberShake_Code_Base#MySQLdb|MySQLdb for Python]]

Executable chain:
presgt.py
faultlist_py/CreateFaultList.py
bin/gen_sgtgrid

Compile instructions:Run 'make' in the src directory.

Usage:
<pre>Usage: ./presgt.py <site> <erf_id> <modelbox> <gridout> <model_coords> <fdloc> <faultlist> <radiusfile> <sgtcords> <spacing> [frequency]
Example: ./presgt.py USC 33 USC.modelbox gridout_USC model_coords_GC_USC USC.fdloc USC.faultlist USC.radiusfile USC.cordfile 200.0 0.1
</pre>

Typical run configuration: Parallel on 8 nodes, 32 cores (gen_sgtgrid is a parallel code); for 200m spacing UCERF2, takes about 8 minutes.

Input files: [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Coord|coord]]

Output files: [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#Faultlist|faultlist]], [[CyberShake_Code_Base#Radiusfile|radiusfile]], [[CyberShake_Code_Base#SgtCoords|sgtcoords]].

=== PreAWP ===

Purpose: To generate input files in a format that AWP-ODC expects.

Detailed description: PreAWP performs a number of steps:
#An IN3D parameter file is produced, needed for AWP-ODC.
#A file with the SGT coordinates to save in AWP format is produced. Since RWG and AWP use different coordinate systems, a coordinate transformation (X->Y, Y->X, zero-indexing->one-indexing) is performed on the SGT coordinates file.
#The velocity file in translated to AWP format, if it isn't in AWP format already.
#The correct source, based on the dt and nt, is selected. The source must be generated manually ahead of time. Details about source generation are given [[CyberShake Code Base#Impulse source descriptions | here]].
#Striping for the output file is also set up here.
#Files are symlinked into the directory structure that AWP expects. Note that slightly different versions of this exist for the CPU and GPU implementations of AWP-ODC-SGT.

Needs to be changed if:
#The path to the Lustre striping command (lfs) changes. This path is hard-coded in build_awp_inputs.py, line 14. Note that this is the path to lfs on the compute node, NOT the login node.
#The AWP code changes its input format.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/ (HIP GPU) or https://github.com/SCECcode/cybershake-core/AWP-GPU-SGT/utils/ (CUDA GPU) or https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT/utils/ (CPU), AND also https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: SgtHead

Executable chain:
build_awp_inputs.py
build_IN3D.py
build_src.py
build_cordfile.py
SgtHead/gen_awp_cordfile.py
build_media.py
SgtHead/bin/reformat_velocity

Compile instructions:Run 'make' in the SgtHead/src directory.

Usage:
<pre>Usage: build_awp_inputs.py [options]

Options:
-h, --help show this help message and exit
--site=SITE Site name
--gridout=GRIDOUT Path to gridout input file
--fdloc=FDLOC Path to fdloc input file
--cordfile=CORDFILE Path to cordfile input file
--velocity-prefix=VEL_PREFIX
RWG velocity prefix. If omitted, will not reformat
velocity file, just symlink.
--frequency=FREQUENCY
Frequency of SGT run, 0.5 Hz by default.
--px=PX Number of processors in X-direction.
--py=PY Number of processors in Y-direction.
--pz=PZ Number of processors in Z-direction.
--source-frequency=SOURCE_FREQ
Low-pass filter frequency to use on the source,
default is same frequency as the frequency of the run.
--spacing=SPACING Override default spacing, derived from frequency.
--velocity-mesh=VEL_MESH
Provide path to velocity mesh. If omitted, will
assume mesh is named awp.<site>.media.
</pre>

Typical run configuration: Serial; for 1 Hz run, takes about 11 minutes.

Input files: [[CyberShake_Code_Base#Gridout|gridout]], [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#SgtCoords|cordfile]], velocity mesh (if in [[CyberShake_Code_Base#RWG_format|RWG format]], will be converted to [[CyberShake_Code_Base#AWP_format|AWP]]), [[CyberShake_Code_Base#RWG_source|RWG source]]

Output files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP source|AWP source]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]].

=== AWP-ODC-SGT, CPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the CPU version. It uses the IN3D file for its parameters.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: https://github.com/SCECcode/cybershake-core/AWP-ODC-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: iobuf module

Executable chain:
awp_odc_wrapper.sh
bin/pmcl3d

Compile instructions:Using the GNU compilers, run 'make' in the src directory.

Usage:
<pre> pmcl3d <IN3D parameter file>
</pre>

Typical run configuration: Parallel; for 0.5 Hz run (2 billion points, 20k timesteps), takes about 45 minutes on 10,000 cores.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== AWP-ODC-SGT, CUDA GPU version ===

Purpose: To perform SGT synthesis

Detailed description: AWP-ODC-SGT is the GPU version. It takes parameters on the command-line, so the wrapper converts the IN3D file into command-line arguments and invokes it.

Needs to be changed if:
#New science or features are added to the AWP code.

Source code location: hhttps://github.com/SCECcode/cybershake-core/AWP-GPU-SGT

Author: Kim Olsen, Steve Day, Yifeng Cui, various students and post-docs, wrapped by Scott Callaghan

Dependencies: CUDA toolkit module

Executable chain:
gpu_wrapper.py
bin/pmcl3d

Compile instructions:modules PrgEnv-gnu and module cudatoolkit must be loaded first. Then, run 'make' in the src directory.

Usage:
<pre>Usage: ./pmcl3d
Options:
[(-T | --TMAX) <TMAX>]
[(-H | --DH) <DH>]
[(-t | --DT) <DT>]
[(-A | --ARBC) <ARBC>]
[(-P | --PHT) <PHT>]
[(-M | --NPC) <NPC>]
[(-D | --ND) <ND>]
[(-S | --NSRC) <NSRC>]
[(-N | --NST) <NST>]

[(-V | --NVE) <NVE>]
[(-B | --MEDIASTART) <MEDIASTART>]
[(-n | --NVAR) <NVAR>]
[(-I | --IFAULT) <IFAULT>]
[(-R | --READ_STEP) <x READ_STEP]

[(-X | --NX) <x length]
[(-Y | --NY) <y length>]
[(-Z | --NZ) <z length]
[(-x | --NPX) <x processors]
[(-y | --NPY) <y processors>]
[(-z | --NPZ) <z processors>]

[(-1 | --NBGX) <starting point to record in X>]
[(-2 | --NEDX) <ending point to record in X>]
[(-3 | --NSKPX) <skipping points to record in X>]
[(-11 | --NBGY) <starting point to record in Y>]
[(-12 | --NEDY) <ending point to record in Y>]
[(-13 | --NSKPY) <skipping points to record in Y>]
[(-21 | --NBGZ) <starting point to record in Z>]
[(-22 | --NEDZ) <ending point to record in Z>]
[(-23 | --NSKPZ) <skipping points to record in Z>]

[(-i | --IDYNA) ]
[(-s | --SoCalQ) <s SoCalQ>]
[(-l | --FL) <l FL>]
[(-h | --FH) ]
[(-p | --FP) ]
[(-r | --NTISKP) <time skipping in writing>]
[(-W | --WRITE_STEP) <time aggregation in writing>]

[(-100 | --INSRC) <source file>]
[(-101 | --INVEL) <mesh file>]
[(-o | --OUT) <output file>]
[(-c | --CHKFILE) <checkpoint file to write statistics>]

[(-G | --IGREEN) <IGREEN for SGT>]
[(-200 | --NTISKP_SGT) <NTISKP for SGT>]
[(-201 | --INSGT) <SGT input file>]
</pre>

Typical run configuration: Parallel; for 1 Hz run (10 billion points, 40k timesteps), takes about 55 minutes on 800 GPUs.

Input files: [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP cordfile|AWP cordfile]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]), [[CyberShake_Code_Base#AWP source|AWP source]]

Output files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]].

=== PostAWP ===

Purpose: To prepare the AWP results for use in post-processing.

Detailed description: PostAWP prepares the outputs of AWP so that they can be used with the RWG-authored post-processing code. Specifically, it undoes the AWP coordinate transformation and reformats the AWP output files into the SGT component order expected by RWG (XX->YY, YY->XX, XZ->-YZ, YZ->-XZ, and all SGTs are doubled if we are calculating the Z-component), creates separate SGT header files, and calculates MD5 sums on the SGT files. Calculating the header information requires a number of input files, since lambda, mu, and the location of the impulse must all be included. The MD5 sums can be calculated separately, using the MD5 wrapper RunMD5sum.

Needs to be changed if:
#The AWP code is modified to produce outputs in exactly RWG order
#The header format for the post-processing code changes
#We decide not to calculate MD5 sums

Source code location: https://github.com/SCECcode/cybershake-core/AWP-HIP-SGT/utils/prepare_for_pp.py (this will work for the CPU version of AWP also, despite the path); https://github.com/SCECcode/cybershake-core/SgtHead

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
AWP-GPU-SGT/utils/prepare_for_pp.py
SgtHead/bin/reformat_awp_mpi
SgtHead/bin/write_head

Compile instructions:Run 'make write_head' and 'make reformat_awp_mpi' in the SgtHead/src directory.

Usage:
<pre>Usage: ./prepare_for_pp.py <site> <AWP SGT> <reformatted SGT filename> <modelbox file> <rwg cordfile> <fdloc file> <gridout file> <IN3D file> <AWP media file> <component> <run_id> <header> [frequency]
</pre>

Typical run configuration: Parallel, 4 processors on 2 nodes; for a 750 GB SGT, takes about 100 minutes without the MD5 sums.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Modelbox|modelbox]], [[CyberShake_Code_Base#SgtCoords|RWG cordfile]]), [[CyberShake_Code_Base#Fdloc|fdloc]], [[CyberShake_Code_Base#IN3D|IN3D]], [[CyberShake_Code_Base#AWP_format|AWP velocity mesh]]

Output files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]], [[CyberShake_Code_Base#SGT header file|SGT header file]]

=== RunMD5sum ===

Purpose: Wrapper for performing MD5sums.

Detailed description: On Titan, we ran into wallclock issues when bundling the MD5sums along with PostAWP. This wrapper supports performing the MD5 sums separately.

Needs to be changed if:
#We change hash algorithms

Source code location: https://github.com/SCECcode/cybershake-core/SgtHead/run_md5sum.sh

Author: Scott Callaghan

Dependencies: none

Executable chain:
run_md5sum.sh

Compile instructions: none

Usage:
<pre>Usage: ./run_md5sum.sh <file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 70 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT file]]

Output files: MD5sum, with filename <RWG SGT filename>.md5

=== NanCheck ===

Purpose: Check the SGTs for anomalies before the post-processing.

Detailed description: This code checks to be sure the SGTs are the expected size, then checks for NaNs or too many consecutive zeros in the SGT files.

Needs to be changed if:
#We change the number of timesteps in the SGT file. Currently this is hardcoded, but it should be a command-line parameter.
#We want to add additional checks.

Source code location: https://github.com/SCECcode/cybershake-core/SgtTest/

Author: Rob Graves, Scott Callaghan

Dependencies: [[CyberShake_Code_Base#Getpar|Getpar]]

Executable chain:
perform_checks.py
bin/check_for_nans

Compile instructions: Run 'make' in SgtTest/src .

Usage:
<pre>Usage: ./perform_checks.py <SGT file> <SGT header file></pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 45 minutes.

Input files: [[CyberShake_Code_Base#AWP SGT|AWP SGT file]], [[CyberShake_Code_Base#Sgt Coords|RWG coordinate file]], [[CyberShake_Code_Base#IN3D | IN3D file]]

Output files: none

== PP-related codes ==

The following codes are related to the post-processing part of the workflow.

[[File:PP_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the PP part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_PP_workflow.odg source file (ODG)]]]

=== CheckSgt ===

Purpose: To check the MD5 sums of the SGT files to be sure they match.

Detailed description: CheckSgt takes the SGT files and their corresponding MD5 sums and checks for agreement.

Needs to be changed if:
#We change hashing algorithms.
#We decide to add additional sanity checks to the beginning of the post-processing.

Source code location: https://github.com/SCECcode/cybershake-core/CheckSgt

Author: Scott Callaghan

Dependencies: none

Executable chain:
CheckSgt.py

Compile instructions: none

Usage:
<pre>Usage: ./CheckSgt.py <sgt file> <md5 file>
</pre>

Typical run configuration: Serial; for a 750 GB SGT, takes about 90 minutes.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], SGT MD5 sums

Output files: None

=== DirectSynth ===

DirectSynth is the code we currently use to perform the post-processing. For historical reasons, all of the codes used for CyberShake post-processing are documented here: [https://scec.usc.edu/it/Post-processing_options CyberShake post-processing options] (login required).

Purpose: To perform reciprocity calculations and produce seismograms, intensity measures, and duration measures.

Detailed description: DirectSynth reads in the SGTs across a group of processes, and hands out tasks (synthesis jobs) to worker processes. These worker processes read in rupture geometry information from disk and call the RupGen-api to generate full slip histories in memory. The workers request SGTs from the reader processes over MPI. X and Y component PSA calculations are performed from the resultant seismograms, and RotD and duration calculations are also performed, if requested. More details about the approach used are available at [[DirectSynth]].

Needs to be changed if:
#We have new intensity measures or other calculations per seismogram to perform.
#We decide to change the post-processing algorithm.
#The wrapper needs to be modified if we want to set different custom environment variables.

Source code location: https://github.com/SCECcode/cybershake-core/DirectSynth

Author: Scott Callaghan, original seismogram synthesis code by Rob Graves, X and Y component PSA code by David Okaya, RotD code by Christine Goulet

Dependencies: [[CyberShake Code Base#Getpar | Getpar]], [[CyberShake Code Base#libcfu | libcfu]], [[CyberShake Code Base#RupGen-api-v3.3.1 | RupGen-api-v3.3.1, [[CyberShake Code Base#FFTW | FFTW]], [[CyberShake Code Base#libmemcached | libmemcached]] (optional) and [[CyberShake Code Base#memcached | memcached]] (optional)

Executable chain:
direct_synth_v3.3.1.py (current version, uses the Graves & Pitarka (2014) rupture generator)
utils/pegasus_wrappers/invoke_memcached.sh
memcached
bin/direct_synth

Compile instructions:
#Compile RupGen-api first.
#Edit the makefile in DirectSynth/src . Check the following variables:
##BASE_DIR should point to the top-level CyberShake install directory
##LIBCFU should point to the libcfu install directory
##V3_3_1_RG_LIB should point to the RupGen-api-3.3.1/lib directory
##LDLIBS should have the correct paths to the libcfu and libmemcached lib directories
##V3_3_1_RG_INC should point to the RupGen-api-3.3.1/include directory
##IFLAGS should have the correct paths to the libcfu and libmemcached include directories
#Run 'make direct_synth_v3.3.1' in DirectSynth/src.

You will also need to edit the hard-coded paths to memcached in direct_synth_v3.3.1.py, in lines 15 and 24.

Usage:
<pre>
direct_synth_v3.3.1.py
stat=<site short name>
slat=<site lat>
slon=<site lon>
run_id=<run id>
sgt_handlers=<number of SGT handler processes; must be enough for the SGTs to be read into memory>
debug=<print logs for each process; 1 is yes, 0 no>
max_buf_mb=<buffer size in MB for each worker to use for storing SGT information>
rupture_spacing=<'uniform' or 'random' hypocenter spacing>
ntout=<nt for seismograms>
dtout=<dt for seismograms>
rup_list_file=<input file containing ruptures to process>
sgt_xfile=<input SGT X file>
sgt_yfile=<input SGT Y file>
x_header=<input SGT X header>
y_header=<input SGT Y header>
det_max_freq=<maximum frequency of deterministic part>
stoch_max_freq=<maximum frequency of stochastic part>
run_psa=<'1' to run X and Y component PSA, '0' to not>
run_rotd=<'1' to run RotD calculations, '0' to not>
run_durations=<'1' to run duration calculation, '0' to not>
simulation_out_pointsX=<'2', the number of components>
simulation_out_pointsY=1
simulation_out_timesamples=<same as ntout>
simulation_out_timeskip=<same as dtout>
surfseis_rspectra_seismogram_units=cmpersec
surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa
surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=<high filter, 5.0 for 1 Hz runs, 20.0 or higher for 10 Hz runs>
surfseis_rspectra_apply_byteswap=no
</pre>

Typical run configuration: Parallel, typically on 3840 processors; for 750 GB SGTs with ~7000 ruptures, takes about 12 hours.

Input files: [[CyberShake_Code_Base#RWG SGT|RWG SGT]], [[CyberShake_Code_Base#SGT header file|SGT headers]], [[CyberShake_Code_Base#rupture list file|rupture list file]], rupture geometry files

Output files: [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | Seismograms]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

== Data Product Codes ==

The software in this section takes the data products produced by the SGT and post-processing stages, adds some of it to the database, and creates final data products. Note that all these codes should be installed on a server close to the database, to reduce insertion and query time. Currently these are all installed on SCEC disks and accessed from shock.usc.edu.

[[File:Data_workflow_stages.png|thumb|right|300px|Overview of the codes involved in the data product of CyberShake, [http://hypocenter.usc.edu/research/cybershake/full_data_workflow.odg source file (ODG)]]]

=== Load Amps ===

Purpose: Load data from output files into the database.

Detailed description: This code loads either PSA, RotD, or Duration data into the database, depending on command-line options. It also performs sanity checks on the PSA data being inserted: values must be between 0.008 and 8400 cm/s2. If they are less than 0.008, some will still be passed through if it's a small magnitude event at large distances. If this constraint is violated, it will abort. Note that if LoadAmps needs to be rerun, sometimes the database must be cleaned out first, as data from the previous attempt may have inserted successfully and will cause duplicate key errors if you try to insert the same data again.

Needs to be changed if:
#We change the sanity checks on data inserts.
#We modify the format of the PSA, RotD, or Duration files.
#We add new types of data to insert.
#We change the database schema.
#We add a new server. To add a new server, in addition to providing a command-line option for it, you will need to create a Hibernate config file. You can start with moment.cfg.xml or focal.cfg.xml and edit lines 7-16 appropriately.

Source code location: https://github.com/SCECcode/cybershake-core/CyberCommands

Author: Joshua Garcia, Scott Callaghan

Dependencies: LoadAmps calls CyberCommands, a Java code with a long list of dependencies (all of these are checked into the Java project):

*Ant
*Apache Commons
*Hibernate
*MySQL bindings
*Xerces
*DOM4J
*Log4J
*Java 1.6+

Executable chain:
insert_dir.sh
CyberLoadAmps_SC
cybercommands_SC.jar
CyberLoadamps.java

Compile instructions: Check out CyberCommands into Eclipse. Create the cybercommands_SC.jar file using Eclipse's JAR build framework and the cybercommands_SC.jardesc description file. Install cybercommand_SC.jar and the required JAR files on the server. Point insert_dir.sh to CyberLoadAmps_SC to cybercommands_SC.jar.

Usage:
<pre>Usage: CyberLoadAmps [-r | -d | -z | -u][-c] [-d] [-periods periods] [-run RunID] [-p directory] [-server name] [-z] [-help] [-i insertion_values]
[-u] [-f]
-i <insertion_values> Which values to insert -
gm: geometric mean PSA data (default)
xy: X and Y component PSA data
gmxy: Geometric mean and X and Y components
-run <RunID> Run ID - this option is required
-p <directory> file path with spectral acceleration files,
either top-level directory or zip file - this option is required
-server <name> server name (focal, surface, intensity, moment,
or csep-x) - this option is required
-periods <periods> Comma-delimited periods to insert
-c Convert values from g to cm/sec^2
-d Assume one BSA file per rupture, with embedded
header information.
-f Don't apply value checks to insertion values; use
with care!.
-help print this message
-r Read rotd files (instead of bsa.)
-u Read duration files (instead of bsa.)
-z Read zip files instead of bsa.</pre>

Typical run configuration: Serial; for 5 periods, takes about 10 minutes. It's wildly dependent on the database and contention from other database processes.

Input files: [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], [[Accessing_CyberShake_Duration_Data | Duration files]]

Output files: none

=== Check DB Site ===

Purpose: Verify that data was correctly loaded into the database.

Detailed description: This code takes a list of components (or type IDs) to check for a run ID, and verifies that there is one entry for every rupture variation. If some rupture variations are missing, a file is produced which lists the missing source, rupture, rupture variation tuples.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/db/CheckDBDataForSite.java and DBConnect.java

Author: Scott Callaghan (CheckDBDataForSite.java), Nitin Gupta, Vipin Gupta, Phil Maechling (DBConnect.java)

Dependencies: Both are checked into the CyberShake project:

*Apache Commons
*MySQL bindings

Executable chain:
check_db.sh
CheckDBDataForSite.java

Compile instructions: Check out CheckDBDataForSite.java and DBConnect.java. Compile them by running 'javac -classpath mysql-connector-java-5.0.5-bin.jar:commons-cli-1.0.jar DBConnect.java CheckDBDataForSite.java'. The paths to the MySQL bindings jar and the Apache Commons jar may be different depending on your installation.

Usage:
<pre>usage: CheckDBDataForSite
-p <periods> Comma-separated list of periods to check, for geometric
and rotd.
-t <type_ids> Comma-separated list of type IDs to check, for duration.
-c <component> Component type (geometric, rotd, duration) to check.
-h,--help Print help for CheckDBDataForSite
-o <output> Path to output file, if something is missing (required).
-r <run_id> Run ID to check (required).
-s <server> DB server to query against.
</pre>

Typical run configuration: Serial; typically takes just a few seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Missing variations file | Missing variations file]]

=== DB Report ===

Purpose: Produce a database report, a data product which Rob Graves used for a time.

Detailed description: This code takes a run ID, queries the database for PSA values for all components, and writes the output to a text file. The list of periods and the DB config parameters are specified in an XML config file.

Needs to be changed if:
#Username, password, or database host are changed: the DB connection parameters in default.xml would need to be edited.
#We want results for different periods: edit default.xml.
#We change the database schema.

Source code location: https://github.com/SCECcode/cybershake-core/reports/db_report_gen.py . default.xml in the same directory is also needed, and can be generated by editing and running conf_get.py, also in the same directory.

Author: Kevin Milner

Dependencies: MySQLdb

Executable chain:
db_report_gen.py

Compile instructions: None, all code is Python.

Usage:
<pre>Usage: db_report_gen.py [options] SITE_SHORT_NAME

NOTE: defaults are loaded from defaults.xml and can be edited manually
or overridden with conf_gen.py

Options:
-h, --help show this help message and exit
-e ERF_ID, --erfID=ERF_ID
ERF ID for Report (default = none)
-f FILENAME, --file=FILENAME
Store Results to a file instead of STDOUT. If a
directory is given, a name will be auto generated.
-i, --id Flag for specifying site ID instead of Short Name
(default uses Short Name)
--hypo, --hpyocenter Flag for appending hypocenter locations to result
-l LIMIT, --limit=LIMIT
Limit the total number of rusults, or 0 for no limit
(default = 0)
-o, --sort SLOW: Force SQL Order By statement for sorting. It
will probably come out sorted, but if it doesn't, you
can use this. (default will not sort)
-p PERIODS, --periods=PERIODS
Comma separated period values (default = 3.0,5.0,10.0)
--pr, --print-runs Print run IDs for site and optionally ERF/Rup Var
Scen/SGT Var IDs
-r RUP_VAR_SCENARIO_ID, --rupVarID=RUP_VAR_SCENARIO_ID
Rupture Variation Scenario ID for Report (default =
none)
--ri=RUN_ID, --runID=RUN_ID
Allows you to specify a run ID to use (default uses
latest compatible run ID)
-R RUPTURE, --rupture=RUPTURE
Only give information on specified rupture. Must be
acompanied by -S/--source flag (default shows all
ruptures)
-s SGT_VAR_ID, --sgtVarID=SGT_VAR_ID
SGT Variation ID for Report (default = none)
-S SOURCE, --source=SOURCE
Only give information on specified source. To specify
rupture, see -R option (default shows all sources)
--s_im, --sort-ims Sort output by IM value (increasing)...may be slow!
-v, --verbose Verbosity Flag (default = False)
</pre>

Typical run configuration: Serial; about 1 minute. It's wildly dependent on the database and contention from other database processes.

Input files: default.xml

Output files: [[CyberShake_Code_Base#DB Report file | DB Report file]]

=== Curve Calc ===

Purpose: Calculate CyberShake hazard curves alongside comparison GMPEs.

Detailed description: This code takes a run ID, component, and period, queries the database for the appropriate IM values, and calculates a hazard curve in the desired format. Comparison GMPE curves can also be plotted.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#New IM types need to be supported.

Source code location: The CyberShake curve calculator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.HazardCurvePlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by curve_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/curve_plot_wrapper.sh .

The OpenSHA project also has configuration files for various GMPEs, config files for UCERF2, and configuration files for output formats preferred by Tom and Rob, in src/org/opensha/sha/cybershake/conf.

Author: Kevin Milner

Dependencies: Standard OpenSHA dependencies

Executable chain:
curve_plot_wrapper.sh
HazardCurvePlotter.java

Compile instructions: Use the OpenSHA build process if building from source.

Usage:
<pre>
usage: HazardCurvePlotter [-?] [-af <arg>] [-benchmark] [-c] [-cmp <arg>]
[-comp <arg>] [-cvmvs] [-e <arg>] [-ef <arg>] [-f] [-fvs <arg>] [-h
<arg>] [-imid <arg>] [-imt <arg>] [-n] [-novm] [-o <arg>] [-p
<arg>] [-pf <arg>] [-pl <arg>] [-R <arg>] [-r <arg>] [-s <arg>]
[-sgt <arg>] [-sgtsym] [-t <arg>] [-v <arg>] [-vel <arg>] [-w
<arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship
description file(s) for comparison.
Multiple files should be comma
separated
-benchmark,--benchmark-test-recalc Forces recalculation of hazard
curves to test calculation speed.
Newly recalculated curves are not
kept and the original curves are
plotted.
-c,--calc-only Only calculate and insert the
CyberShake curves, don't make plots.
If a curve already exists, it will
be skipped.
-cmp,--component <arg> Intensity measure component.
Options: GEOM,X,Y,RotD100,RotD50,
Default: GEOM
-comp,--compare-to <arg> Compare to aspecific Run ID (or
multiple IDs, comma separated)
-cvmvs,--cvm-vs30 Option to use Vs30 value from the
velocity model itself in GMPE
calculations rather than, for
example, the Wills 2006 value.
-e,--erf-id <arg> ERF ID
-ef,--erf-file <arg> XML ERF description file for
comparison
-f,--force-add Flag to add curves to db without
prompt
-fvs,--force-vs30 <arg> Option to force the given Vs30 value
to be used in GMPE calculations.
-h,--height <arg> Plot height (default = 500)
-imid,--im-type-id <arg> Intensity measure type ID. If not
supplied, will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-n,--no-add Flag to not automatically calculate
curves not in the database
-novm,--no-vm-colors Disables Velocity Model coloring
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple
periods should be comma separated
(default: 3)
-pf,--password-file <arg> Path to a file that contains the
username and password for inserting
curves into the database. Format
should be "user:pass"
-pl,--plot-chars-file <arg> Specify the path to a plot
characteristics XML file
-R,--run-id <arg> Run ID
-r,--rv-id <arg> Rupture Variation ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-sgtsym,--sgt-colors Enables SGT specific symbols
-t,--type <arg> Plot save type. Options are png,
pdf, jpg, and txt. Multiple types
can be comma separated (default is
pdf)
-v,--vs30 <arg> Specify default Vs30 for sites with
no Vs30 data, or leave blank for
default value. Otherwise, you will
be prompted to enter vs30
interactively if needed.
-vel,--vel-model-id <arg> Velocity Model ID
-w,--width <arg> Plot width (default = 600)
</pre>

Typical run configuration: Serial; about 30 seconds per curve. It's wildly dependent on the database and contention from other database processes.

Input files: ERF config file, GMPE config files

Output files: [[CyberShake_Code_Base#Hazard Curve | Hazard Curve]]

=== Disaggregate ===

Purpose: Disaggregate the curve results to determine the largest contributing sources.

Detailed description: This code takes a run ID, a probability or IM level, and a period to disaggregate at. It produces disaggregation distance-magnitude plots and also a list of the % contribution of each source.

Needs to be changed if:
#Username, password, or database host are changed.
#We change the database schema.
#We want to support different kinds of disaggregation, or for a different kind of ERF.

Source code location: The Disaggregator is part of the OpenSHA codebase. The specific Java class is org.opensha.sha.cybershake.plot.DisaggregationPlotter (available via https://github.com/opensha/opensha-cybershake/tree/master/src/main/java/org/opensha/sha/cybershake/plot), but it has a complex set of Java depdendencies. To compile and run, you should follow the instructions on http://www.opensha.org/trac/wiki/SettingUpEclipse to access the source. The curve calculator is also wrapped by disagg_plot_wrapper.sh, in https://github.com/SCECcode/cybershake-tools/blob/master/HazardCurveGeneration/disagg_plot_wrapper.sh .

Author: Kevin Milner, Nitin Gupta, Vipin Gupta

Dependencies: Standard OpenSHA dependencies

Executable chain:
disagg_plot_wrapper.sh
DisaggregationPlotter.java

Compile instructions: Use the standard OpenSHA building process if building from source.

Usage:
<pre>usage: DisaggregationPlotter [-?] [-af <arg>] [-cmp <arg>] [-e <arg>]
[-fvs <arg>] [-i <arg>] [-imid <arg>] [-imt <arg>] [-o <arg>] [-p
<arg>] [-pr <arg>] [-r <arg>] [-R <arg>] [-s <arg>] [-sgt <arg>]
[-t <arg>] [-vel <arg>]
-?,--help Display this message
-af,--atten-rel-file <arg> XML Attenuation Relationship description
file(s) for comparison. Multiple files
should be comma separated
-cmp,--component <arg> Intensity measure component. Options:
GEOM,X,Y,RotD100,RotD50, Default: GEOM
-e,--erf-id <arg> ERF ID
-fvs,--force-vs30 <arg> Option to force the given Vs30 value to be
used in GMPE calculations.
-i,--imls <arg> Intensity Measure Levels (IMLs) to
disaggregate at. Multiple IMLs should be
comma separated.
-imid,--im-type-id <arg> Intensity measure type ID. If not supplied,
will be detected from im
type/component/period parameters
-imt,--im-type <arg> Intensity measure type. Options: SA,
Default: SA
-o,--output-dir <arg> Output directory
-p,--period <arg> Period(s) to calculate. Multiple periods
should be comma separated (default: 3)
-pr,--probs <arg> Probabilities (1 year) to disaggregate at.
Multiple probabilities should be comma
separated.
-r,--rv-id <arg> Rupture Variation ID
-R,--run-id <arg> Run ID
-s,--site <arg> Site short name
-sgt,--sgt-var-id <arg> STG Variation ID
-t,--type <arg> Plot save type. Options are png, pdf, and
txt. Multiple types can be comma separated
(default is pdf)
-vel,--vel-model-id <arg> Velocity Model ID
</pre>

Typical run configuration: Serial; typically takes about 30 seconds. It's wildly dependent on the database and contention from other database processes.

Input files: none

Output files: [[CyberShake_Code_Base#Disaggregation file | Disaggregation file]]

== Stochastic codes ==

With CyberShake, we also have the option to augment a completed run with stochastic seismograms. The following codes are used to add stochastic high-frequency content to an already-completed low-frequency deterministic run.

[[File:stochastic workflow overview.png|thumb|right|300px|Overview of the codes involved in the stochastic part of CyberShake, [http://hypocenter.usc.edu/research/cybershake/stochastic_workflow_overview.odg source file (ODG)]]]

=== Velocity Info ===

Purpose: To determine slowness-averaged VsX values for a CyberShake site, from UCVM.

Detailed description: Velocity Info takes a location, a velocity model, and grid spacing information and queries UCVM to generate three VsX values needed by the site response:
#Vs30, calculated as: 30 / sum( 1 / (Vs sampled from [0.5, 29.5] at 1 meter increments, for 30 values) )
#Vs5H, like Vs30 but calculated over the shallowest 5*gridspacing meters. So if gridspacing=100m, Vs5H = 500 / sum( 1 / (Vs sampled from [0.5, 499.5] at 1 meter increments, for 500 values) )
#VsD5H, like Vs30, but calculated over gridspacing increments, instead of 1 meter. The start and end are weighted half as much. So if gridspacing=100m, VsD5H = 5 / sum( 0 / (Vs sampled from [0, 500] at 1 meter increments, for 500 values) )

Needs to be changed if:
#We need to support more than one model - for instance, if the CyberShake site box (not simulation volume) spans multiple models. The code to parse the model string and load models in initialize_ucvm() would need to be changed.
#We want to support new kinds of velocity values.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/src/retrieve_vs.c

Author: Scott Callaghan

Dependencies: [[CyberShake_Code_Base#UCVM | UCVM]]

Executable chain:
retrieve_vs

Compile instructions:Run 'make retrieve_vs'

Usage:
<pre>Usage: ./retrieve_vs <lon> <lat> <model> <gridspacing> <out filename></pre>

Typical run configuration: Serial; takes about 15 seconds.

Input files: None

Output files: [[CyberShake_Code_Base#Velocity_Info file|Velocity Info file]]

=== Local VM ===

Purpose: To generate a "local" 1D velocity file, required for the high-frequency codes.

Detailed description: Local VM takes in an input file containing a 1D velocity model. It then calculates Qs from these values and writes all the velocity data to a new file. For all Study 15.12 runs, we used the LA Basin 1D model from the BBP, v14.3.0. It's registered in the RLS, and is located at /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod.

Needs to be changed if:
#We change the algorithm for calculating Vs.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/gen_local_vel.py

Author: Scott Callaghan, modified from Rob Graves' code

Dependencies: None

Executable chain:
gen_local_vel.py

Compile instructions: None

Usage:

<pre>Usage: ./gen_local_vel.py <1D velocity model> <output></pre>

Typical run configuration: Serial; takes less than a second.

Input files: [[CyberShake_Code_Base#BBP velocity file|BBP 1D velocity file]]

Output files: [[CyberShake_Code_Base#Local VM file|Local VM file]]

=== Create Dirs ===

Purpose: To create a directory for each source.

Detailed description: The high-frequency codes produce many intermediate files. To avoid overloading the filesystem, Create Dirs creates a separate directory for every source.

Needs to be changed if: This code is basically just a wrapper around mkdir, and is unlikely to need changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/create_dirs.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
create_dirs.py

Compile instructions: None

Usage:
<pre>
Usage: ./create_dirs.py <file with list of dirs>
</pre>

Typical run configuration: Serial, takes just a few seconds.

Input files: File with a directory to create (a source ID) on each line.

Output files: None.

=== HF Synth ===

Purpose: HF Synth generates a high-frequency stochastic seismogram for one or more rupture variations.

Detailed description: This code wraps multiple broadband platform codes to reduce the number of invocations required. Specifically, it calls:
#srf2stoch_lite(), a reduced-memory version of srf2stoch. We have modified it to call rupgen_genslip() to generate the SRF, rather than reading it in from disk.
#hfsim(), a wrapper for:
##hb_high(), Rob Graves's original BBP code to produce the seismograms
##wcc_getpeak(), which calculates PGA for the seismogram
##wcc_siteamp14(), which performs site amplification.

Vs30 is required, so if it is not passed as a command-line argument, UCVM is called to determine it.

Additionally, hf_synth_lite is able to handle processing on multiple rupture variations, to further reduce the number of invocations.

Needs to be changed if:
#A new version of one of Rob's codes - the high-frequency generator or the site amplification - is needed. We have tried to use whatever the most recent version is on the BBP, for consistency.
#New velocity parameters are needed for the site amplification.
#The format of the rupture geometry files changes.

The makefile needs to be changed if the path to libmemcached, UCVM, Getpar, or the rupture generator changes.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem

Author: wrapper by Scott Callaghan, hb_high(), wcc_getpeak(), and wcc_siteamp14() by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
hf_synth_lite

Compile instructions: Run 'make' in src.

Usage: There is no 'help' usage string, but here's a sample invocation:
<pre>
/projects/sciteam/jmz/CyberShake/software/HFSim_mem/bin/hf_synth_lite
stat=OSI slat=34.6145 slon=-118.7235
rup_geom_file=e36_rv6_121_0.txt source_id=121 rupture_id=0
num_rup_vars=5 rup_vars=(0,0,0);(1,1,0);(2,2,0);(3,3,0);(4,4,0)
outfile=121/Seismogram_OSI_4331_121_0_hf_t0.grm
dx=2.0 dy=2.0 tlen=300.0 dt=0.025
do_site_response=1 vs30=359.1 debug=0 vmod=LA_Basin_BBP_14.3.0.local
</pre>

Typical run configuration: Serial; takes a few seconds per rupture variation up to a minute, depending on the size of the fault surface.

Input files: [[CyberShake_Code_Base#Local_VM_file | Local velocity file]], [[CyberShake_Rupture_Files#UCERF2_Rupture_Geometry_Files | rupture geometry file]]

Output files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Combine HF Synth ===

Purpose: This code combines the seismograms produced by HF Synth so that there is just 1 seismogram per source/rupture combo.

Detailed description: Since we split up work so that each HF Synth job takes a chunk of rupture variations, we may end up with multiple seismogram files per rupture, each containing some of the rupture variations. This script concatenates the files, using cat, into a single file, ready to be worked on later in the workflow.

Needs to be changed if: I can't think of a circumstance where we would need to change this.

Source code location: https://github.com/SCECcode/cybershake-core/HFSim_mem/combine_seis.py

Author: Scott Callaghan

Dependencies: None

Executable chain:
combine_seis.py
cat

Compile instructions: None

Usage:
<pre>
Usage: ./combine_seis.py <seis 0> <seis 1> ... <seis N> <output seis name>
</pre>

Typical run configuration: Serial; takes a few seconds.

Input files: High-frequency seismograms, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A single high-frequency seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== LF Site Response ===

Purpose: This code performs site response modifications to the CyberShake low-frequency seismograms.

Detailed description: The LF Site Response code takes a low-frequency seismogram and some velocity parameters, and outputs a seismogram with site response applied. In Study 15.12, this was a necessary step before combining the low and high frequency seismograms together. Since Vs30 is required, if it's not passed as a command-line argument, then UCVM is called to determine it.

The reason we calculate site response for the low-frequency deterministic seismograms is that we want both the low- and high-frequency results to be for the same site-response condition. For the HF, we used Vs30 directly
for the site-response adjustment, but for the LF we had to use an adjusted VsX value since the grid spacing was 100 m (so Vs30 doesn't make sense).

Needs to be changed if:
#We change the site response algorithm.
#We decide to use different velocity parameters for setting site response.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/LF_Site_Response

Author: wrapper by Scott Callaghan, site response by Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]], [[CyberShake_Code_Base#UCVM | UCVM]], [[CyberShake_Code_Base#RupGen-api-v3.3.1 | rupture generator]], [[CyberShake_Code_Base#libmemcached | libmemcached]]

Executable chain:
lf_site_response

Compile instructions: Edit the makefile to point to RupGen, libmemcached, and Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./lf_site_response
seis_in=Seismogram_OSI_3923_263_3.grm seis_out=263/Seismogram_OSI_3923_263_3_site_response.grm
slat=34.6145 slon=-118.7235
module=cb2014
vs30=359.1 vref=344.7
</pre>

Typical run configuration: Serial; takes less than a second.

Input files: A low-frequency deterministic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: A low-frequency deterministic seismogram with site response, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

=== Merge IM ===

Purpose: This code combines low-frequency deterministic and high-frequency stochastic seismograms, then processes them to obtain intensity measures.

Detailed description: The Merge IM code takes an LF and HF seismogram and performs the following processing:
#A high-pass filter is applied to the HF seismogram.
#The LF seismogram is resampled to the same dt as the HF seismogram.
#The two seismograms are combined into a single broadband (BB) seismogram.
#The PSA code is run on the resulting seismogram.
#If desired, the RotD and duration codes are also run on the seismogram.

Merge IM works on a seismogram file at the rupture level, so it assumes that the input files contain multiple rupture variations.

Needs to be changed if:
#We change the filter-and-combine algorithm.
#We decide to modify the post-processing and IM types we want to capture.
#The format of the seismogram files changes.

Source code location: https://github.com/SCECcode/cybershake-core/MergeIM

Author: Scott Callaghan, Rob Graves

Dependencies: [[CyberShake_Code_Base#Getpar | Getpar]]

Executable chain:
merge_psa

Compile instructions: Edit the makefile to point to Getpar, then run 'make' in the src directory.

Usage:
Sample invocation:
<pre>
./merge_psa
lf_seis=182/Seismogram_OSI_3923_182_23_site_response.grm hf_seis=182/Seismogram_OSI_4331_182_23_hf.grm seis_out=182/Seismogram_OSI_4331_182_23_bb.grm
freq=1.0 comps=2 num_rup_vars=16
simulation_out_pointsX=2 simulation_out_pointsY=1
simulation_out_timesamples=12000 simulation_out_timeskip=0.025
surfseis_rspectra_seismogram_units=cmpersec surfseis_rspectra_output_units=cmpersec2
surfseis_rspectra_output_type=aa surfseis_rspectra_period=all
surfseis_rspectra_apply_filter_highHZ=20.0 surfseis_rspectra_apply_byteswap=no
out=182/PeakVals_OSI_4331_182_23_bb.bsa
run_rotd=1 rotd_out=182/RotD_OSI_4331_182_23_bb.rotd
run_duration=1 duration_out=182/Duration_OSI_4331_182_23_bb.dur
</pre>

Typical run configuration: Serial; takes 5-30 seconds, depending on the number of rupture variations in the files.

Input files: LF deterministic seismogram and HF stochastic seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]].

Output files: BB seismogram, in the general [[Accessing_CyberShake_Seismograms#Reading_Seismogram_Files | seismogram format]]; also [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | PSA files]], [[Accessing_CyberShake_Peak_Acceleration_Data#Reading_Peak_Acceleration_Files | RotD files]], and [[Accessing_CyberShake_Duration_Data | Duration files]]

== File types ==

=== Modelbox ===

Purpose: Contains a description of the simulation box, at the surface.

Filename convention: <site>.modelbox

Format:
<pre>
<site name>
APPROXIMATE CENTROID:
clon= <centroid lon> clat =<centroid lat>
MODEL PARAMETERS:
mlon= <model lon> mlat =<model lat> mrot=<model rot, default -55> xlen= <x-length in km> ylen= <y-length in km>
MODEL CORNERS:
<lon 1> <lat 1> (x= 0.000 y= 0.000)
<lon 2> <lat 2> (x= <max x> y= 0.000)
<lon 3> <lat 3> (x= <max x> y= <max y>)
<lon 4> <lat 4> (x= 0.000 y= <max y>)
</pre>

Generated by: PreCVM

Used by: PreSGT, PostAWP

=== Gridfile ===

Purpose: Specify the three dimensions, and gridspacing in each dimension, of the volume.

Filename convention: gridfile_<site>

Format:
<pre>
xlen=<x-length in km>
0.0 <x-length> <grid spacing in km>
ylen=<y-length in km>
0.0 <y-length> <grid spacing in km>
zlen=<z-length in km>
0.0 <z-length> <grid spacing in km>
</pre>

=== Gridout ===

Purpose: Specify the km offsets for each grid index, in X, Y, and Z, from the upper southwest corner.

Filename convention: gridout_<site>

Format:
<pre>
xlen=<x-length in km>
nx=<number of gridpoints in X direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
2 <2*grid spacing> <grid spacing>
3 <3*grid spacing> <grid spacing>
...
nx-1 <(nx-1)*grid spacing> <grid spacing>
ylen=<y-length in km>
ny=<number of gridpoints in Y direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
ny-1 <(ny-1)*grid spacing> <grid spacing>
zlen=<z-length in km>
nz=<number of gridpoints in Z direction>
0 0 <grid spacing>
1 <grid spacing> <grid spacing>
...
nz-1 <(nz-1)*grid spacing> <grid spacing>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT, PreAWP

=== Params ===

Purpose: Succinctly specify the parameters for the CyberShake volume. Similar information to the modelbox file, but in a different format.

Filename convention: model_params_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
Model origin coordinates:
lon= <model lon> lat= <model lat> rotate= <model rotation, default -55>

Model origin shift (cartesian vs. geographic):
xshift(km)= <x shift, usually half the x-length minus 1 grid spacing> yshift(km)= <y-shift, usually half the y-length minus 1 grid spacing>

Model corners:
c1= <nw lon> <nw lat>
c2= <ne lon> <ne lat>
c3= <se lon> <se lat>
c4= <sw lon> <sw lat>

Model Dimensions:
xlen= <x-length> km
ylen= <y-length> km
zlen= <z-length> km
</pre>

Generated by: PreCVM

Used by:

=== Coord ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, for each point on the surface.

Filename convention: model_coords_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
...
<lon> <lat> <nx-1> 1
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by: UCVM, smoothing, PreSGT

=== Bounds ===

Purpose: Specify the mapping of latitude and longitude to X and Y offsets, but only for the points along the boundary. A subset of the coord file.

Filename convention: model_bounds_GC_<site> (GC stands for 'great circle', the projection we use).

Format:
<pre>
<lon> <lat> 0 0
<lon> <lat> 1 0
<lon> <lat> 2 0
...
<lon> <lat> <nx-1> 0
<lon> <lat> 0 1
<lon> <lat> <nx-1> 1
<lon> <lat> 0 2
<lon> <lat> <nx-1> 2
...
<lon> <lat> 0 <ny-1>
<lon> <lat> 1 <ny-1>
...
<lon> <lat> <nx-1> <ny-1>
</pre>

Generated by: PreCVM

Used by:

=== Velocity files ===

==== RWG format ====

Purpose: Input velocity files for the RWG wave propagation code, emod3d.

Filename convention: v_sgt-<site>.<p, s, or d>

Format: 3 files, one each for Vp (*.p), Vs (*.s), and rho (*.d). Each is binary, with 4-byte floats, in fast X, Z (surface->down), slow Y order.

Generated by: UCVM

Used by: PreAWP

==== AWP format ====

Purpose: Input velocity file for the AWP-ODC wave propagation code.

Filename convention: awp.<site>.media

Format: Binary, with 4-byte floats, in fast Y, X, slow Z (surface down) order.

Generated by: UCVM

Used by: Smoothing, PreAWP, PostAWP

=== Fdloc ===

Purpose: Coordinates of the site, in X Y grid indices, and therefore the coordinates where the SGT impulse should be placed.

Filename convention: <site>.fdloc

Format:
<pre>
<X grid index of site> <Y grid index of site>
</pre>

Generated by: PreSGT

Used by: PreAWP, PostAWP

=== Faultlist ===

Purpose: List of paths to all the rupture geometry files for all ruptures which are within the cutoff for this site. Used to produce a list of points to save SGTs for.

Filename convention: <site>.faultlist

Format:
<pre>
<path to rupture file> nheader=<number of header lines, usually 6> latfirst=<1, to signify that latitude comes first in the rupture files>
...
</pre>

Generated by: PreSGT

Used by: PreSGT

=== Radiusfile ===

Purpose: Describe the adaptive mesh SGTs will be saved for.

Filename convention: <site>.radiusfile

Format:
<pre>
<number of gradations in X and Y>
<radius 1> <radius 2> <radius 3> <radius 4>
<decimation less than radius 1> <decimation between radius 1 and 2> <between 2 and 3> <between 3 and 4>
<number of gradations in Z>
<depth 1> <depth 2> <depth 3> <depth 4>
<decimation less than depth 1> <decimation between depth 1 and 2> <between 2 and 3> <between 3 and 4>
</pre>

Generated by: PreSGT

Used by: PreSGT

=== SGT Coordinate files ===

There are two formats for the list of points to save SGTs for, one for Rob's codes and one for AWP-ODC. As with other coordinate transformations between the two systems, to convert X and Y offsets from RWG to AWP you have to flip the X and Y and add 1 to each, since RWG is 0-indexed and AWP is 1-indexed.

==== SgtCoords ====

Purpose: List of all the points to save SGTs for.

Filename convention: <site>.cordfile

Format: Z changes fastest, then Y, then X slowest.
<pre>
# geoproj= <projection; we usually use 1 for great circle>
# modellon= <model lon> modellat= <model lat> modelrot= <model rot, usually -55>
# xlen= <x-length> ylen= <y-length>
#
<total number of points>
<X index> <Y index> <Z index> <Single long to capture the index, in the form XXXXYYYYZZZZ> <lon> <lat> <depth in km>
...
</pre>

Generated by: PreSGT

Used by: PreSGT, PreAWP, PostAWP

==== AWP cordfile ====

Purpose: List of SGT points to save in a format usable by AWP-ODC-SGT.

Filename convention: awp.<site>.cordfile

Format: Remember that X and Y are flipped and have 1 added from RWG. The points are sorted by Y, then X, then Z, so Y changes slowest and Z changes fastest. This is flipped from the RWG cordfile because X and Y components are swapped.
<pre>
<number of points>
<X coordinate> <Y coordinate> <Z coordinate>
...
</pre>

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== Impulse source descriptions ===

We generate the initial source description for CyberShake, with the required dt, nt, and filtering, using gen_source, in https://github.com/SCECcode/cybershake-core/SimSgt_V3.0.3/src/ (run 'make get_source'). gen_source hard-codes its parameters, but you should only change 'nt', 'dt', and 'flo'. We have been setting flo to twice the CyberShake maximum frequency, to reduce filtering affects at the frequency of interest. gen_source wraps Rob Graves's source generator, which we use for consistency.

To generate a source for a component, run
<pre>
$>./gen_source xsrc=0 ysrc=0 zsrc=0 <fxsrc|fysrc|fzsrc>=1 moment=1e20
</pre>

Once this RWG source is generated, we then use AWP-GPU-SGT/utils/data/format_source.py to reprocess the RWG source into an AWP-source friendly format. This involves reformatting the file and multiplying all values by 1e15 for unit conversion. Different files must be produced for X and Y coordinates, since in the AWP format different columns are used for different components.

Finally, AWP-GPU-SGT/utils/build_src.py takes the correct AWP-friendly source (nt and dt) for a run and adds the impulse location coordinates, producing a complete AWP format source description.

==== RWG source ====

Purpose: Source description for the SGT impulse.

Filename convention: source_cos0.10_<frequency>hz

Format:
<pre>
source cos
<nt> <dt> 0 0 0.0 0.0 0.0 0.0
<value at ts0> <value at ts1> <value at ts2> <value at ts3> <value at ts4> <value at ts5>
<value at ts6> <value at ts7> <value at ts8> <value at ts9> <value at ts10> <value at ts11>
...
</pre>

Generated by: gen_source (see above)

Used by: PreAWP

==== AWP source ====

Purpose: Source description which can be used by AWP-ODC.

Filename convention: <site>_f<x or y>_src

Format: Note that X and Y coordinates are swapped between RWG and AWP format, because of how the box is defined. Additionally, RWG is 0-indexed, and AWP is 1-indexed, and the RWG values must be multiplied by 1e15 for unit conversion.
<pre>
<X index of source, same as site X index> <Y index of source, same as site Y index>
<XX impulse at ts0> <YY at ts0> <ZZ at ts0> <XY at ts0> <XZ at ts0> <YZ at ts0>
...
</pre>
Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU

=== IN3D ===

Purpose: Input file for AWP-ODC.

Filename convention: IN3D.<site>.<x or y>

Format: Specified [https://scec.usc.edu/it/AWP-ODC-SGT#IN3D here (login required)].

Generated by: PreAWP

Used by: AWP-ODC-SGT CPU, AWP-ODC-SGT GPU, PostAWP

=== AWP SGT ===

Purpose: SGT file, created by AWP-ODC-SGT.

Filename convention: awp-strain-<site>-f<x or y>

Format: binary, 4-byte floats. Points are in the same order as in the AWP SGT coordinate file, which is fast Z, X, Y. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: AWP-ODC-SGT CPU and GPU

Used by: PostAWP, NanCheck

=== RWG SGT ===

Purpose: SGT file, created by PostAWP for use in post-processing.

Filename convention: <site>_f<x or y>_<run id>.sgt

Format: binary, 4-byte floats. Points are in the same order as in the RWG coordinate file, which is fast Z, Y, X. For each point, the SGT components are stored in XX, YY, ZZ, XY, XZ, YZ order, with time fastest.
<pre>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YY component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 1st z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, 2nd z-coordinate), XX component>
...
<timeseries for nt steps, for (1st x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (2nd x-coordinate, 1st y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, 1st y-coordinate, last z-coordinate), YZ component>
<timeseries for nt steps, for (1st x-coordinate, 2nd y-coordinate, 1st z-coordinate), XX component>
...
<timeseries for nt steps, for (last x-coordinate, last y-coordinate, last z-coordinate), YZ component>
</pre>

Generated by: PostAWP

Used by: CheckSgt, DirectSynth

=== SGT header file ===

Purpose: SGT header information, used to parse and understand SGT files

Filename convention: <site>_f<x or y>_<run id>.sgthead

Format: binary. It consists of three sections:

<ol>
<li>The sgtmaster structure, described below in C. Its information can be used to set up data structures to read the rest of the SGTs.</li>
<pre>
struct sgtmaster
{
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int globnp; /* total number of SGT locations (entire model) */
int localnp; /* local number of SGT locations (this file only) */
int nt; /* number of time points */
};
</pre>
<li>The sgtindex structures, described below in C. There is one of these for each point in the SGTs, and they're used to determine the X/Y/Z indices of all the SGT points. Note that the current way of packing the X,Y,Z coordinates into the long allows for 6 digits (so maximum 1M grid points) for each component.</li>
<pre>
struct sgtindex /* indices for all 'globnp' SGT locations */
{
long long indx; /* indx= xsgt*1000000000000 + ysgt*1000000 + zsgt */
int xsgt; /* x grid location */
int ysgt; /* y grid location */
int zsgt; /* z grid location */
float h; /* grid spacing */
};
</pre>
<li>The sgtheader structures, described below in C. There is one of these for each point in the SGTs. They're used when we perform reciprocity.</li>
<pre>
struct sgtheader
{
long long indx; /* index of this SGT */
int geoproj; /* =0: RWG local flat earth; =1: RWG great circle arcs; =2: UTM */
float modellon; /* longitude of geographic origin */
float modellat; /* latitude of geographic origin */
float modelrot; /* rotation of y-axis from south (clockwise positive) */
float xshift; /* xshift of cartesian origin from geographic origin */
float yshift; /* yshift of cartesian origin from geographic origin */
int nt; /* number of time points */
float xazim; /* azimuth of X-axis in FD model (clockwise from north) */
float dt; /* time sampling */
float tst; /* start time of 1st point in GF */
float h; /* grid spacing */
float src_lat; /* site latitude */
float src_lon; /* site longitude */
float src_dep; /* site depth */
int xsrc; /* x grid location for source (station in recip. exp.) */
int ysrc; /* y grid location for source (station in recip. exp.) */
int zsrc; /* z grid location for source (station in recip. exp.) */
float sgt_lat; /* SGT location latitude */
float sgt_lon; /* SGT location longitude */
float sgt_dep; /* SGT location depth */
int xsgt; /* x grid location for output (source in recip. exp.) */
int ysgt; /* y grid location for output (source in recip. exp.) */
int zsgt; /* z grid location for output (source in recip. exp.) */
float cdist; /* straight-line distance btw site and SGT location */
float lam; /* lambda [in dyne/(cm*cm)] at output point */
float mu; /* rigidity [in dyne/(cm*cm)] at output point */
float rho; /* density [in gm/(cm*cm*cm)] at output point */
float xmom; /* moment strength of x-oriented force in this run */
float ymom; /* moment strength of y-oriented force in this run */
float zmom; /* moment strength of z-oriented force in this run */
};
</pre>
</ol>

Overall, then, the format for the file is:
<pre>
<sgtmaster>
<sgtindex for point 1>
<sgtindex for point 2>
...
<sgtindex for point globnp>
<sgtheader for point 1>
<sgtheader for point 2>
...
<sgtheader for point globnp>
</pre>

Generated by: PostAWP

Used by: DirectSynth

=== Velocity Info file ===

Purpose: Contains the 3D velocity information needed for stochastic jobs

Filename convention: velocity_info_<site>.txt

Format: Text format, three lines:

<pre>
Vs30 = <Vs30 value>
Vs500 = <Vs500 value>
VsD500 = <VsD500 value>
</pre>

Generated by: Velocity Info job

Used by: Sub Stoch DAX generator, to add these values as command-line arguments to HF Synth and LF Site Response jobs.

=== rupture list file ===

Purpose: Contains a list of all the ruptures for which low-frequency seismograms should be synthesized. This file is used to construct the tasks in DirectSynth. The number of rows, columns, and magnitude are included because DirectSynth uses this information to determine how much memory the tasks will use. This file is constructed at abstract workflow creation time.

Filename convention: rupture_file_list_<site>_<run_id>

Format: Text format, with the number of ruptures and then 1 line per rupture:

<pre>
<number of ruptures N>
<rupture geometry filename 1> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
<rupture geometry filename 2> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
...
<rupture geometry filename N> <number of hypocenters> <number of slips per hypocenter> <number of rows in the rupture geometry> <number of columns in the rupture geometry> <magnitude>
</pre>

Used by: DirectSynth

=== rupture variation info file ===

Purpose: This file provides the rvfrac (rupture velocity speed as a fraction of shear wave velocity) and random seed for each rupture variation. It is constructed at abstract workflow creation time, using values from the database. It is highly recommended that these values are stored somewhere for reproducibility, and the same values should be used for all sites so that the rupture variations are the same for all sites.

Filename convention: rvfrac_seed_values_<site>_<run_id>

Format: Text format, with the number of rupture variations and then 1 line per rupture variation:

<pre>
<number of rupture variations N>
<source ID 1> <rupture ID 1> <rupture variation ID 1> <rvfrac> <random seed>
<source ID 2> <rupture ID 2> <rupture variation ID 2> <rvfrac> <random seed>
...
<source ID N> <rupture ID N> <rupture variation ID N> <rvfrac> <random seed>
</pre>

Used by: DirectSynth, when linked with RupGen-v5.5.2 or later

=== BBP 1D Velocity file ===

Purpose: Contains 1D velocity profile information

Filename convention: The only one currently in use in CyberShake is /home/scec-02/cybershk/runs/genslip_nr_generic1d-gp01.vmod .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <not used> <not used>
<layer 2 thickness in km> <Vp> <Vs> <density> <not used> <not used>
...
<layer L thickness in km> <Vp> <Vs> <density> <not used> <not used>
</pre>

Note that the last layer has thickness 999.0.

Generated by: Rob Graves

Used by: Local VM job

=== Local VM file ===

Purpose: Contains 1D velocity profile information for use with stochastic codes

Filename convention: The only one currently in use in CyberShake is LA_Basin_BBP_14.3.0.local .

Format: Text format:

<pre>
<number of thickness layers L>
<layer 1 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
<layer 2 thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
...
<layer L thickness in km> <Vp> <Vs> <density> <Qs> <Qs>
</pre>

Note that the last layer has thickness '0.0', indicating it has no bottom.

Generated by: Local VM Job

Used by:

=== Missing variations file ===

Purpose: Lists the variations which the Check DB stage has found are missing.

Filename convention: DB_Check_Out_<PSA or RotD or Duration>_<site>

Format: For each source and rupture pair with missing variations, the following record is output in text format:

<pre>
<source ID> <rupture ID> <number N of missing rupture variations>
<ID of first missing rupture variation>
<ID of second missing rupture variation>
...
<ID of Nth missing rupture variation>
</pre>

Originally, a file in this format could be directly fed back into the DAX generator, but that capability has not been used for many years and may not still be functional.

Generated by: Check DB Site

Used by: none

=== DB Report file ===

Purpose: Provides PSA data for a run in a text format.

Filename convention: <site>_ERF<erf id>_report_<date>.txt

Format: It's a text file with the following header:
Site_Name ERF_ID Source_ID Rupture_ID Rup_Var_ID Rup_Var_Scenario_ID Mag Prob Grid_Spacing Num_Rows Num_Columns Period Component SA
The file is sorted by fast Rup_Var_ID, Rupture_ID, Source_ID, Period, slow Component.

Generated by: DB Report

Used by: none, output data product

=== Hazard Curve ===

Purpose: Contains a hazard curve, either in text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run id>_<IM type>_<period>sec_<IM component>_<date run completed>.<pdf|txt|png>

Format: The PNG and PDF formats contain an image of the curve. The PDF format also has an extended legend. The TXT file contains a list of (X,Y) points which describe the curve.

Generated by: Curve Calc

Used by: none, output data product

=== Disaggregation file ===

Purpose: Contains disaggregation results for a single run, in either text, PNG, or PDF format.

Filename convention: <site>_ERF<erf id>_Run<run_id>_Disagg<POE|IM>_<disagg level>_<IM type>_<period>sec_<run date>.<txt|png|pdf>

Format: The PNG and PDF formats contain a plot of the disaggregation results, showing magnitude vs distance and color-coding based on epsilon. The PDF and TXT formats contain additional information about individual source contributions, in the following format:

<pre>Summary data
Parameters used to create disaggregation
Disaggregation bin data:
Dist Mag <breakout by epsilon values>
<Breakdown of contribution by distance, magnitude, and epsilon range>

Disaggregation Source List Info:
Source# %Contribution TotExceedRate SourceName DistRup DistX DistSeis DistJB
<list of contributing sources, in decreasing order of % contribution>
</pre>

Generated by: Disaggregation

Used by: none, output data product

== Dependencies ==

The following are external software dependencies used by CyberShake software modules.

=== Getpar ===

Purpose: A library written in C which enables parsing of key-value command-line parameters, and enforcement of required parameters. Rob Graves uses it in his codes.

How to obtain: Rob supplied a copy; it is in the CyberShake repository at https://github.com/SCECcode/cybershake-core/tree/main/Getpar .

Special installation instructions: Run 'make' in Getpar/getpar/src; this will make the library, libget.a, and install it in the lib directory, where CyberShake codes will expect it.

=== MySQLdb ===

This library has been deprecated in favor of pymysql.

=== pymysql ===

Purpose: MySQL bindings for Python.

How to obtain: pip3 install pymysql . Documentation is at https://pypi.org/project/PyMySQL/ .

Special installation instructions: None; pip3 shouldn't have any issues.

=== UCVM ===

Purpose: Supplies the query tools needed to populate a mesh with velocity information.

How to obtain: The most recent version of UCVM can be found at [[UCVM#Current_UCVM_Software_Releases|Current UCVM Software Releases]]. As of October 2017, we have only integrated the C version of UCVM into CyberShake.

Special installation instructions: Following the standard installation instructions for a cluster should work (running ./ucvm_setup.py). You will want to install CVM-S4, CVM-S426, CVM-S4.M01, CVM-H, CenCal, CCA-06, and CCA 1D velocity models for CyberShake.

=== libcfu ===

Purpose: Provides a hash table library for a variety of CyberShake codes.

How to obtain: https://sourceforge.net/projects/libcfu/ . Documentation is at http://libcfu.sourceforge.net/libcfu.html .

Special installation instructions: Follow the instructions, and install into the utils directory.

=== FFTW ===

Purpose: Library which provides FFTs.

How to obtain: Typically installed on supercomputers already, though you may need to load a module to activate it.

Special installation instructions: Doesn't need to be installed in user space.

=== memcached ===

Purpose: Server library for running a memory caching system, using key-value pairs.

How to obtain: Download from https://memcached.org/ .

Special installation instructions: Follow instructions and install in utils directory. It has a dependency on libevent, which you may have to install also.

=== libmemcached ===

Purpose: Client library and tools for memcached server.

How to obtain: Download from http://libmemcached.org/libMemcached.html . Install memcached first.

Special installation instructions: Sometimes installing can be a challenge, because it can't find the memcached install. You may have to set the path to memcached either as an argument to configure, or you may even need to edit the configuration and makefiles directory. Install into the utils directory.

=== RupGen-api ===

Purpose: To generate rupture variations from a rupture geometry for a given hypocenter and slip using the Graves & Pitarka rupture generator. The current version is 5.5.2.

How to obtain: Check out from https://github.com/SCECcode/cybershake-core/tree/main/RuptureCodes/RupGen-api-5.5.2 .

Special installation instructions:

#This code is dependent on FFTW. You may need to edit the makefile to point to the FFTW include files and libraries, since different clusters often use different environment variables to capture FFTW paths.
#If you want memcached support, edit the makefile in RuptureCodes/RupGen-api-5.5.2/src to uncomment lines 19-21 and edit line 19 to point to the libmemcached install directory. You'll need to do the same to RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.0/makefile, lines 35-37.
#You may need to edit CFLAGS in RuptureCodes/RupGen-api-5.5.2/src/GenRandV5.5.2/makefile (lines 21-23) to point to the FFTW path; whether or not this is needed depends on the particular system.
#Run 'make' in RupGen-api-5.5.2 to make the librupgen.a library.

=== SCEC Broadband Platform ===

Purpose: To generate high-frequency stochastic seismograms for broadband CyberShake runs.

How to obtain: Follow installation instructions at https://github.com/SCECcode/bbp .

UCVM ucvm with sw4 using cvmsi

2025-11-06T22:39:41Z

Scottcal: /* Difference in Vp and Vs GTL depth traced to CVM-S4 */

== Questions 11/2025 ==

LBNL TARGET:
Performing 5 Hz simulations based on CVM.S4.26.M01 and apply additional GTL with
the Ely tapering method. For high frequency simulation requirements, the velocity model
needs some additional modifications.

=== What causes the Ripple-like pattern (bullseyes) in the cvmsi? ===

Region of interest: -118.4232,33.58, -117.3459,34.3519

Due to local borehole information that are in the CVMS(rule-based) with its GTL processing

{|
| [[FILE:bullseyes_vs_cvms.png|thumb|300px|cvms bullseyes vs]]
| [[FILE:bullseyes_vs_cvms5.png|thumb|300px|cvms5 bullseyes vs]]
| [[FILE:bullseyes_vs_cvmsi.png|thumb|300px|cvmsi bullseyes vs]]
|}

LBNL: Using taper with -z 0,700 -L 200,700,1500, to mitigate the feature

{|
| [[FILE:cvmsi_vs_taper_ripple_z700-200-500-700.png|thumb|300px|cvmsi taper vs]]
|}

=== Transition depth to high velocity differs between Vp(~400m) and Vs(~250) ===

LBNL has a variable grid size/spacing based on depth: 50m grid for 0-650m depth,
then 100m grid for 650-2500m, 200m grid for 2500-6000m, 400m grid for 6000m and below.
The horizontal and vertical spacing is the same within the same depth range.

Region of interest: 33.599659 -117.505759, 34.311847 -117.501624

{|
| [[FILE:transition_cvms_vp.png|thumb|300px|cvms transition vp]]
| [[FILE:transition_cvms_vs.png|thumb|300px|cvms transition vs]]
| [[FILE:transition_cvms_density.png|thumb|300px|cvms transition density]]
|}

{|
| [[FILE:transition_cvms5_vp.png|thumb|300px|cvms5 transition vp]]
| [[FILE:transition_cvms5_vs.png|thumb|300px|cvms5 transition vs]]
| [[FILE:transition_cvms5_density.png|thumb|300px|cvms5 transition density]]
|}

{|
| [[FILE:transition_cvmsi_vp_2.png|thumb|300px|cvmsi transition vp]]
| [[FILE:transition_cvmsi_vs.png|thumb|300px|cvmsi transition vs]]
| [[FILE:transition_cvmsi_density.png|thumb|300px|cvmsi transition density]]
|}

Difference in GTL bounds for CVM-S4.26.M01 matches with CVM-S4

about density: https://strike.scec.org/scecpedia/CVM-S4.26#Density_Based_on_Vs

=== Adding elygtl:taper introduces discontinuities ===

just cvmsi

{|
| [[FILE:cvmsi_vp_only.png|thumb|300px|cvmsi vp]]
| [[FILE:cvmsi_vs_only.png|thumb|300px|cvmsi vs]]
| [[FILE:cvmsi_density_only.png|thumb|300px|cvmsi density]]
|}

cvmsi with -z0,700 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

extending z range with -z0,1000 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

=== Difference in Vp and Vs GTL depth traced to CVM-S4 ===

We selected (33.95575, -117.50369), in the middle of the cross-sections above, and ran this point at a variety of depths through the CVM-S3 and CVM-S4 implementations from https://scedc.caltech.edu/data/3d-velocity.html .

In CVM-S version 3, we can see that there is a transition between 720 and 760m:
<pre>
Lat Lon Depth(m) Vp Vs Rho
33.95575 -117.50369 120.00 1790.2 730.8 1795.2
33.95575 -117.50369 160.00 1999.7 816.4 1888.2
33.95575 -117.50369 200.00 2322.3 948.1 2031.5
33.95575 -117.50369 240.00 2418.5 1000.0 2074.2
33.95575 -117.50369 280.00 2505.4 1000.0 2129.9
33.95575 -117.50369 320.00 2585.1 1169.1 2143.7
33.95575 -117.50369 360.00 2659.2 1218.6 2156.6
33.95575 -117.50369 400.00 2728.5 1265.4 2168.6
33.95575 -117.50369 440.00 2794.0 1310.0 2179.9
33.95575 -117.50369 480.00 2856.0 1352.5 2190.7
33.95575 -117.50369 520.00 2915.1 1393.3 2200.9
33.95575 -117.50369 560.00 2971.6 1432.5 2210.7
33.95575 -117.50369 600.00 3025.8 1470.4 2220.1
33.95575 -117.50369 640.00 3077.9 1507.0 2229.1
33.95575 -117.50369 680.00 3128.2 1542.5 2237.9
33.95575 -117.50369 720.00 3176.7 1577.0 2246.3
33.95575 -117.50369 760.00 5903.3 3424.9 2718.9
33.95575 -117.50369 800.00 5903.3 3424.9 2718.9
</pre>

In CVM-S version 4, we see that the transition is now between 160 and 200m for Vp and rho, but between 280 and 320m for Vs:

<pre>
Lat Lon Depth(m) Vp Vs Rho
33.95575 -117.50369 120.00 2770.8 980.0 2302.5
33.95575 -117.50369 160.00 4188.8 1000.0 2526.4
33.95575 -117.50369 200.00 5903.2 1000.0 2797.1
33.95575 -117.50369 240.00 5903.3 1000.0 2797.1
33.95575 -117.50369 280.00 5903.3 1000.0 2797.1
33.95575 -117.50369 320.00 5903.3 3424.9 2797.1
33.95575 -117.50369 360.00 5903.3 3424.9 2797.1
33.95575 -117.50369 400.00 5903.3 3424.9 2797.1
33.95575 -117.50369 440.00 5903.3 3424.9 2797.1
33.95575 -117.50369 480.00 5903.3 3424.9 2797.1
33.95575 -117.50369 520.00 5903.3 3424.9 2797.1
33.95575 -117.50369 560.00 5903.3 3424.9 2797.1
33.95575 -117.50369 600.00 5903.3 3424.9 2797.1
33.95575 -117.50369 640.00 5903.3 3424.9 2797.1
33.95575 -117.50369 680.00 5903.3 3424.9 2797.1
33.95575 -117.50369 720.00 5903.3 3424.9 2797.1
33.95575 -117.50369 760.00 5903.3 3424.9 2797.1
33.95575 -117.50369 800.00 5903.3 3424.9 2797.1
</pre>

The readme for CVM-S version 4 states that changes were made to the San Bernardino Valley, so perhaps that is what led to this change.

== Question 9/2025 ==

Question from Rie to Scott,

..conducting SW4 simulations within the LA Basin for both small and large magnitude earthquake events
(please see the attached slides for reference where we are interested in). While validating the ground
motions, we have come across several features in the velocity model—built from the SCEC model—that we
were hoping to better understand with your insight.

Blocky structure north of LA (highlighted in red in the slides):
We observed a blocky structure characterized by elevated Vs compared to the surrounding region. This structure appears to disappear at 50 m depth and then re-emerges below. Is there a specific reason why this structure is not present at the 50 m depth level?

Vp–Vs relationship of the blocky structure (green color):
The structure shows higher Vs values, with Vp appearing higher at the surface (Z = 0 m) but becoming lower at 250 m depth. We also noted that the density is relatively low at the surface.

Vp–density relationship west of the blocky structure:
In this nearby region, the density is higher than that of the surrounding material, but Vp appears to be lower. (I expect Vp correlates with density)

Would you know of any literature or documentation that describe these characteristics?

=== Background of the posted question ===

Accessing UCVM velocity model via SW4's UCVM reader branch and then run the SW4 simulation.

CVM-S4.26.M01 (cvmsi), the velocity values are extracted using UCVM "withSCPBR" branch

internal query parameters were:

ucvm_query -f conf/ucvm.conf -m cvmsi,elygtl:taper -L 200,700,1500

Is this version of velocity model, recommended for ground motion simulation ? (another question)

=== Response from Scott ===

It looks like the blocky structure appears in the original CVM-S4 (https://strike.scec.org/scecpedia/UCVM_ucvm_with_sw4_using_cvmsi#Base_cvm, top row), and therefore also appears in CVM-S4.26 and CVM-S4.26.M01, both of which were derived from it. I believe this is the northern edge of the LA basin as defined in the original CVM-S4. When using this model for CyberShake Study 22.12 with the Ely taper, we didn't see this sharp east-west boundary. You can see our cross sections at https://strike.scec.org/scecpedia/CyberShake_Study_22.12#Cross-sections, in the 3rd column. However, we ran with a minimum Vs of 500 m/s and 100m grid spacing.

For question 1), I think this has to do with the way the merged taper is applied. The taper is constrained by the Thompson et al. (2022) Vs30 values, but every mesh point is evaluated when determining if to apply the taper or not. In other words, at (34.0, -118.0, 0m), the Vs values are calculated with and without the taper, and the method with the lowest Vs is selected. But then this process is repeated at 50m, 100m, etc., so at some depths the taper might be selected and at others not. I pulled Vs profiles of the top 500m for (-118, 34.1), which is in the dark blue region; (-118, 34.2), in the teal region; and (-118, 34.3), in the lime green region (attached as taper 34_1.png, taper 34_2.png, taper 34_3.png). From the smoothness of the profiles, it looks like the taper is always used for 34.1 and 34.3, but not always for 34.2. As a result, sometimes the points in the teal region are closer to the lime green region, meaning the blocky structure disappears, and sometimes they are closer to the dark blue region, meaning the blocky structure reappears.

For 2), it looks to me like at the surface Vp~1100 m/s and Vs~400 m/s, and at 250m depth Vp~4500 m/s and Vs~1800 m/s, since the color bars change dramatically from z=0 to z=250m.

For 3), I extracted velocity profiles with and without the merged taper. In the region you highlighted, even without the taper the Vp value hits the floor at 700 m/s, but density is about 2000 km/m3 (see attached "all props no taper.png"). This is also true in the original CVM-S4 model. So this isn't a result of the taper, but rather a native feature. Since I wasn't involved in the original model construction, I'm not sure what the logic is for these values, but they do seem to be what was intended in CVM-S4 and its derivatives.

Please let me know if you have follow-up questions. We can also discuss modifications to the model if you'd like to avoid some of these features; for example, I know Hu et al. (2022) [https://doi.org/10.1093/gji/ggac175] used an alternative method for deciding where to apply the taper.

=== Plots from explorer with the posted parameters ===

{|
| [[FILE:sw4_cvmsi_taper_200_map.png|thumb|300px|cvmsi taper200 map]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_0m.png|thumb|300px|cvmsi taper200 0m]]
| [[FILE:sw4_cvmsi_taper_200_50m.png|thumb|300px|cvmsi taper200 50m]]
| [[FILE:sw4_cvmsi_taper_200_100m.png|thumb|300px|cvmsi taper200 100m]]
| [[FILE:sw4_cvmsi_taper_200_250m.png|thumb|300px|cvmsi taper200 250m]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line1_map.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line1.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line2_map.png|thumb|300px|cvmsi taper200 line2]]
| [[FILE:sw4_cvmsi_taper_200_line2.png|thumb|300px|cvmsi taper200 line2]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line3_map.png|thumb|300px|cvmsi taper200 line3]]
| [[FILE:sw4_cvmsi_taper_200_line3.png|thumb|300px|cvmsi taper200 line3]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt_map.png|thumb|300px|cvmsi taper200 pt]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt1.png|thumb|300px|cvmsi taper200 pt1]]
| [[FILE:sw4_cvmsi_taper_200_pt2.png|thumb|300px|cvmsi taper200 pt2]]
| [[FILE:sw4_cvmsi_taper_200_pt3.png|thumb|300px|cvmsi taper200 pt3]]
| [[FILE:sw4_cvmsi_taper_200_pt4.png|thumb|300px|cvmsi taper200 pt4]]
|}

=== Base cvm ===

{|
| [[FILE:sw4_cvms_0m.png|thumb|300px|cvms 0m]]
| [[FILE:sw4_cvms5_0m.png|thumb|300px|cvms5 0m]]
| [[FILE:sw4_cvmsi_0m.png|thumb|300px|cvmsi 0m]]
|}

{|
| [[FILE:sw4_cvmsi_50m.png|thumb|300px|cvmsi 50m]]
| [[FILE:sw4_cvmsi_100m.png|thumb|300px|cvmsi 100m]]
| [[FILE:sw4_cvmsi_250m.png|thumb|300px|cvmsi 250m]]
|}

{|
| [[FILE:sw4_cvmsi_all_0m.png|thumb|300px|cvmsi all 0m]]
| [[FILE:sw4_cvmsi_all_50m.png|thumb|300px|cvmsi all 50m]]
| [[FILE:sw4_cvmsi_all_100m.png|thumb|300px|cvmsi all 100m]]
| [[FILE:sw4_cvmsi_all_250m.png|thumb|300px|cvmsi all 250m]]
|}

looking at basin,

{|
| [[FILE:sw4_cvmsi_basin_a.png|thumb|300px|cvmsi basin a]]
| [[FILE:sw4_cvmsi_basin_b.png|thumb|300px|cvmsi basin b]]
|}

=== using elygtl:ely ===

{|
| [[FILE:sw4_cvmsi_ely0_0m.png|thumb|300px|cvmsi ely0 0m]]
|}

UCVM ucvm with sw4 using cvmsi

2025-11-06T22:37:48Z

Scottcal: /* Difference in Vp and Vs GTL depth traced to CVM-S4 */

== Questions 11/2025 ==

LBNL TARGET:
Performing 5 Hz simulations based on CVM.S4.26.M01 and apply additional GTL with
the Ely tapering method. For high frequency simulation requirements, the velocity model
needs some additional modifications.

=== What causes the Ripple-like pattern (bullseyes) in the cvmsi? ===

Region of interest: -118.4232,33.58, -117.3459,34.3519

Due to local borehole information that are in the CVMS(rule-based) with its GTL processing

{|
| [[FILE:bullseyes_vs_cvms.png|thumb|300px|cvms bullseyes vs]]
| [[FILE:bullseyes_vs_cvms5.png|thumb|300px|cvms5 bullseyes vs]]
| [[FILE:bullseyes_vs_cvmsi.png|thumb|300px|cvmsi bullseyes vs]]
|}

LBNL: Using taper with -z 0,700 -L 200,700,1500, to mitigate the feature

{|
| [[FILE:cvmsi_vs_taper_ripple_z700-200-500-700.png|thumb|300px|cvmsi taper vs]]
|}

=== Transition depth to high velocity differs between Vp(~400m) and Vs(~250) ===

LBNL has a variable grid size/spacing based on depth: 50m grid for 0-650m depth,
then 100m grid for 650-2500m, 200m grid for 2500-6000m, 400m grid for 6000m and below.
The horizontal and vertical spacing is the same within the same depth range.

Region of interest: 33.599659 -117.505759, 34.311847 -117.501624

{|
| [[FILE:transition_cvms_vp.png|thumb|300px|cvms transition vp]]
| [[FILE:transition_cvms_vs.png|thumb|300px|cvms transition vs]]
| [[FILE:transition_cvms_density.png|thumb|300px|cvms transition density]]
|}

{|
| [[FILE:transition_cvms5_vp.png|thumb|300px|cvms5 transition vp]]
| [[FILE:transition_cvms5_vs.png|thumb|300px|cvms5 transition vs]]
| [[FILE:transition_cvms5_density.png|thumb|300px|cvms5 transition density]]
|}

{|
| [[FILE:transition_cvmsi_vp_2.png|thumb|300px|cvmsi transition vp]]
| [[FILE:transition_cvmsi_vs.png|thumb|300px|cvmsi transition vs]]
| [[FILE:transition_cvmsi_density.png|thumb|300px|cvmsi transition density]]
|}

Difference in GTL bounds for CVM-S4.26.M01 matches with CVM-S4

about density: https://strike.scec.org/scecpedia/CVM-S4.26#Density_Based_on_Vs

=== Adding elygtl:taper introduces discontinuities ===

just cvmsi

{|
| [[FILE:cvmsi_vp_only.png|thumb|300px|cvmsi vp]]
| [[FILE:cvmsi_vs_only.png|thumb|300px|cvmsi vs]]
| [[FILE:cvmsi_density_only.png|thumb|300px|cvmsi density]]
|}

cvmsi with -z0,700 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

extending z range with -z0,1000 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

=== Difference in Vp and Vs GTL depth traced to CVM-S4 ===

We selected (33.95575, -117.50369), in the middle of the cross-sections above, and ran this point at a variety of depths through the CVM-S3 and CVM-S4 implementations from https://scedc.caltech.edu/data/3d-velocity.html .

CVM-S version 3:
<pre>
Lat Lon Depth(m) Vp Vs Rho
33.95575 -117.50369 120.00 2770.8 980.0 2302.5
33.95575 -117.50369 160.00 4188.8 1000.0 2526.4
33.95575 -117.50369 200.00 5903.2 1000.0 2797.1
33.95575 -117.50369 240.00 5903.3 1000.0 2797.1
33.95575 -117.50369 280.00 5903.3 1000.0 2797.1
33.95575 -117.50369 320.00 5903.3 3424.9 2797.1
33.95575 -117.50369 360.00 5903.3 3424.9 2797.1
33.95575 -117.50369 400.00 5903.3 3424.9 2797.1
33.95575 -117.50369 440.00 5903.3 3424.9 2797.1
33.95575 -117.50369 480.00 5903.3 3424.9 2797.1
33.95575 -117.50369 520.00 5903.3 3424.9 2797.1
33.95575 -117.50369 560.00 5903.3 3424.9 2797.1
33.95575 -117.50369 600.00 5903.3 3424.9 2797.1
33.95575 -117.50369 640.00 5903.3 3424.9 2797.1
33.95575 -117.50369 680.00 5903.3 3424.9 2797.1
33.95575 -117.50369 720.00 5903.3 3424.9 2797.1
33.95575 -117.50369 760.00 5903.3 3424.9 2797.1
33.95575 -117.50369 800.00 5903.3 3424.9 2797.1
</pre>

== Question 9/2025 ==

Question from Rie to Scott,

..conducting SW4 simulations within the LA Basin for both small and large magnitude earthquake events
(please see the attached slides for reference where we are interested in). While validating the ground
motions, we have come across several features in the velocity model—built from the SCEC model—that we
were hoping to better understand with your insight.

Blocky structure north of LA (highlighted in red in the slides):
We observed a blocky structure characterized by elevated Vs compared to the surrounding region. This structure appears to disappear at 50 m depth and then re-emerges below. Is there a specific reason why this structure is not present at the 50 m depth level?

Vp–Vs relationship of the blocky structure (green color):
The structure shows higher Vs values, with Vp appearing higher at the surface (Z = 0 m) but becoming lower at 250 m depth. We also noted that the density is relatively low at the surface.

Vp–density relationship west of the blocky structure:
In this nearby region, the density is higher than that of the surrounding material, but Vp appears to be lower. (I expect Vp correlates with density)

Would you know of any literature or documentation that describe these characteristics?

=== Background of the posted question ===

Accessing UCVM velocity model via SW4's UCVM reader branch and then run the SW4 simulation.

CVM-S4.26.M01 (cvmsi), the velocity values are extracted using UCVM "withSCPBR" branch

internal query parameters were:

ucvm_query -f conf/ucvm.conf -m cvmsi,elygtl:taper -L 200,700,1500

Is this version of velocity model, recommended for ground motion simulation ? (another question)

=== Response from Scott ===

It looks like the blocky structure appears in the original CVM-S4 (https://strike.scec.org/scecpedia/UCVM_ucvm_with_sw4_using_cvmsi#Base_cvm, top row), and therefore also appears in CVM-S4.26 and CVM-S4.26.M01, both of which were derived from it. I believe this is the northern edge of the LA basin as defined in the original CVM-S4. When using this model for CyberShake Study 22.12 with the Ely taper, we didn't see this sharp east-west boundary. You can see our cross sections at https://strike.scec.org/scecpedia/CyberShake_Study_22.12#Cross-sections, in the 3rd column. However, we ran with a minimum Vs of 500 m/s and 100m grid spacing.

For question 1), I think this has to do with the way the merged taper is applied. The taper is constrained by the Thompson et al. (2022) Vs30 values, but every mesh point is evaluated when determining if to apply the taper or not. In other words, at (34.0, -118.0, 0m), the Vs values are calculated with and without the taper, and the method with the lowest Vs is selected. But then this process is repeated at 50m, 100m, etc., so at some depths the taper might be selected and at others not. I pulled Vs profiles of the top 500m for (-118, 34.1), which is in the dark blue region; (-118, 34.2), in the teal region; and (-118, 34.3), in the lime green region (attached as taper 34_1.png, taper 34_2.png, taper 34_3.png). From the smoothness of the profiles, it looks like the taper is always used for 34.1 and 34.3, but not always for 34.2. As a result, sometimes the points in the teal region are closer to the lime green region, meaning the blocky structure disappears, and sometimes they are closer to the dark blue region, meaning the blocky structure reappears.

For 2), it looks to me like at the surface Vp~1100 m/s and Vs~400 m/s, and at 250m depth Vp~4500 m/s and Vs~1800 m/s, since the color bars change dramatically from z=0 to z=250m.

For 3), I extracted velocity profiles with and without the merged taper. In the region you highlighted, even without the taper the Vp value hits the floor at 700 m/s, but density is about 2000 km/m3 (see attached "all props no taper.png"). This is also true in the original CVM-S4 model. So this isn't a result of the taper, but rather a native feature. Since I wasn't involved in the original model construction, I'm not sure what the logic is for these values, but they do seem to be what was intended in CVM-S4 and its derivatives.

Please let me know if you have follow-up questions. We can also discuss modifications to the model if you'd like to avoid some of these features; for example, I know Hu et al. (2022) [https://doi.org/10.1093/gji/ggac175] used an alternative method for deciding where to apply the taper.

=== Plots from explorer with the posted parameters ===

{|
| [[FILE:sw4_cvmsi_taper_200_map.png|thumb|300px|cvmsi taper200 map]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_0m.png|thumb|300px|cvmsi taper200 0m]]
| [[FILE:sw4_cvmsi_taper_200_50m.png|thumb|300px|cvmsi taper200 50m]]
| [[FILE:sw4_cvmsi_taper_200_100m.png|thumb|300px|cvmsi taper200 100m]]
| [[FILE:sw4_cvmsi_taper_200_250m.png|thumb|300px|cvmsi taper200 250m]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line1_map.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line1.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line2_map.png|thumb|300px|cvmsi taper200 line2]]
| [[FILE:sw4_cvmsi_taper_200_line2.png|thumb|300px|cvmsi taper200 line2]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line3_map.png|thumb|300px|cvmsi taper200 line3]]
| [[FILE:sw4_cvmsi_taper_200_line3.png|thumb|300px|cvmsi taper200 line3]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt_map.png|thumb|300px|cvmsi taper200 pt]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt1.png|thumb|300px|cvmsi taper200 pt1]]
| [[FILE:sw4_cvmsi_taper_200_pt2.png|thumb|300px|cvmsi taper200 pt2]]
| [[FILE:sw4_cvmsi_taper_200_pt3.png|thumb|300px|cvmsi taper200 pt3]]
| [[FILE:sw4_cvmsi_taper_200_pt4.png|thumb|300px|cvmsi taper200 pt4]]
|}

=== Base cvm ===

{|
| [[FILE:sw4_cvms_0m.png|thumb|300px|cvms 0m]]
| [[FILE:sw4_cvms5_0m.png|thumb|300px|cvms5 0m]]
| [[FILE:sw4_cvmsi_0m.png|thumb|300px|cvmsi 0m]]
|}

{|
| [[FILE:sw4_cvmsi_50m.png|thumb|300px|cvmsi 50m]]
| [[FILE:sw4_cvmsi_100m.png|thumb|300px|cvmsi 100m]]
| [[FILE:sw4_cvmsi_250m.png|thumb|300px|cvmsi 250m]]
|}

{|
| [[FILE:sw4_cvmsi_all_0m.png|thumb|300px|cvmsi all 0m]]
| [[FILE:sw4_cvmsi_all_50m.png|thumb|300px|cvmsi all 50m]]
| [[FILE:sw4_cvmsi_all_100m.png|thumb|300px|cvmsi all 100m]]
| [[FILE:sw4_cvmsi_all_250m.png|thumb|300px|cvmsi all 250m]]
|}

looking at basin,

{|
| [[FILE:sw4_cvmsi_basin_a.png|thumb|300px|cvmsi basin a]]
| [[FILE:sw4_cvmsi_basin_b.png|thumb|300px|cvmsi basin b]]
|}

=== using elygtl:ely ===

{|
| [[FILE:sw4_cvmsi_ely0_0m.png|thumb|300px|cvmsi ely0 0m]]
|}

UCVM ucvm with sw4 using cvmsi

2025-11-06T22:36:14Z

Scottcal:

== Questions 11/2025 ==

LBNL TARGET:
Performing 5 Hz simulations based on CVM.S4.26.M01 and apply additional GTL with
the Ely tapering method. For high frequency simulation requirements, the velocity model
needs some additional modifications.

=== What causes the Ripple-like pattern (bullseyes) in the cvmsi? ===

Region of interest: -118.4232,33.58, -117.3459,34.3519

Due to local borehole information that are in the CVMS(rule-based) with its GTL processing

{|
| [[FILE:bullseyes_vs_cvms.png|thumb|300px|cvms bullseyes vs]]
| [[FILE:bullseyes_vs_cvms5.png|thumb|300px|cvms5 bullseyes vs]]
| [[FILE:bullseyes_vs_cvmsi.png|thumb|300px|cvmsi bullseyes vs]]
|}

LBNL: Using taper with -z 0,700 -L 200,700,1500, to mitigate the feature

{|
| [[FILE:cvmsi_vs_taper_ripple_z700-200-500-700.png|thumb|300px|cvmsi taper vs]]
|}

=== Transition depth to high velocity differs between Vp(~400m) and Vs(~250) ===

LBNL has a variable grid size/spacing based on depth: 50m grid for 0-650m depth,
then 100m grid for 650-2500m, 200m grid for 2500-6000m, 400m grid for 6000m and below.
The horizontal and vertical spacing is the same within the same depth range.

Region of interest: 33.599659 -117.505759, 34.311847 -117.501624

{|
| [[FILE:transition_cvms_vp.png|thumb|300px|cvms transition vp]]
| [[FILE:transition_cvms_vs.png|thumb|300px|cvms transition vs]]
| [[FILE:transition_cvms_density.png|thumb|300px|cvms transition density]]
|}

{|
| [[FILE:transition_cvms5_vp.png|thumb|300px|cvms5 transition vp]]
| [[FILE:transition_cvms5_vs.png|thumb|300px|cvms5 transition vs]]
| [[FILE:transition_cvms5_density.png|thumb|300px|cvms5 transition density]]
|}

{|
| [[FILE:transition_cvmsi_vp_2.png|thumb|300px|cvmsi transition vp]]
| [[FILE:transition_cvmsi_vs.png|thumb|300px|cvmsi transition vs]]
| [[FILE:transition_cvmsi_density.png|thumb|300px|cvmsi transition density]]
|}

Difference in GTL bounds for CVM-S4.26.M01 matches with CVM-S4

about density: https://strike.scec.org/scecpedia/CVM-S4.26#Density_Based_on_Vs

=== Adding elygtl:taper introduces discontinuities ===

just cvmsi

{|
| [[FILE:cvmsi_vp_only.png|thumb|300px|cvmsi vp]]
| [[FILE:cvmsi_vs_only.png|thumb|300px|cvmsi vs]]
| [[FILE:cvmsi_density_only.png|thumb|300px|cvmsi density]]
|}

cvmsi with -z0,700 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z700-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

extending z range with -z0,1000 and -L 200,700,1500

{|
| [[FILE:cvmsi_vp_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vp 700z]]
| [[FILE:cvmsi_vs_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper vs 700z]]
| [[FILE:cvmsi_density_taper_z1000-200-700-1500.png|thumb|300px|cvmsi taper density 700z]]
|}

=== Difference in Vp and Vs GTL depth traced to CVM-S4 ===

Looking at (33.95575, -117.50369), in the

== Question 9/2025 ==

Question from Rie to Scott,

..conducting SW4 simulations within the LA Basin for both small and large magnitude earthquake events
(please see the attached slides for reference where we are interested in). While validating the ground
motions, we have come across several features in the velocity model—built from the SCEC model—that we
were hoping to better understand with your insight.

Blocky structure north of LA (highlighted in red in the slides):
We observed a blocky structure characterized by elevated Vs compared to the surrounding region. This structure appears to disappear at 50 m depth and then re-emerges below. Is there a specific reason why this structure is not present at the 50 m depth level?

Vp–Vs relationship of the blocky structure (green color):
The structure shows higher Vs values, with Vp appearing higher at the surface (Z = 0 m) but becoming lower at 250 m depth. We also noted that the density is relatively low at the surface.

Vp–density relationship west of the blocky structure:
In this nearby region, the density is higher than that of the surrounding material, but Vp appears to be lower. (I expect Vp correlates with density)

Would you know of any literature or documentation that describe these characteristics?

=== Background of the posted question ===

Accessing UCVM velocity model via SW4's UCVM reader branch and then run the SW4 simulation.

CVM-S4.26.M01 (cvmsi), the velocity values are extracted using UCVM "withSCPBR" branch

internal query parameters were:

ucvm_query -f conf/ucvm.conf -m cvmsi,elygtl:taper -L 200,700,1500

Is this version of velocity model, recommended for ground motion simulation ? (another question)

=== Response from Scott ===

It looks like the blocky structure appears in the original CVM-S4 (https://strike.scec.org/scecpedia/UCVM_ucvm_with_sw4_using_cvmsi#Base_cvm, top row), and therefore also appears in CVM-S4.26 and CVM-S4.26.M01, both of which were derived from it. I believe this is the northern edge of the LA basin as defined in the original CVM-S4. When using this model for CyberShake Study 22.12 with the Ely taper, we didn't see this sharp east-west boundary. You can see our cross sections at https://strike.scec.org/scecpedia/CyberShake_Study_22.12#Cross-sections, in the 3rd column. However, we ran with a minimum Vs of 500 m/s and 100m grid spacing.

For question 1), I think this has to do with the way the merged taper is applied. The taper is constrained by the Thompson et al. (2022) Vs30 values, but every mesh point is evaluated when determining if to apply the taper or not. In other words, at (34.0, -118.0, 0m), the Vs values are calculated with and without the taper, and the method with the lowest Vs is selected. But then this process is repeated at 50m, 100m, etc., so at some depths the taper might be selected and at others not. I pulled Vs profiles of the top 500m for (-118, 34.1), which is in the dark blue region; (-118, 34.2), in the teal region; and (-118, 34.3), in the lime green region (attached as taper 34_1.png, taper 34_2.png, taper 34_3.png). From the smoothness of the profiles, it looks like the taper is always used for 34.1 and 34.3, but not always for 34.2. As a result, sometimes the points in the teal region are closer to the lime green region, meaning the blocky structure disappears, and sometimes they are closer to the dark blue region, meaning the blocky structure reappears.

For 2), it looks to me like at the surface Vp~1100 m/s and Vs~400 m/s, and at 250m depth Vp~4500 m/s and Vs~1800 m/s, since the color bars change dramatically from z=0 to z=250m.

For 3), I extracted velocity profiles with and without the merged taper. In the region you highlighted, even without the taper the Vp value hits the floor at 700 m/s, but density is about 2000 km/m3 (see attached "all props no taper.png"). This is also true in the original CVM-S4 model. So this isn't a result of the taper, but rather a native feature. Since I wasn't involved in the original model construction, I'm not sure what the logic is for these values, but they do seem to be what was intended in CVM-S4 and its derivatives.

Please let me know if you have follow-up questions. We can also discuss modifications to the model if you'd like to avoid some of these features; for example, I know Hu et al. (2022) [https://doi.org/10.1093/gji/ggac175] used an alternative method for deciding where to apply the taper.

=== Plots from explorer with the posted parameters ===

{|
| [[FILE:sw4_cvmsi_taper_200_map.png|thumb|300px|cvmsi taper200 map]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_0m.png|thumb|300px|cvmsi taper200 0m]]
| [[FILE:sw4_cvmsi_taper_200_50m.png|thumb|300px|cvmsi taper200 50m]]
| [[FILE:sw4_cvmsi_taper_200_100m.png|thumb|300px|cvmsi taper200 100m]]
| [[FILE:sw4_cvmsi_taper_200_250m.png|thumb|300px|cvmsi taper200 250m]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line1_map.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line1.png|thumb|300px|cvmsi taper200 line1]]
| [[FILE:sw4_cvmsi_taper_200_line2_map.png|thumb|300px|cvmsi taper200 line2]]
| [[FILE:sw4_cvmsi_taper_200_line2.png|thumb|300px|cvmsi taper200 line2]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_line3_map.png|thumb|300px|cvmsi taper200 line3]]
| [[FILE:sw4_cvmsi_taper_200_line3.png|thumb|300px|cvmsi taper200 line3]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt_map.png|thumb|300px|cvmsi taper200 pt]]
|}

{|
| [[FILE:sw4_cvmsi_taper_200_pt1.png|thumb|300px|cvmsi taper200 pt1]]
| [[FILE:sw4_cvmsi_taper_200_pt2.png|thumb|300px|cvmsi taper200 pt2]]
| [[FILE:sw4_cvmsi_taper_200_pt3.png|thumb|300px|cvmsi taper200 pt3]]
| [[FILE:sw4_cvmsi_taper_200_pt4.png|thumb|300px|cvmsi taper200 pt4]]
|}

=== Base cvm ===

{|
| [[FILE:sw4_cvms_0m.png|thumb|300px|cvms 0m]]
| [[FILE:sw4_cvms5_0m.png|thumb|300px|cvms5 0m]]
| [[FILE:sw4_cvmsi_0m.png|thumb|300px|cvmsi 0m]]
|}

{|
| [[FILE:sw4_cvmsi_50m.png|thumb|300px|cvmsi 50m]]
| [[FILE:sw4_cvmsi_100m.png|thumb|300px|cvmsi 100m]]
| [[FILE:sw4_cvmsi_250m.png|thumb|300px|cvmsi 250m]]
|}

{|
| [[FILE:sw4_cvmsi_all_0m.png|thumb|300px|cvmsi all 0m]]
| [[FILE:sw4_cvmsi_all_50m.png|thumb|300px|cvmsi all 50m]]
| [[FILE:sw4_cvmsi_all_100m.png|thumb|300px|cvmsi all 100m]]
| [[FILE:sw4_cvmsi_all_250m.png|thumb|300px|cvmsi all 250m]]
|}

looking at basin,

{|
| [[FILE:sw4_cvmsi_basin_a.png|thumb|300px|cvmsi basin a]]
| [[FILE:sw4_cvmsi_basin_b.png|thumb|300px|cvmsi basin b]]
|}

=== using elygtl:ely ===

{|
| [[FILE:sw4_cvmsi_ely0_0m.png|thumb|300px|cvmsi ely0 0m]]
|}

CyberShake Study 24.8

2025-10-01T16:47:03Z

Scottcal: /* Data Products */

CyberShake Study 24.8 is a study in Northern California which includes deterministic low-frequency (0-1 Hz) and stochastic high-frequency (1-50 Hz) simulations. We will use the [[Rupture_Variation_Generator_v5.5.2|Graves & Pitarka (2022)]] rupture generator and the high frequency modules from the SCEC Broadband Platform v22.4. This study includes vertical component seismograms, period-dependent durations, and Fourier spectra IMs, and a reduction in minimum Vs to 400 m/s.

== Status ==

This study was completed on 11/8/24 at 6:15:15 PST.

The low-frequency calculations finished on 10/30/24 at 04:52:52 PDT.

Study results are posted below.

== Data Products ==

Low-frequency hazard maps are available here: [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_lf/hazard_maps/ Low-frequency Hazard Maps].

Low-frequency GMM comparisons are available here, using [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_lf/gmpe_comparisons_NGAWest_2014_NoIdr_Vs30Simulation/ top velocity mesh value as Vs30] and [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_lf/gmpe_comparisons_NGAWest_2014_NoIdr_Vs30Thompson2020/ Thompson Vs30].

Broadband hazard maps are available here: [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_bb/hazard_maps/ Broadband Hazard Maps].

Broadband GMM comparisons are available here: [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_bb/gmpe_comparisons_NGAWest_2014_NoIdr_Vs30Thompson2020/ Broadband GMM Comparisons].

Updated statewide maps using Study 24.8 and Study 22.12 results are available here: [https://opensha.usc.edu/ftp/kmilner/markdown/cybershake-analysis/study_24_8_lf/multi_study_hazard_maps/resources/ 2025 Statewide Maps].

== Science Goals ==

The science goals for this study are:

*To perform an updated broadband study for the greater Bay Area.
*To use an updated rupture generator and improved velocity model from Study 18.8.
*To use the same parameters as in Study 22.12 when possible to make comparisons between the studies simple.

== Technical Goals ==

The technical goals for this study are:

*Use Frontier for the SGTs and Frontera for the post-processing and high-frequency calculations.
*Use a modified approach for the production database, to improve performance.

== Sites ==

For this study, we chose to focus on a smaller region than in [[CyberShake_Study_18.8#Sites | Study 18.8]]. Starting with the Study 18.8 region, we selected a smaller (180 km x 100 km) box extending roughly from San Jose to Santa Rosa, containing 315 sites.

{|
| [[File:Study_24_1_site_map.png|600px]]
|}

*[[Media:Study_24.1_sites.csv|CSV site list]]
*[[Media:Study_24.1_sites_names.kml|KML site list with names]]
*[[Media:Study_24.1_sites_no_names.kml|KML site list without names]]

== Ruptures to Include ==

Summary: we decided to exclude the southern San Andreas events from Study 24.8. This was implemented by creating a new ERF with ID 64, which includes all the ERF 36 ruptures except for the southern San Andreas events.

Historically, we have determined which ruptures to include in a CyberShake run by calculating the distance between the site and the closest part of the rupture surface. If that distance is less than 200 km, we then include all ruptures which take place on that surface, including ruptures which may extend much farther away from the site than 200 km.

For Northern California sites, this means that sites around San Jose and south include southern San Andreas events (events which rupture the northernmost segment of the southern San Andreas) within 200 km. Since there are some UCERF2 ruptures which extend from the Parkfield segment all the way down to Bombay Beach, the simulation volumes for some of these Northern California sites cover most of the state. This was the case for Study 18.8 (sample volumes can be seen [[Study_18.5_Velocity_Model_Comparisons#Cross-sections_from_production_velocity_mesh|on this page]]). This required tiling together 3 3D models and a background 1D model.

To simplify the velocity model and reduce the volumes, we are investigating omitting southern San Andreas events from this study.

=== Source Contribution Curves ===

Below are source contribution curves for 3 sites: s3430 (southwest corner of the study region), s3446 (southeast corner of the study region), and SJO (San Jose). In general, the sSAF events are about the 3rd largest contributor at long periods and medium-to-long return periods.

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec
|-
! s3430
| [[File:s3430_run6408_2sec_contributions.png|thumb|300px]]
| [[File:s3430_run6408_3sec_contributions.png|thumb|300px]]
| [[File:s3430_run6408_5sec_contributions.png|thumb|300px]]
| [[File:s3430_run6408_10sec_contributions.png|thumb|300px]]
|-
! s3446
| [[File:s3446_run6452_2sec_contributions.png|thumb|300px]]
| [[File:s3446_run6452_3sec_contributions.png|thumb|300px]]
| [[File:s3446_run6452_5sec_contributions.png|thumb|300px]]
| [[File:s3446_run6452_10sec_contributions.png|thumb|300px]]
|-
! SJO
| [[File:SJO_run6987_2sec_contributions.png|thumb|300px]]
| [[File:SJO_run6987_3sec_contributions.png|thumb|300px]]
| [[File:SJO_run6987_5sec_contributions.png|thumb|300px]]
| [[File:SJO_run6987_10sec_contributions.png|thumb|300px]]
|-
|}

We also looked at the source contributions for these 3 sites from ASK 2014. In general, the sSAF events play a reduced role compared to the CyberShake results.

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec
|-
! s3430
| [[File:s3430_ASK2014_2sec_contributions.png|thumb|300px]]
| [[File:s3430_ASK2014_3sec_contributions.png|thumb|300px]]
| [[File:s3430_ASK2014_5sec_contributions.png|thumb|300px]]
| [[File:s3430_ASK2014_10sec_contributions.png|thumb|300px]]
|-
! s3446
| [[File:s3446_ASK2014_2sec_contributions.png|thumb|300px]]
| [[File:s3446_ASK2014_3sec_contributions.png|thumb|300px]]
| [[File:s3446_ASK2014_5sec_contributions.png|thumb|300px]]
| [[File:s3446_ASK2014_10sec_contributions.png|thumb|300px]]
|-
! SJO
| [[File:SJO_ASK2014_2sec_contributions.png|thumb|300px]]
| [[File:SJO_ASK2014_3sec_contributions.png|thumb|300px]]
| [[File:SJO_ASK2014_5sec_contributions.png|thumb|300px]]
| [[File:SJO_ASK2014_10sec_contributions.png|thumb|300px]]
|-
|}

=== Disaggregations ===

From Study 18.8, we looked at disaggregations for s3430, s3446, and SJO at 1e-3 (1000 yr), 4e-4 (2500 yr), and 1e-4 (10000 yr) probability levels, at 2 and 10 seconds. We list the top 3 contributing sources from the southern SAF, their magnitude ranges, and their contributing percentages.

The only significant contributions are for site s3446 at 10 second period. Those come from large events, with median magnitude 7.85 or higher.

==== s3430 ====

{| border="1" cellpadding="3"
! Period !! 1e-3 !! 4e-4 !! 1e-4
|-
! 2 sec
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
|-
! 10 sec
| 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), 0.01% 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), 0.01% 85 (S. San Andreas;PK+CH+CC+BB+NM+SM, M7.55-8.15), <0.01%
| 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), <0.01% 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
|}

==== s3446 ====
{| border="1" cellpadding="3"
! Period !! 1e-3 !! 4e-4 !! 1e-4
|-
! 2 sec
| 84 (S. San Andreas;PK+CH+CC+BB+NM, M7.45-7.95), <0.01% 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), <0.01% 80 (S. San Andreas;PK, M5.65-6.35), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
|-
! 10 sec
| 85 (S. San Andreas;PK+CH+CC+BB+NM+SM, M7.55-8.15), 6.83% 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), 4.18% 84 (S. San Andreas;PK+CH+CC+BB+NM, M7.45-7.95), 1.53%
| 85 (S. San Andreas;PK+CH+CC+BB+NM+SM, M7.55-8.15), 4.27% 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), 3.09% 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), 1.08%
| 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), 1.19% 85 (S. San Andreas;PK+CH+CC+BB+NM+SM, M7.55-8.15), 1.19% 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), 0.55%
|}

==== SJO ====
{|border="1" cellpadding="3"
! Period !! 1e-3 !! 4e-4 !! 1e-4
|-
! 2 sec
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
|-
! 10 sec
| 85 (S. San Andreas;PK+CH+CC+BB+NM+SM, M7.55-8.15), 0.09% 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), 0.07% 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), 0.05%
| 89 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG+CO, M7.75-8.45), 0.01% 88 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB+SSB+BG, M7.75-8.35), 0.01% 86 (S. San Andreas;PK+CH+CC+BB+NM+SM+NSB, M7.65-8.25), <0.01%
| 80 (S. San Andreas;PK, M5.65-6.35), <0.01% 81 (S. San Andreas;PK+CH, M6.75-7.35), <0.01%82 (S. San Andreas;PK+CH+CC, M7.15-7.65), <0.01%
|}

== Velocity Model ==

We will perform validation of the proposed velocity model using northern California BBP events.

To line up closely with the USGS SF model angle, we will generate volumes using an angle of -36 degrees.

For generating sample meshes, we will use site s3446, a site in the SE corner of the study region with one of the larger volumes.

{|
| [[File:s3446_erf64_volume.png|thumb|400px|Simulation region for s3446 is in yellow. Also plotted are the extents of the USGS SF model, the USGS regional model, CCA-06, and CVM-S4.26.M01.]]
|}

=== Primary 3D model ===

Given the extensive low-velocity near-surface regions in the USGS SF CVM, we plan to use a minimum Vs of 400 m/s (and therefore a grid spacing of 80 m).

{|
| [[File:Sfcvm_h0_2.png|thumb|400px]]
|}

Initial slices with the USGS SF CVM are available here: [[UCVM_sfcvm_geomodelgrid]]. We found two sharply defined high-velocity patches visible on the surface slice, one in the East Bay near the mountains, and another near Gilroy. These are regions where the gabbro type goes to the surface, and so the SF CVM geological rules dictate that the high velocities go to the surface as well.

{|
| [[File:eastbay_high_vs_vertical_profile.png|thumb|400px]]
|}

These patches are not present in the Vs30 models - for instance, for the point (37.6827, -122.086) SF CVM gives a surface Vs of about 3500 m/s, but Wills (2015) has Vs30=710 and Thompson (2018) has Vs30=702.

=== Potential modification to gabbro regions ===

A candidate modification to the gabbro regions to reduce the near-surface velocities is to apply the approach used by Arben Pitarka and Rie Nakata, detailed below.

{| border="1"
! Component !! At surface !! At 7.75 km depth !! derivation
|-
! Vp
| 4.2 km/s || 5.7 km/s || Linear interpolation
|-
! Vs
| 2.44 km/s || 3.4 km/s || Vp/Vs relationship
|-
! Density
| 2.76 g/cm3 || 2.87 g/cm3 || Vp/Density relationship
|}

The Vs (km/s) values are derived from Vp (km/s) using the San Leandro Gabbro relationship:
<pre>Vs = 0.7858 - 1.2344*Vp + 0.7949*Vp^2 - 0.1238*Vp^3 + 0.0064*Vp^4</pre>

The density (g/cm3) values are derived from Vp (km/s) using the San Leandro Gabbro relationship:
<pre>density = 2.4372 + 0.0761*Vp</pre>

A sample plot is below.

{|
| [[File:Nakata_and_Pitarka_modification_slice.png|thumb|800px]]
|}

=== Background model ===

For Study 24.8, we decided to go with the [[Sierra Foothills 1D]] model, which extends the Sierra region of SFCVM.

There are several candidates to use as a background model for the regions outside of the 3D model region.

1D models
#1D Broadband Platform model - either Northern California, Central California, or the Southern Sierras.
#1D CVM-S4 background model
#Extend eastern edge of SFCVM model to fill the remaining volume
#1D CCA model (derived from averaging CCA-06), used in Study 17.3

3D models
#3D CANVAS long-period tomography model
#3D National Crustal model

Plots of these options are available below.

{|
! 1D Model !! BBP NorCal || BBP CenCal !! BBP SouthernSierras !! CVM-S4.26.M01 1D background !! CCA 1D
|-
! Plot
| [[File:nocal500.png|thumb|300px]]
| [[File:centralcal500.png|thumb|300px]]
| [[File:ssn2-500.png|thumb|300px]]
| [[File:cvms426_1dbackground.png|thumb|300px]]
| [[File:Cs_cca_ucvm_1d_all.png|thumb|300px]]
|-
|}

=== Cross-sections ===

==== Cross-sections, no smoothing, CVM-S4.26.M01 1D background ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06, CVM-S4.26.M01. This model was extracted on 2/28/24, and is one of the largest volumes needed for the study.

{|
! 0m !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:s3446_0m_nosmooth_vs.png|thumb|250px]]
| [[File:s3446_80m_nosmooth_vs.png|thumb|250px]]
| [[File:s3446_800m_nosmooth_vs.png|thumb|250px]]
| [[File:s3446_2000m_nosmooth_vs.png|thumb|250px]]
| [[File:s3446_4000m_nosmooth_vs.png|thumb|250px]]
| [[File:s3446_10000m_nosmooth_vs.png|thumb|250px]]
|}

Below are vertical cross-sections taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06, CVM-S4.26.M01. This model was extracted on 2/28/24, and is one of the largest volumes needed for the study.

{|
| [[File:s3446_cross_section_locations.png|thumb|600px]]
|}

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:s3446_x_2400_vs.png|thumb|400px]]
| [[File:s3446_x_4800_vs.png|thumb|400px]]
| [[File:s3446_x_7200_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:s3446_y_1400_vs.png|thumb|400px]]
| [[File:s3446_y_2800_vs.png|thumb|400px]]
|}

==== Cross-sections, smoothing, CVM-S4.26.M01 1D background ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated with smoothing, with the tiling SFCVM, CCA-06, CVM-S4.26.M01. This model was extracted on 2/28/24.

{|
! 0m !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:s3446_0m_smooth_vs.png|thumb|250px]]
| [[File:s3446_80m_smooth_vs.png|thumb|250px]]
| [[File:s3446_800m_smooth_vs.png|thumb|250px]]
| [[File:s3446_2000m_smooth_vs.png|thumb|250px]]
| [[File:s3446_4000m_smooth_vs.png|thumb|250px]]
| [[File:s3446_10000m_smooth_vs.png|thumb|250px]]
|}

Below are vertical cross-sections taken from a model for s3446 generated with smoothing, with the tiling SFCVM, CCA-06, CVM-S4.26.M01. This model was extracted on 2/28/24.

{|
| [[File:s3446_smoothed_cross_section_locations.png|thumb|600px]]
|}

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:s3446_x_2400_smoothed_vs.png|thumb|400px]]
| [[File:s3446_x_4800_smoothed_vs.png|thumb|400px]]
| [[File:s3446_x_7200_smoothed_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:s3446_y_1400_smoothed_vs.png|thumb|400px]]
| [[File:s3446_y_2800_smoothed_vs.png|thumb|400px]]
|}

==== Cross-sections, no smoothing, Southern Sierra BBP 1D background ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06, Southern Sierra BBP1D model. This model was extracted on 3/13/24.

{|
! 0m !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:s3446_0m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
| [[File:s3446_80m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
| [[File:s3446_800m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
| [[File:s3446_2000m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
| [[File:s3446_4000m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
| [[File:s3446_10000m_nosmooth_ss_bbp1d_vs.png|thumb|250px]]
|}

Below are horizontal cross-sections at various depths taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06, Southern Sierra BBP1D model. This model was extracted on 3/13/24.

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:s3446_x_2400_nosmooth_ss_bbp1d_vs.png|thumb|400px]]
| [[File:s3446_x_4800_nosmooth_ss_bbp1d_vs.png|thumb|400px]]
| [[File:s3446_x_7200_nosmooth_ss_bbp1d_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:s3446_y_1400_nosmooth_ss_bbp1d_vs.png|thumb|400px]]
| [[File:s3446_y_2800_nosmooth_ss_bbp1d_vs.png|thumb|400px]]
|}

==== Cross-sections, no smoothing, extended SFCVM Sierra 1D background, CCA + taper ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06 + taper, 1D representation of the Sierra foothills in SFCVM. This model was extracted on 4/2/24.

{|
! 0m !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:s3446_0m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_80m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_800m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_2000m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_4000m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_10000m_nosmooth_sfcvm_extended_vs.png|thumb|250px]]
|}

Below are vertical cross-sections.

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:s3446_x_2400_nosmooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_x_4800_nosmooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_x_7200_nosmooth_sfcvm_extended_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:s3446_y_1400_nosmooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_y_2800_nosmooth_sfcvm_extended_vs.png|thumb|400px]]
|}

==== Cross-sections, smoothing, extended SFCVM Sierra 1D background, CCA + taper ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated with smoothing, with the tiling SFCVM, CCA-06 + taper, 1D representation of the Sierra foothills in SFCVM. This model was extracted on 4/2/24.

{|
! 0m !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:s3446_0m_smooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_80m_smooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_800m_smooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_2000m_smooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_4000m_smooth_sfcvm_extended_vs.png|thumb|250px]]
| [[File:s3446_10000m_smooth_sfcvm_extended_vs.png|thumb|250px]]
|}

Below are vertical cross-sections.

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:s3446_x_2400_smooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_x_4800_smooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_x_7200_smooth_sfcvm_extended_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:s3446_y_1400_smooth_sfcvm_extended_vs.png|thumb|400px]]
| [[File:s3446_y_2800_smooth_sfcvm_extended_vs.png|thumb|400px]]
|}

==== Cross-sections, no smoothing, extended SFCVM Sierra 1D background with taper, CCA + taper ====

Below are horizontal cross-sections at various depths taken from a model for s3446 generated without smoothing, with the tiling SFCVM, CCA-06 + taper, 1D representation of the Sierra foothills in SFCVM + taper. This plot includes our typical practice of populating the surface point by querying the models at a depth of grid_spacing/4, or 20m. This model was extracted on 4/9/24.

{|
! Surface (20m) !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:4_9 s3446_0m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
| [[File:4_9_s3446_80m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
| [[File:4_9_s3446_800m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
| [[File:4_9_s3446_2000m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
| [[File:4_9_s3446_4000m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
| [[File:4_9_s3446_10000m_nosmooth_sfcvm_extended_taper_vs.png|thumb|250px]]
|}

{|
! Y=2400 !! Y=4800 !! Y=7200
|-
| [[File:4_9_s3446_x_2400_nosmooth_vs.png|thumb|400px]]
| [[File:4_9_s3446_x_4800_nosmooth_vs.png|thumb|400px]]
| [[File:4_9_s3446_x_7200_nosmooth_vs.png|thumb|400px]]
|}

{|
! X=1400 !! X=2800
|-
| [[File:4_9_s3446_y_1400_nosmooth_vs.png|thumb|400px]]
| [[File:4_9_s3446_y_2800_nosmooth_vs.png|thumb|400px]]
|}

=== Candidate Model (RC1) ===

Our candidate model is generated using (1) SFCVM with the gabbro modifications; (2) CCA-06 with the merged taper in the top 700m; (3) the [[NC1D]] model with the merged taper in the top 700m.

{|
! Surface (20m) !! 80m !! 800m !! 2000m !! 4000m !! 10000m
|-
| [[File:4_19 s3446_20m_smooth_RC1_vs.png|thumb|250px]]
| [[File:4_19_s3446_80m_smooth_RC1_vs.png|thumb|250px]]
| [[File:4_19_s3446_800m_smooth_RC1_vs.png|thumb|250px]]
| [[File:4_19_s3446_2000m_smooth_RC1_vs.png|thumb|250px]]
| [[File:4_19_s3446_4000m_smooth_RC1_vs.png|thumb|250px]]
| [[File:4_19_s3446_10000m_smooth_RC1_vs.png|thumb|250px]]
|}

=== Vp/Vs Ratio Adjustment ===

For this study, we are modifying our approach to preserving the Vp/Vs ratio when applying a Vs floor to avoid very large Vp/Vs ratios.

Our previous approach for applying the Vs floor is as follows:

#If Vs < Vs_floor (400 m/s):
##Calculate the Vp/Vs ratio
##Change Vs to the floor
##Calculate a new Vp using Vp = Vs_floor * Vp/Vs ratio
#Apply Vp and density floors

However, there are some sites with very high Vp/Vs ratios near the surface where Vs is low. Therefore, if this algorithm is applied, unexpectedly high Vp values may result.

Here is a vertical profile at site s3240 (Moffett Field). You can see the high surface Vp value:

{|
| [[File:s3240_vert_profile.png|thumb|400px]]
|}

Looking in more detail, here are the Vp and Vs values in the top 90m at s3240:

{| border="1"
! Depth (m) !! Vp !! Vs !! Vp/Vs ratio !! Adjusted Vs !! Adjusted Vp
|-
| 0 || 739 || 81 || 9.12 || 400 || 3649
|-
| 10 || 1009 || 82 || 12.30 || 400 || 4922
|-
| 20 || 1309 || 84 || 15.58 || 400 || 6233 
|-
| 30 || 1502 || 152 || 9.88 || 400 || 3953
|-
| 40 || 1590 || 285 || 5.58 || 400 || 3649
|-
| 50 || 1678 || 418 || 4.01
|-
| 60 || 1711 || 436 || 3.92
|-
| 70 || 1744 || 453 || 3.85
|-
| 80 || 1776 || 471 || 3.77
|-
| 90 || 1807 || 489 || 3.70
|}

Since we are using 80m grid spacing, and populating the surface point at a depth of (grid spacing)/4 = 20m, the values at 20m and 80m are being used. The very high Vp/Vs ratio at 20m means that a very high Vp value is used.

These high Vp/Vs ratios occur at a number of locations around San Francisco Bay, illustrated in the surface Vp plot below:

{|
| [[File:s3240_surface_vp.png|thumb|400px]]
|}

To solve this problem, we will modify the process for applying the Vs floor. We will use the Vp/Vs ratio at 80m depth instead of at the surface, and use a maximum ratio of 4. A similar process was used in the HighF project.

#If Vs < Vs_floor (400 m/s):
##If surface grid point:
###Calculate Vp/Vs ratio at 1 grid point depth (80m)
###If Vp/Vs ratio > 4:
####Lower Vp/Vs ratio to 4
##Else:
###Calculate Vp/Vs ratio at this grid point
##New Vs = Vs_floor
##New Vp = Vs * (potentially modified) Vp/Vs ratio.
#Apply Vp and density floors.

Below is a surface Vp plot with the ratio modification. Note that the areas of previous high Vp have been reduced.

{|
| [[File:s3240_modifiedratio_surface_vp.png|thumb|400px]]
|}

=== Candidate Model (RC2) ===

Candidate model RC2 is generated using the following procedure:
#Tiling with:
##USGS SFCVM v21.1
##CCA-06
##1D background model, derived as an extension of the Sierra section of the SFCVM model and described [[NC1D|here]].
#Surface points are populated using a depth of (grid spacing)/4, which is 20m for these meshes.
#An Ely-Jordan taper is applied to the top 700m across all models using Vs30 values from Thompson et al. (2020).
#Application of a Vs floor of 400 m/s, using the procedure outlined in [[CyberShake_Study_24.8#Vp/Vs Ratio Adjustment]].
#Smoothing is applied within 20km of a model boundary.

Vs plots:

{|
! Surface (20m) !! 80m !! 160m !! 320m !! 640m !! 2000m !! 4000m !! 10000m
|-
| [[File:8_5_s3446_20m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_80m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_160m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_320m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_640m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_2000m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_4000m_smooth_RC2_vs.png|thumb|250px]]
| [[File:8_5_s3446_10000m_smooth_RC2_vs.png|thumb|250px]]
|}

Surface Vp plot:

{|
| [[File:8_5_s3446_20m_smooth_RC2_vp.png|thumb|250px]]
|}

=== Taper impact ===

Below are velocity profiles for the 20 stress test sites, with and without the near-surface taper.

{|
! Site !! Without taper !! With taper (top 700m) !! Vs overlay
|-
! ALBY
| [[File:ALBY_notaper_profile.png|thumb|400px]]
| [[File:ALBY_taper_profile.png|thumb|400px]]
| [[File:ALBY_overlay_profile.png|thumb|300px]]
|-
! BLMT
| [[File:BLMT_notaper_profile.png|thumb|400px]]
| [[File:BLMT_taper_profile.png|thumb|400px]]
| [[File:BLMT_overlay_profile.png|thumb|300px]]
|-
! CFCS
| [[File:CFCS_notaper_profile.png|thumb|400px]]
| [[File:CFCS_taper_profile.png|thumb|400px]]
| [[File:CFCS_overlay_profile.png|thumb|300px]]
|-
! CSU1
| [[File:CSU1_notaper_profile.png|thumb|400px]]
| [[File:CSU1_taper_profile.png|thumb|400px]]
| [[File:CSU1_overlay_profile.png|thumb|300px]]
|-
! CSUEB
| [[File:CSUEB_notaper_profile.png|thumb|400px]]
| [[File:CSUEB_taper_profile.png|thumb|400px]]
| [[File:CSUEB_overlay_profile.png|thumb|300px]]
|-
! DALY
| [[File:DALY_notaper_profile.png|thumb|400px]]
| [[File:DALY_taper_profile.png|thumb|400px]]
| [[File:DALY_overlay_profile.png|thumb|300px]]
|-
! HAYW
| [[File:HAYW_notaper_profile.png|thumb|400px]]
| [[File:HAYW_taper_profile.png|thumb|400px]]
| [[File:HAYW_overlay_profile.png|thumb|300px]]
|-
! LICK
| [[File:LICK_notaper_profile.png|thumb|400px]]
| [[File:LICK_taper_profile.png|thumb|400px]]
| [[File:LICK_overlay_profile.png|thumb|300px]]
|-
! LVMR
| [[File:LVMR_notaper_profile.png|thumb|400px]]
| [[File:LVMR_taper_profile.png|thumb|400px]]
| [[File:LVMR_overlay_profile.png|thumb|300px]]
|-
! MSRA
| [[File:MSRA_notaper_profile.png|thumb|400px]]
| [[File:MSRA_taper_profile.png|thumb|400px]]
| [[File:MSRA_overlay_profile.png|thumb|300px]]
|-
! NAPA
| [[File:NAPA_notaper_profile.png|thumb|400px]]
| [[File:NAPA_taper_profile.png|thumb|400px]]
| [[File:NAPA_overlay_profile.png|thumb|300px]]
|-
! PTRY
| [[File:PTRY_notaper_profile.png|thumb|400px]]
| [[File:PTRY_taper_profile.png|thumb|400px]]
| [[File:PTRY_overlay_profile.png|thumb|300px]]
|-
! s3171
| [[File:s3171_notaper_profile.png|thumb|400px]]
| [[File:s3171_taper_profile.png|thumb|400px]]
| [[File:s3171_overlay_profile.png|thumb|300px]]
|-
! s3240
| [[File:s3240_notaper_profile.png|thumb|400px]]
| [[File:s3240_taper_profile.png|thumb|400px]]
| [[File:s3240_overlay_profile.png|thumb|300px]]
|-
! s3446
| [[File:s3446_notaper_profile.png|thumb|400px]]
| [[File:s3446_taper_profile.png|thumb|400px]]
| [[File:s3446_overlay_profile.png|thumb|300px]]
|-
! SFRH
| [[File:SFRH_notaper_profile.png|thumb|400px]]
| [[File:SFRH_taper_profile.png|thumb|400px]]
| [[File:SFRH_overlay_profile.png|thumb|300px]]
|-
! SSFO
| [[File:SSFO_notaper_profile.png|thumb|400px]]
| [[File:SSFO_taper_profile.png|thumb|400px]]
| [[File:SSFO_overlay_profile.png|thumb|300px]]
|-
! SSOL
| [[File:SSOL_notaper_profile.png|thumb|400px]]
| [[File:SSOL_taper_profile.png|thumb|400px]]
| [[File:SSOL_overlay_profile.png|thumb|300px]]
|-
! SRSA
| [[File:SRSA_notaper_profile.png|thumb|400px]]
| [[File:SRSA_taper_profile.png|thumb|400px]]
| [[File:SRSA_overlay_profile.png|thumb|300px]]
|-
! SJO
| [[File:SJO_notaper_profile.png|thumb|400px]]
| [[File:SJO_taper_profile.png|thumb|400px]]
| [[File:SJO_overlay_profile.png|thumb|300px]]
|-
|}

== Strain Green Tensors ==

We will use the HIP implementation of AWP-ODC-SGT, with the following parameters:
*Grid spacing: 80 m
*DT: 0.004 sec
*NT: 50000 timesteps by default, increased to 75000 for sites with any site-to-hypocenter distance greater than 450 km.
*Minimum Vs: 400 m/s

SGTs will be saved with a time decimation of 10, so every 0.04 sec.

== Vertical Component ==

We will include vertical (Z) component seismograms in this study. To support this, we will produce Z-component SGTs and include Z-component synthesis in the post-processing and broadband stages.

Verification that the Z component codes are working correctly is documented at [[Vertical component verification]].

== Rupture Generator ==

We will use the same version of the rupture generator that we used for Study 22.12, v5.5.2.

To match the SGT timestep, SRFs will be generated with dt=0.04s, deterministic seismograms will be output with dt=0.04s, and broadband seismograms will use dt=0.01s.

== High-frequency codes ==

We will use the Graves & Pitarka high-frequency codes from the BBP v22.4.

However, since we are using a denser mesh (80m) and a lower minimum Vs (400 m/s), we will not apply site correction to the low-frequency seismograms before combining. Rob states, You may recall that there is a klugy process we have used to estimate the Vref value based on the Vsmin and grid spacing of the model. But, it has only been applied for the case of h=100 m and Vsmin=500 m/s. What I found here is that estimating Vref using the 80m & 400m/s model is that Vref is almost always less than Vs30 (i.e., Vsite). This means that when the site adjustment is applied, the motions are deamplified. This is why we see such a poor fit for the 3D case when using the estimated Vref values. My conclusion at this point is that if we run the 3D calculation with 80 m grid spacing and Vsmin of 400 m/s (or lower), then we probably do not need to apply any site adjustments.

== Validation ==

We performed [[Loma Prieta Validation | validation runs for the Loma Prieta BBP event]].

== Hazard Curve Tests ==

We are calculating test hazard curves for the following sites:

{|
| [[File:Study_24.6_test_sites_map.png|thumb|600px]]
|}

=== Results using velocity model RC1 ===

==== Low-frequency curves ====

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec !! Vertical profile
|-
! s3446
| [[File:s3446_10676_2sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_3sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_5sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_10sec_RotD50.png|thumb|300px]]
| [[File:s3446_vert_profile.png|thumb|250px]]
|-
|
| [[File:s3446_10676_2sec_RotD50_log.png|thumb|300px]]
| [[File:s3446_10676_3sec_RotD50_log.png|thumb|300px]]
| [[File:s3446_10676_5sec_RotD50_log.png|thumb|300px]]
| [[File:s3446_10676_10sec_RotD50_log.png|thumb|300px]]
|-
! s3240
| [[File:s3240_10677_2sec_RotD50.png|thumb|300px]]
| [[File:s3240_10677_3sec_RotD50.png|thumb|300px]]
| [[File:s3240_10677_5sec_RotD50.png|thumb|300px]]
| [[File:s3240_10677_10sec_RotD50.png|thumb|300px]]
| [[File:s3240_vert_profile.png|thumb|250px]]
|-
|
| [[File:s3240_10677_2sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10677_3sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10677_5sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10677_10sec_RotD50_log.png|thumb|300px]]
|-
! ALBY
| [[File:ALBY_10678_2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10678_3sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10678_5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10678_10sec_RotD50.png|thumb|300px]]
| [[File:ALBY_vert_profile.png|thumb|250px]]
|-
|
| [[File:ALBY_10678_2sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10678_3sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10678_5sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10678_10sec_RotD50_log.png|thumb|300px]]
|-
! SJO
| [[File:SJO_10683_2sec_RotD50.png|thumb|300px]]
| [[File:SJO_10683_3sec_RotD50.png|thumb|300px]]
| [[File:SJO_10683_5sec_RotD50.png|thumb|300px]]
| [[File:SJO_10683_10sec_RotD50.png|thumb|300px]]
| [[File:SJO_vert_profile.png|thumb|250px]]
|-
|
| [[File:SJO_10683_2sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10683_3sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10683_5sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10683_10sec_RotD50_log.png|thumb|300px]]
|-
! CFCS
| [[File:CFCS_10684_2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10684_3sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10684_5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10684_10sec_RotD50.png|thumb|300px]]
| [[File:CFCS_vert_profile.png|thumb|250px]]
|-
|
| [[File:CFCS_10684_2sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10684_3sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10684_5sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10684_10sec_RotD50_log.png|thumb|300px]]
|-
! s3171
| [[File:s3171_10685_2sec_RotD50.png|thumb|300px]]
| [[File:s3171_10685_3sec_RotD50.png|thumb|300px]]
| [[File:s3171_10685_5sec_RotD50.png|thumb|300px]]
| [[File:s3171_10685_10sec_RotD50.png|thumb|300px]]
| [[File:s3171_vert_profile.png|thumb|250px]]
|-
|
| [[File:s3171_10685_2sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10685_3sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10685_5sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10685_10sec_RotD50_log.png|thumb|300px]]
|-
! CSUEB
| [[File:CSUEB_10687_2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10687_3sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10687_5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10687_10sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_vert_profile.png|thumb|250px]]
|-
|
| [[File:CSUEB_10687_2sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10687_3sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10687_5sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10687_10sec_RotD50_log.png|thumb|300px]]
|-
! CSU1
| [[File:CSU1_10686_2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10686_3sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10686_5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10686_10sec_RotD50.png|thumb|300px]]
| [[File:CSU1_vert_profile.png|thumb|250px]]
|-
|
| [[File:CSU1_10686_2sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10686_3sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10686_5sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10686_10sec_RotD50_log.png|thumb|300px]]
|-
! SFRH
| [[File:SFRH_10681_2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10681_3sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10681_5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10681_10sec_RotD50.png|thumb|300px]]
| [[File:SFRH_vert_profile.png|thumb|250px]]
|-
|
| [[File:SFRH_10681_2sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10681_3sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10681_5sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10681_10sec_RotD50_log.png|thumb|300px]]
|-
! LVMR
| [[File:LVMR_10682_2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10682_3sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10682_5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10682_10sec_RotD50.png|thumb|300px]]
| [[File:LVMR_vert_profile.png|thumb|250px]]
|-
|
| [[File:LVMR_10682_2sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10682_3sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10682_5sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10682_10sec_RotD50_log.png|thumb|300px]]
|-
! HAYW
| [[File:HAYW_10679_2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10679_3sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10679_5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10679_10sec_RotD50.png|thumb|300px]]
| [[File:HAYW_vert_profile.png|thumb|250px]]
|-
|
| [[File:HAYW_10679_2sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10679_3sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10679_5sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10679_10sec_RotD50_log.png|thumb|300px]]
|}

==== High-frequency curves ====

{|
! Site !! 1 sec !! 0.5 sec !! 0.2 sec !! 0.1 sec !! Vertical profile
|-
! s3446
| [[File:s3446_10676_1sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_0.5sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_0.2sec_RotD50.png|thumb|300px]]
| [[File:s3446_10676_0.1sec_RotD50.png|thumb|300px]]
| [[File:s3446_vert_profile.png|thumb|250px]]
|-
! s3240
| [[File:s3240_10689_1sec_RotD50.png|thumb|300px]]
| [[File:s3240_10689_0.5sec_RotD50.png|thumb|300px]]
| [[File:s3240_10689_0.2sec_RotD50.png|thumb|300px]]
| [[File:s3240_10689_0.1sec_RotD50.png|thumb|300px]]
| [[File:s3240_vert_profile.png|thumb|250px]]
|-
! ALBY
| [[File:ALBY_10694_1sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10694_0.5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10694_0.2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10694_0.1sec_RotD50.png|thumb|300px]]
| [[File:ALBY_vert_profile.png|thumb|250px]]
|-
! SJO
| [[File:SJO_10695_1sec_RotD50.png|thumb|300px]]
| [[File:SJO_10695_0.5sec_RotD50.png|thumb|300px]]
| [[File:SJO_10695_0.2sec_RotD50.png|thumb|300px]]
| [[File:SJO_10695_0.1sec_RotD50.png|thumb|300px]]
| [[File:SJO_vert_profile.png|thumb|250px]]
|-
! CFCS
| [[File:CFCS_10693_1sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10693_0.5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10693_0.2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10693_0.1sec_RotD50.png|thumb|300px]]
| [[File:CFCS_vert_profile.png|thumb|250px]]
|-
! s3171
| [[File:s3171_10688_1sec_RotD50.png|thumb|300px]]
| [[File:s3171_10688_0.5sec_RotD50.png|thumb|300px]]
| [[File:s3171_10688_0.2sec_RotD50.png|thumb|300px]]
| [[File:s3171_10688_0.1sec_RotD50.png|thumb|300px]]
| [[File:s3171_vert_profile.png|thumb|250px]]
|-
! CSUEB
| [[File:CSUEB_10691_1sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10691_0.5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10691_0.2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10691_0.1sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_vert_profile.png|thumb|250px]]
|-
! CSU1
| [[File:CSU1_10692_1sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10692_0.5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10692_0.2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10692_0.1sec_RotD50.png|thumb|300px]]
| [[File:CSU1_vert_profile.png|thumb|250px]]
|-
! SFRH
| [[File:SFRH_10690_1sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10690_0.5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10690_0.2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10690_0.1sec_RotD50.png|thumb|300px]]
| [[File:SFRH_vert_profile.png|thumb|250px]]
|-
! LVMR
| [[File:LVMR_10696_1sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10696_0.5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10696_0.2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10696_0.1sec_RotD50.png|thumb|300px]]
| [[File:LVMR_vert_profile.png|thumb|250px]]
|-
! HAYW
| [[File:HAYW_10697_1sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10697_0.5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10697_0.2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10697_0.1sec_RotD50.png|thumb|300px]]
| [[File:HAYW_vert_profile.png|thumb|250px]]
|}

=== Results using velocity model RC2 ===

==== Low-frequency curves ====

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec !! Vertical profile
|-
! s3240
| [[File:s3240_10708_2sec_RotD50.png|thumb|300px]]
| [[File:s3240_10708_3sec_RotD50.png|thumb|300px]]
| [[File:s3240_10708_5sec_RotD50.png|thumb|300px]]
| [[File:s3240_10708_10sec_RotD50.png|thumb|300px]]
| [[File:s3240_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:s3240_10708_2sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10708_3sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10708_5sec_RotD50_log.png|thumb|300px]]
| [[File:s3240_10708_10sec_RotD50_log.png|thumb|300px]]
|-
! ALBY
| [[File:ALBY_10709_2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10709_3sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10709_5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10709_10sec_RotD50.png|thumb|300px]]
| [[File:ALBY_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:ALBY_10709_2sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10709_3sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10709_5sec_RotD50_log.png|thumb|300px]]
| [[File:ALBY_10709_10sec_RotD50_log.png|thumb|300px]]
|-
! SJO
| [[File:SJO_10710_2sec_RotD50.png|thumb|300px]]
| [[File:SJO_10710_3sec_RotD50.png|thumb|300px]]
| [[File:SJO_10710_5sec_RotD50.png|thumb|300px]]
| [[File:SJO_10710_10sec_RotD50.png|thumb|300px]]
| [[File:SJO_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:SJO_10710_2sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10710_3sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10710_5sec_RotD50_log.png|thumb|300px]]
| [[File:SJO_10710_10sec_RotD50_log.png|thumb|300px]]
|-
! CFCS
| [[File:CFCS_10711_2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10711_3sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10711_5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10711_10sec_RotD50.png|thumb|300px]]
| [[File:CFCS_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:CFCS_10711_2sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10711_3sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10711_5sec_RotD50_log.png|thumb|300px]]
| [[File:CFCS_10711_10sec_RotD50_log.png|thumb|300px]]
|-
! s3171
| [[File:s3171_10712_2sec_RotD50.png|thumb|300px]]
| [[File:s3171_10712_3sec_RotD50.png|thumb|300px]]
| [[File:s3171_10712_5sec_RotD50.png|thumb|300px]]
| [[File:s3171_10712_10sec_RotD50.png|thumb|300px]]
| [[File:s3171_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:s3171_10712_2sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10712_3sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10712_5sec_RotD50_log.png|thumb|300px]]
| [[File:s3171_10712_10sec_RotD50_log.png|thumb|300px]]
|-
! CSUEB
| [[File:CSUEB_10713_2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10713_3sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10713_5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10713_10sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:CSUEB_10713_2sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10713_3sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10713_5sec_RotD50_log.png|thumb|300px]]
| [[File:CSUEB_10713_10sec_RotD50_log.png|thumb|300px]]
|-
! CSU1
| [[File:CSU1_10714_2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10714_3sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10714_5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10714_10sec_RotD50.png|thumb|300px]]
| [[File:CSU1_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:CSU1_10714_2sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10714_3sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10714_5sec_RotD50_log.png|thumb|300px]]
| [[File:CSU1_10714_10sec_RotD50_log.png|thumb|300px]]
|-
! SFRH
| [[File:SFRH_10715_2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10715_3sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10715_5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10715_10sec_RotD50.png|thumb|300px]]
| [[File:SFRH_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:SFRH_10715_2sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10715_3sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10715_5sec_RotD50_log.png|thumb|300px]]
| [[File:SFRH_10715_10sec_RotD50_log.png|thumb|300px]]
|-
! LVMR
| [[File:LVMR_10715_2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10715_3sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10715_5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10715_10sec_RotD50.png|thumb|300px]]
| [[File:LVMR_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:LVMR_10715_2sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10715_3sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10715_5sec_RotD50_log.png|thumb|300px]]
| [[File:LVMR_10715_10sec_RotD50_log.png|thumb|300px]]
|-
! HAYW
| [[File:HAYW_10717_2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10717_3sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10717_5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10717_10sec_RotD50.png|thumb|300px]]
| [[File:HAYW_RC2_vert_profile.png|thumb|250px]]
|-
|
| [[File:HAYW_10717_2sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10717_3sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10717_5sec_RotD50_log.png|thumb|300px]]
| [[File:HAYW_10717_10sec_RotD50_log.png|thumb|300px]]
|}

==== Comparisons with Study 18.8 ====

Study 18.8 curves are in red, and new curves are in black.

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec !! Vertical profile
|-
! s3240
| [[File:s3240_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3240_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3240_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3240_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:s3240_RC2_vert_profile.png|thumb|250px]]
|-
! ALBY
| [[File:ALBY_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:ALBY_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:ALBY_RC2_vert_profile.png|thumb|250px]]
|-
! SJO
| [[File:SJO_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SJO_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SJO_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SJO_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:SJO_RC2_vert_profile.png|thumb|250px]]
|-
! CFCS
| [[File:CFCS_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CFCS_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:CFCS_RC2_vert_profile.png|thumb|250px]]
|-
! s3171
| [[File:s3171_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3171_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3171_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3171_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:s3171_RC2_vert_profile.png|thumb|250px]]
|-
! CSUEB
| [[File:CSUEB_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_RC2_vert_profile.png|thumb|250px]]
|-
! CSU1
| [[File:CSU1_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CSU1_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:CSU1_RC2_vert_profile.png|thumb|250px]]
|-
! SFRH
| [[File:SFRH_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SFRH_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:SFRH_RC2_vert_profile.png|thumb|250px]]
|-
! LVMR
| [[File:LVMR_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:LVMR_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:LVMR_RC2_vert_profile.png|thumb|250px]]
|-
! HAYW
| [[File:HAYW_Aug9_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_Aug9_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:HAYW_Aug9_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_Aug9_248_v_188_10sec_RotD50.png|thumb|300px]]
| [[File:HAYW_RC2_vert_profile.png|thumb|250px]]
|-
|}

==== High-frequency curves ====

{|
! Site !! 1 sec !! 0.5 sec !! 0.2 sec !! 0.1 sec !! Vertical profile
|-
! s3240
| [[File:s3240_10724_1sec_RotD50.png|thumb|300px]]
| [[File:s3240_10724_0.5sec_RotD50.png|thumb|300px]]
| [[File:s3240_10724_0.2sec_RotD50.png|thumb|300px]]
| [[File:s3240_10724_0.1sec_RotD50.png|thumb|300px]]
| [[File:s3240_vert_profile.png|thumb|250px]]
|-
! ALBY
| [[File:ALBY_10725_1sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10725_0.5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10725_0.2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_10725_0.1sec_RotD50.png|thumb|300px]]
| [[File:ALBY_vert_profile.png|thumb|250px]]
|-
! SJO
| [[File:SJO_10723_1sec_RotD50.png|thumb|300px]]
| [[File:SJO_10723_0.5sec_RotD50.png|thumb|300px]]
| [[File:SJO_10723_0.2sec_RotD50.png|thumb|300px]]
| [[File:SJO_10723_0.1sec_RotD50.png|thumb|300px]]
| [[File:SJO_vert_profile.png|thumb|250px]]
|-
! CFCS
| [[File:CFCS_10718_1sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10718_0.5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10718_0.2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_10718_0.1sec_RotD50.png|thumb|300px]]
| [[File:CFCS_vert_profile.png|thumb|250px]]
|-
! s3171
| [[File:s3171_10719_1sec_RotD50.png|thumb|300px]]
| [[File:s3171_10719_0.5sec_RotD50.png|thumb|300px]]
| [[File:s3171_10719_0.2sec_RotD50.png|thumb|300px]]
| [[File:s3171_10719_0.1sec_RotD50.png|thumb|300px]]
| [[File:s3171_vert_profile.png|thumb|250px]]
|-
! CSUEB
| [[File:CSUEB_10720_1sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10720_0.5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10720_0.2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_10720_0.1sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_vert_profile.png|thumb|250px]]
|-
! CSU1
| [[File:CSU1_10721_1sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10721_0.5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10721_0.2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_10721_0.1sec_RotD50.png|thumb|300px]]
| [[File:CSU1_vert_profile.png|thumb|250px]]
|-
! SFRH
| [[File:SFRH_10722_1sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10722_0.5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10722_0.2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_10722_0.1sec_RotD50.png|thumb|300px]]
| [[File:SFRH_vert_profile.png|thumb|250px]]
|-
! LVMR
| [[File:LVMR_10726_1sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10726_0.5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10726_0.2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_10726_0.1sec_RotD50.png|thumb|300px]]
| [[File:LVMR_vert_profile.png|thumb|250px]]
|-
! HAYW
| [[File:HAYW_10727_1sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10727_0.5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10727_0.2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_10727_0.1sec_RotD50.png|thumb|300px]]
| [[File:HAYW_vert_profile.png|thumb|250px]]
|}

== Updates and Enhancements ==

*Used smaller study region than in Study 18.8.
*Removed southern San Andreas events, and created a new ERF.

== Output Data Products ==

=== File-based data products ===

We plan to produce the following data products, which will be stored at CARC:

==== Deterministic ====

*Seismograms: 3-component seismograms, 10000 timesteps (400 sec, dt=0.04s) each.
*PSA: We are removing geometric mean PSA calculations from this study.
*RotD: PGV, and RotD50, RotD100, and the RotD100 azimuth at 27 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1)
*Vertical response spectra at 27 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1).
*Durations: for X and Y components, energy integral, Arias intensity, cumulative absolute velocity (CAV), and for both velocity and acceleration, 5-75%, 5-95%, and 20-80%. Also, period-dependent acceleration 5-75%, 5-95%, and 20-80% for 27 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1).

==== Broadband ====

*Seismograms: 3-component seismograms, 40000 timesteps (400 sec, dt=0.01s) each.
*PSA: We are removing geometric mean PSA calculations from this study.
*RotD: PGA, PGV, and RotD50, RotD100, and the the RotD100 azimuth at 68 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1, 0.85, 0.75, 0.65, 0.6, 0.55, 0.5, 0.45, 0.4, 0.35, 0.3, 0.28, 0.26, 0.24, 0.22, 0.2, 0.17, 0.15, 0.13, 0.12, 0.11, 0.1, 0.085, 0.075, 0.065, 0.06, 0.055, 0.05, 0.045, 0.04, 0.035, 0.032, 0.029, 0.025, 0.022, 0.02, 0.017, 0.015, 0.013, 0.012, 0.011, 0.01)
*Vertical response spectra at 68 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1).
*Durations: for X and Y components, energy integral, Arias intensity, cumulative absolute velocity (CAV), and for both velocity and acceleration, 5-75%, 5-95%, and 20-80%. Also, period-dependent acceleration 5-75%, 5-95%, and 20-80% for 68 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1, 0.85, 0.75, 0.65, 0.6, 0.55, 0.5, 0.45, 0.4, 0.35, 0.3, 0.28, 0.26, 0.24, 0.22, 0.2, 0.17, 0.15, 0.13, 0.12, 0.11, 0.1, 0.085, 0.075, 0.065, 0.06, 0.055, 0.05, 0.045, 0.04, 0.035, 0.032, 0.029, 0.025, 0.022, 0.02, 0.017, 0.015, 0.013, 0.012, 0.011, 0.01)

=== Database data products ===

We plan to store the following data products in the database on moment-carc:

==== Deterministic ====

*RotD50 for 6 periods (10, 7.5, 5, 4, 3, 2). Note that we are NOT storing RotD100.
*Duration: acceleration 5-75% and 5-95% for both X and Y

==== Broadband ====

*RotD50 for PGA, PGV, and 19 periods (10, 7.5, 5, 4, 3, 2, 1, 0.75, 0.5, 0.4, 0.3, 0.2, 0.1, 0.075, 0.05, 0.04, 0.03, 0.02, 0.01). Note that we are NOT storing RotD100.

=== Hazard products ===

For each site, we will produce hazard curves from the deterministic results at 10, 5, 3, and 2 seconds, and from the broadband results at 10, 5, 3, 2, 1, 0.5, 0.2, and 0.1 seconds.

When the study is complete, we will produce maps from the deterministic results at 10, 5, 3, and 2 seconds, and from the broadband results at 10, 5, 3, 2, 1, 0.5, 0.2, and 0.1 seconds.

=== Data products after the study ===

After the study completes, we plan to compute Fourier spectra for all 3 components:

*For deterministic, at 27 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1).
*For broadband at 68 periods (20, 17, 15, 13, 12, 10, 8.5, 7.5, 6.5, 6, 5.5, 5, 4.4, 4, 3.5, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.7, 1.5, 1.3, 1.2, 1.1, 1, 0.85, 0.75, 0.65, 0.6, 0.55, 0.5, 0.45, 0.4, 0.35, 0.3, 0.28, 0.26, 0.24, 0.22, 0.2, 0.17, 0.15, 0.13, 0.12, 0.11, 0.1, 0.085, 0.075, 0.065, 0.06, 0.055, 0.05, 0.045, 0.04, 0.035, 0.032, 0.029, 0.025, 0.022, 0.02, 0.017, 0.015, 0.013, 0.012, 0.011, 0.01)

== Computational and Data Estimates ==

=== Computational Estimates ===

We based these estimates on the test sites.

{| class="wikitable"
|+SGT calculation
! !! UCVM runtime !! UCVM nodes !! SGT runtime (3 components) !! SGT nodes !! Other SGT workflow jobs !! SGT Total
|-
! Average of 11 test sites
| 761 sec || 96 || 7134 sec || 100 || 7200 node-sec || 220 node-hrs
|}

220 node-hrs/site x 315 sites + 10% overrun = 76,230 node-hours for SGT workflows on Frontier.

{| class="wikitable"
|+PP calculation
! !! DirectSynth runtime !! DirectSynth nodes !! Additional runtime for period-dependent calculation !! PP Total
|-
! 75th percentile of 10 test sites
| 13914 sec || 60 || 61938 core-sec || 232.2 node-hrs
|}

{| class="wikitable"
|+BB calculation
! !! BB runtime !! BB nodes !! Additional runtime for period-dependent calculation !! BB Total
|-
! 75th percentile of 10 test sites
| 8019 sec || 40 || 61938 core-sec || 89.4 node-hrs
|}

(232.2+89.7) node-hrs/site x 315 sites + 10% overrun = 111,500 node-hours for PP and BB calculations on Frontera.

=== Data Estimates ===

We use the 75th percentile estimate of 206,500 rupture variations.

We are generating 3-component SGTs and 3-component seismograms, with 10k timesteps (400 sec) for LF and 40k timesteps (400 sec) for BB.

{| class="wikitable"
|+Data estimates
! !! Velocity mesh !! SGTs size !! Temp data !! LF Output data !! BB Output data !! Total output data
|-
! Per site, derived from 10 site average (GB)
| 359 || 1131 || 1490 || 23.7 || 93.6 || 117.3
|-
! Total for 335 sites (TB)
| 110 || 348 || 458 || 7.3 || 28.8 || 36.1
|}

==== CARC ====

We estimate 117.3 GB/site x 315 sites = 36.1 TB in output data, which will be transferred back to CARC. We currently have 29 TB free.

==== shock-carc ====

We estimate (3 MB SGT + 32 MB PP + 219 MB BB logs + 3 MB output products) x 315 sites = 79 GB in workflow log space on /home/shock. This drive has approximately 1.2 TB free.

==== moment-carc database ====

The PeakAmplitudes table uses approximately 183 bytes for data + 179 bytes for index = 363 bytes per entry.

362 bytes/entry * 35 entries/event (10 det + 25 stoch) * 206,500 events/site * 315 sites = 768 GB. The drive on moment-carc with the mysql database has 6.6 TB free.

== Lessons Learned ==
*The SRFs used in this study weren't quite what was intended; they had subfault relocation on and used a different risetime. Consider running an SRF check before starting the study. More details about the subfault perturbation issue are given on the [[CyberShake_Study_22.12#Subfault_Perturbation | Study 22.12 wiki page]].
*The runtime requested for post-processing jobs was higher than what was needed, increasing queue times for awhile.
*The scottcal account went over quota on /home at Frontera, an issue for writing rvGAHP files.
*Due to the lack of support for outgoing connections, there was not an easy way to bundle jobs on Frontier and we ran the SGT jobs individually.
*Due to an issue with migrating the Study 22.12 changes back to the main Github branch, FP was being overwritten as 0.5 instead of using the 1.0 value from the IN3D file.

== Stress Test ==

For the stress test, we will run the first 20 sites and check for scientific and technical issues.

Usage before the stress test:
*On Frontier, 587,856 of 700,000 node-hours for project GEO156. callag has used 22,166 node-hours.
*On Frontera, 316,715 of 600,000 node-hours for project EAR20006. scottcal has used 11,274 node-hours.

The stress test began on 8/27/24 at 11:25:23 PDT.

To help us finish the stress test before the SCEC AM, TACC granted us a Frontera reservation for 200 nodes for 8 days, beginning on 8/28/24 at 8 am PDT. We didn't realized we needed to specify the --reservation tag, so we began utilizing it around 9 am PDT.

We gave the reservation back in the morning of 8/30. After the stress test, callag had used 32,660 node-hours on Frontier and scottcal used 18,493 node-hours on Frontera.

Stress test computational cost:

*SGTs: 10494/20 sites = 524.7 node-hours per site, about 2.4x what we estimated. This is mostly due to having used meshes with a -55 degree angle, resulting in larger meshes requiring more computation time.
*PP and BB: 370.0 node-hours per site, about 15% more than we estimated.

=== Changes from stress test ===

Based on the stress test, we made the following changes:
*Reduced ramp-up time for DirectSynth worker processes.
*Fixed issue with PGV writing to files in the BB codes.
*Changed mesh angle from -55 to -36 degrees.
*Changed smoothing zone from 10 km on either side of the boundary to 20 km.
*Fixed issue with vertical response and period duration files not automatically transferred.
*Discovered issue with accessing moment-carc through the USC VPN - confirmed that neither Xiaofeng nor Kevin can access it.

=== Stress test results ===

Below are hazard curves for the 20 test sites in the stress test.

{|
| [[File:study_24_8_stress_test_sites.png|thumb|600px]]
|}

A KML file with the stress test sites is available [[Media:Study_24_8_stress_test_sites.kml|here]].

==== Low-frequency ====

These curves (in black) include comparisons with Study 18.8 (in red)

{|
! Site !! 2 sec !! 3 sec !! 5 sec !! 10 sec
|-
! s3240
| [[File:s3240_r10730_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3240_r10730_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3240_r10730_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3240_r10730_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! ALBY
| [[File:ALBY_r10731_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:ALBY_r10731_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:ALBY_r10731_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:ALBY_r10731_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SJO
| [[File:SJO_r10732_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! CFCS
| [[File:CFCS_r10733_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! s3171
| [[File:s3171_r10734_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3171_r10734_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3171_r10734_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3171_r10734_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! CSUEB
| [[File:CSUEB_r10735_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_r10735_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_r10735_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CSUEB_r10735_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! CSU1
| [[File:CSU1_r10736_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CSU1_r10736_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CSU1_r10736_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CSU1_r10736_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SFRH
| [[File:SFRH_r10737_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SFRH_r10737_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SFRH_r10737_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SFRH_r10737_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! LVMR
| [[File:LVMR_r10738_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:LVMR_r10738_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:LVMR_r10738_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:LVMR_r10738_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! HAYW
| [[File:HAYW_r10739_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:HAYW_r10739_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:HAYW_r10739_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:HAYW_r10739_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! s3446
| [[File:s3446_r10740_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! NAPA
| [[File:NAPA_r10741_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:NAPA_r10741_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:NAPA_r10741_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:NAPA_r10741_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SRSA
| [[File:SRSA_r10742_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SRSA_r10742_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SRSA_r10742_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SRSA_r10742_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! MSRA
| [[File:MSRA_r10743_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:MSRA_r10743_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:MSRA_r10743_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:MSRA_r10743_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! PTRY
| [[File:PTRY_r10744_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:PTRY_r10744_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:PTRY_r10744_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:PTRY_r10744_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! DALY
| [[File:DALY_r10745_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:DALY_r10745_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:DALY_r10745_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:DALY_r10745_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SSOL
| [[File:SSOL_r10746_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SSOL_r10746_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SSOL_r10746_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SSOL_r10746_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! LICK
| [[File:LICK_r10747_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SSFO
| [[File:SSFO_r10748_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SSFO_r10748_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SSFO_r10748_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SSFO_r10748_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! BLMT
| [[File:BLMT_r10749_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
|}

==== Sites with notable differences ====

We identified 3 sites with notable differences between Study 24.8 and Study 18.8:
*LVMR is higher at 10 sec
*CFCS is higher 2, 3, 5 sec
*s3171 is lower at 3, 5, 10 sec

We believe the difference in LVMR is due to the expanded basin added in SFCVM v21.1, and s3171 can be explained by the change in profile as well:

{|
! Site !! Profile, SFCVM v21.1 !! Profile, Cencal model used in Study 18.8
|-
! LVMR
| [[File:LVMR_RC2_vert_profile.png|thumb|250px]]
| [[File:LVMR_cencal_vert_profile.png|thumb|250px]]
|-
! s3171
| [[File:s3171_RC2_vert_profile.png|thumb|250px]]
| [[File:s3171_cencal_vert_profile.png|thumb|250px]]
|}

A scatterplot comparing the average 2 sec RotD50 value for each rupture shows that the Study 24.8 results are consistently higher than the 18.8 results for CFCS:

{|
| [[File:CFCS_scatterplot.png|thumb|400px]]
|}

We extracted vertical slices for the top from Cencal (floor = 500 m/s) and the Study 24.8 model (taper, floor = 400 m/s) for the top 5000 m along an east-west line running through CFCS.

{|
! Vertical slice, Study 24.8 !! Vertical slice, Cencal
|-
| [[File:CFCS_RC2_vert_slice.png|thumb|400px]]
| [[File:CFCS_cencal_vert_slice.png|thumb|400px]]
|}

==== Corrected Study 18.8 comparisons ====

In an attempt to replicate the Study 18.8 results, we discovered that the Study 18.8 velocity models were tiled in a different order than for Study 24.8: CCA-06, then CenCal, then CVM-S4.26.M01, as described [[CyberShake_Study_18.8#Configuration_for_this_study | here]]. Several of the stress test sites fall within the 20 km smoothing zone surrounding the Study 18.8 CCA-06/Cencal interface (interface in blue, 20km zone in white):

{|
| [[File:Study_18_8_20km_smoothing_region_stress_test_sites.png|thumb|400px]]
|}

We compared the velocity profiles of Study 24.8 and the correct Study 18.8 configuration for the 5 stress test sites. For CFCS, this explains the sharp increase in hazard. The Study 18.8 profile is in blue, and the Study 24.8 profile is in orange.

{|
! Site !! Vs overlay, top 700m !! 2 sec curve !! 3 sec curve !! 5 sec curve !! 10 sec curve
|-
! CFCS
| [[File:CFCS_248_188_overlay.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:CFCS_r10733_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! SJO
| [[File:SJO_248_188_overlay.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:SJO_r10732_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! s3446
| [[File:s3446_248_188_overlay.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:s3446_r10740_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! BLMT
| [[File:BLMT_248_188_overlay.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:BLMT_r10749_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
! LICK
| [[File:LICK_248_188_overlay.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_2sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_3sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_5sec_RotD50.png|thumb|300px]]
| [[File:LICK_r10747_248_v_188_10sec_RotD50.png|thumb|300px]]
|-
|}

==== Impact of rotation angle and smoothing zone ====

Based on the below analysis, we will rerun the stress test sites with the intended angle of -36 degrees and a 20 km smoothing zone so that all Study 24.8 results will be consistent.

We discovered that the stress test sites were run with a volume rotation angle of -55 degrees and a smoothing zone width of 10 km on either side of the interface. This is different from our intended rotation angle of -36 degrees and smoothing zone width of 20 km. To quantify the impact of this, we ran CFCS with the updated values. Comparisons are below. The black curves are the stress test run, the blue curves are the corrected run.

{|
! 2 sec !! 3 sec !! 5 sec !! 10 sec
|-
| [[File:CFCS_10733_v_10771_2sec_curve.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_3sec_curve.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_5sec_curve.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_10sec_curve.png|thumb|350px]]
|-
| [[File:CFCS_10733_v_10771_2sec_scatter.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_3sec_scatter.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_5sec_scatter.png|thumb|350px]]
| [[File:CFCS_10733_v_10771_10sec_scatter.png|thumb|350px]]
|}

== Events During Study ==

The main study began on 9/24/24 at 11:49:59 PDT.

We began with a maximum of 5 workflows on Frontier and 20 on Frontera. Later on 9/24 we increased the number of Frontier workflows to 15.

On 9/30, moment-carc wasn't passed to the Check Duration job for finishing PP workflows. I updated the dax generator to correctly pass through the desired database for this job.

On 9/30, I ran out of /home quota on Frontera. This was an issue because some of the rvGAHP-related logs are written here, and it resulted in "Failed to start transfer GAHP" errors. I cleaned up some space on /home and released the jobs.

On 9/30, the merge_pmc jobs were held because they still included the stress test reservation on Frontera. I removed the reservation string and released the jobs.

On 10/1, I found that the cronjob on Frontier to monitor job usage was removed from the crontab, so I added it back.

On 10/2, I turned off stochastic calculations on Frontera while we investigated the unexpected BB results from the stress test.

On 10/10, the work2 filesystem on Frontera, where the executables and rupture files are hosted, had a problem, causing all the Frontera jobs to be held. Additionally, login4, the host which connects to shock, was unavailable. When login4 returned we restarted the rvGAHP process.

On 10/16, the scottcal account was added to the CyberShake DesignSafe project. This meant that scottcal is now part of 3 allocations, leading to a Slurm error when jobs were submitted without specifying an account, meaning Condor jobs were held. I added the EAR20006 account to all Frontera jobs, and had to manually add it for jobs which were already planned.

On 10/16, I realized that DirectSynth jobs were requesting a wallclock time of 10 hours, but these jobs are usually only taking a bit more than 4. I changed the requested job length to 5 hours.

On 10/17, I discovered that the PP Error jobs were because the corresponding SGT workflow had finished its Update and Handoff jobs, but then the stage-out of the SGTs to Frontera failed because of Globus consents. The registration job is dependent on stage-out, so it didn't run either. Then, when the PP workflow tries to plan, it can't find a copy of the SGT files on Frontera and aborts. I couldn't use the standard CyberShake scripts to restart these workflows, since in the database they were already recorded as SGT Generated, so instead I just reran the pegasus-run commands in the log-plan* files.

On 10/18, I got an email from TACC staff that the jobs are causing too much load on the scratch filesystem, and a request to reduce the number of simultaneous jobs to 4. I reduced the number of Frontera slots to 4 in the workflow auto-submission tool, and am following up to learn the specifics of the problem and if there's a way to fix it.

SGT calculations on Frontier finished on 10/18/24 at 12:59:43 PDT.

On 10/21, the broadband transfers to Corral for Study 22.12 resulted in going over quota on CARC scratch1 again, interfering with the workflows for this study. I cleaned up scratch1 and fixed the issue.

On 10/28-30, the work2 filesystem and scheduler on Frontera had a number of issues, requiring restarts of the rvGAHP daemon and some work to recover the job state.

=== Renewal of Globus consents ===

We will track when we renew the Globus consents.

10/6

10/9

10/13

10/17

10/24

10/29

11/5

=== Restarts of the rvgahp daemons ===

We will track when we restart the rvgahp daemons on login10@frontier and login4@frontera.

10/9 on Frontera

10/10 on Frontera (node crashed)

10/29 on Frontera (filesystem issues)

10/30 on Frontera (continuing filesystem issues)

11/7 on Frontera

== Performance Metrics ==

At the start of the main study, project geo156 on Frontier has used 609101 node-hours (of 700,000). User callag has used 33398 node-hours. Project EAR20006 has used 12925.147 node-hours (of 676,000). User scottcal has used 503.796 node-hours.

At the end of the main study, project geo156 had used 671,656 node-hours. User callag has used 88881.2 node-hours. project EAR20006 had 511480 node-hours remaining (out of 676,000). User scottcal used 125411.21 node-hours.

In total, the study used 55483 node-hours on Frontier and 124907 node-hours on Frontera. This is difficult to translate into core-hours. Each Frontier node has 64 cores plus 8 GPUs. Each GPU has 110 compute units, so we will assume each node has 64 + 110*8 = 944 'cores'. Each Frontera node has 56 cores. We translate this to 52.4M core-hours on Frontier and 7.0M core-hours on Frontera.

The study ran from 9/24/24 11:49:59 PDT to 11/8/24 6:15:15 PST, a duration of 1075.4 hrs (44.8 days).

Our high-water marks were 4130 nodes on Frontier (44%) and 1029 nodes on Frontera (12%). Neither used a reservation or priority bump.

Pegasus managed about 1 PB of data.

We staged about 9 million output files totaling 36 TB back to long-term storage at USC CARC.

We ran 945 top-level workflows, with an average of 15 running at a time.

We ran approximately 27,720 jobs. Of these, 7245 were remote, 8190 were local, 5985 were directory creation, 5355 were staging, and 945 were registration.

126,818,608 three-component seismograms (half LF, half BB), 11.5 billion low-frequency IMs, and 22.8 billion broadband IMs were calculated.

Total number of rupture variations is 63,409,304.

== Production Checklist ==

*<s>Run test workflow against moment-carc.</s>
*<s>Investigate velocity profile differences with Mei's plots (s3171 and HAYW)</s>
*<s>Wrap period-dependent duration code and test in PP.</s>
*<s>Wrap period-dependent duration code and test in BB.</s>
*<s>Integrate period-dependent duration code into workflows.</s>
*<s>Update data and compute estimates.</s>
*<s>Determine where to copy output data.</s>
*<s>Modify workflows to remove double-staging of SGTs to Frontera.</s>
*<s>Schedule and hold readiness reviews with TACC and OLCF.</s>
*<s>Modify workflows to only insert RotD50, not RotD100.</s>
*<s>Science readiness review</s>
*<s>Technical readiness review</s>
*<s>Verify that vertical component response is being calculated correctly.</s>
*<s>Set up cronjobs to monitor usage.</s>
*<s>Solve issue with putting velocity parameters into the database from Frontier.</s>
*<s>Tag code in github repository</s>

== Presentations, Posters, and Papers ==

== References ==

File:CS-gof-LOMAP-2025050731-dist.png

2025-09-26T16:36:11Z

Scottcal: Scottcal uploaded a new version of File:CS-gof-LOMAP-2025050731-dist.png

File:CS-gof-LOMAP-2025050731-dist.png

2025-09-26T16:34:11Z

Scottcal: Scottcal uploaded a new version of File:CS-gof-LOMAP-2025050731-dist.png

File:CS-gof-LOMAP-2025050731-map.png

2025-09-26T16:32:56Z

Scottcal:

File:CS-gof-LOMAP-2025050731-dist.png

2025-09-26T16:32:49Z

Scottcal:

File:CS-gof-LOMAP-2025050731.png

2025-09-26T16:32:12Z

Scottcal:

Loma Prieta Validation

2025-09-26T16:28:43Z

Scottcal:

As part of the Study 24.8 validation process, we performed runs for the Loma Prieta event in the BBP for both the BBP and CyberShake.

== BBP 1D ==

{|
! Overall GoF
! GoF, best realization (#7)
! Residuals by distance (#7)
! Residual map (#7)
|-
| [[File:BBP-gof-LOMAP-20250424-combined.png|thumb|400px]]
| [[File:BBP-gof-LOMAP-2025042407.png|thumb|400px]]
| [[File:BBP-gof-LOMAP-2025042407-dist.png|thumb|400px]]
| [[File:BBP-gof-LOMAP-2025042407-map.png|thumb|400px]]
|}

== CyberShake 3D ==

{|
! Overall GoF
! GoF, best realization (#31)
! Residuals by distance (#31)
! Residual map (#31)
|-
| [[File:CS-gof-LOMAP-20250507-combined.png|thumb|400px]]
| [[File:CS-gof-LOMAP-2025050731.png|thumb|400px]]
| [[File:CS-gof-LOMAP-2025050731-dist.png|thumb|400px]]
| [[File:CS-gof-LOMAP-2025050731-map.png|thumb|400px]]
|}

== GMPEs ==

{|
| [[File:GMPE-gof-LOMAP.png|thumb|400px]]
|}

File:CS-gof-LOMAP-20250507-combined.png

2025-09-26T16:27:55Z

Scottcal: Scottcal uploaded a new version of File:CS-gof-LOMAP-20250507-combined.png

Callaghan Presentations

2025-09-26T06:31:55Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*IHPCSS workflow presentation: [[:File:2025_IHPCSS_workflows.pptx | PPTX]], [[:File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[:File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[:File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

File:2025 IHPCSS workflows.pdf

2025-09-26T06:31:23Z

Scottcal:

File:2025 IHPCSS workflows.pptx

2025-09-26T06:31:12Z

Scottcal:

File:2025 USGS NorCal CyberShake.pdf

2025-09-26T06:29:01Z

Scottcal:

File:2025 USGS NorCal CyberShake.pptx

2025-09-26T06:28:16Z

Scottcal:

Callaghan Presentations

2025-09-26T06:27:52Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*IHPCSS workflow presentation: [[File:2025_IHPCSS_workflows.pptx | PPTX]], [[File:2025_IHPCSS_workflows.pdf | PDF]]
*USGS NorCal Earthquake Hazards workshop CyberShake presentation: [[File:2025_USGS_NorCal_CyberShake.pptx | PPTX]], [[File:2025_USGS_NorCal_CyberShake.pdf | PDF]]

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

Callaghan Presentations

2025-09-26T06:25:43Z

Scottcal:

Callaghan Presentations

2025-09-26T06:04:02Z

Scottcal:

Below are links to presentations and related resources given by Scott Callaghan.

== 2025 ==
*IHPCSS workflow presentation:
*USGS NorCal Earthquake Hazards workshop CyberShake presentation:

== 2024 ==
*AGU24 and December staff meeting presentation: [[:File:AGU24_CyberShake_24_8_presentation.pptx | PPTX]], [[:File:AGU24_CyberShake_24_8_presentation.pdf | PDF]]
*SC24 presentation at OSU booth: [[:File:SC24_OSU_MPI_compression.pptx | PPTX]], [[:File:SC24_OSU_MPI_compression.pdf | PDF]]
*NGA-West3 CyberShake Study 24.8 overview: [[:File:Study_24.8_overview_for_NGAW3.odp | ODP]], [[:File:Study_24.8_overview_for_NGAW3.pdf | PDF]]
*Geo-INQUIRE Data Lake workshop CyberShake presentation: [[:File:CyberShake_Data_Lake_workshop.pptx | PPTX]], [[:File:CyberShake_Data_Lake_workshop.pdf | PDF]]
*IHPCSS Workflow talk: [[:File:2024_IHPCSS_workflows.pptx | PPTX]], [[:File:2024_IHPCSS_workflows.pdf | PDF]]

== 2023 ==
*December Staff Meeting CyberShake updates: [[:File:Dec_Staffmtg_CyberShake_update.pptx | PPTX]], [[:File:Dec_Staffmtg_CyberShake_update.pdf | PDF]]
*NGA-West3 CyberShake presentation: [[:File:2023_NGA_West3.pptx | PPTX]], [[:File:2023_NGA_West3.pdf | PDF]]
*SC23 early career talk: [[:File:SC23_ECP_career_talk.pptx | PPTX]], [[:File:SC23_ECP_career_talk.pdf | PDF]]
*IHPCSS seismology presentation: [[:File:2023_IHPCSS_seismology.pptx | PPTX]], [[:File:2023_IHPCSS_seismology.pdf | PDF]]
*IHPCSS workflow presentation: [[:File:2023_IHPCSS_workflows.pptx | PPTX]], [[:File:2023_IHPCSS_workflows.pdf | PDF]]
*GC11 conference (Solid Earth and Geohazards in the Exascale Era): [[:File:GC11_Callaghan_workflows.pptx | PPTX]]
*CyberTraining for Seismology talk on CyberShake Data Access tool: [[:File:CyberShake_tutorial_for_2023_CyberTraining.pptx | PPTX]]
*SSA CyberShake Study 22.12 talk: [[:File:2023_SSA_CyberShake_22_12.pptx | PPTX]], [[:File:2023_SSA_CyberShake_22_12.pdf | PDF]]

== 2022 ==

*SC22 Early Career talk (also given to ECP Work/Life balance group, and Sandia Parents Group): [[:File:2022_parental_balance.ppt | PPT]], [[:File:2022_parental_balance.pdf | PDF]]
*SC22 SIGHPC Education Chapter overview: [[:File:SC22_SIGHPC_Edu_overview.pptx | PPTX]], [[:File:SC22_SIGHPC_Edu_overview.pdf | PDF]]
*SOURCES career talk: [[:File:2022_Sources_career_talk.odp | ODP ]]
*IHPCSS workflow talk: [[:File:2022_IHPCSS_talk.pptx | PPTX]]
*SSA Broadband CyberShake Validation talk: [[:File:2022_SSA_Broadband_CyberShake.pptx | PPTX]], [[:File:2022_SSA_Broadband_CyberShake.pdf | PDF]]
*SSA CyberShake Study 21.12 talk: [[:File:2022_SSA_CyberShake_21_12.pptx | PPTX]], [[:File:2022_SSA_CyberShake_21_12.pdf | PDF]]
*SCEC staff meeting talk: [[:File:Feb_2022_staff_meeting.pptx | PPTX]], [[:File:Feb_2022_staff_meeting.pdf | PDF]]

== 2021 ==
* AGU CyberShake talk: [[:File:AGU_2021_CyberShake.pptx | PPTX full]], [[:File:AGU_2021_CyberShake_lighting.pptx | PPTX lightning]]
* IHPCSS Workflow talk: [[:File:2021_IHPCSS_workflow.pptx | PPTX]], [[:File:2021_IHPCSS_workflow.pdf | PDF]]

== 2020 ==
* Polytechnic talk resources: [[Poly 2020 outreach discussion]]
* AGU CyberShake talk: [[File:AGU_2020_CyberShake.pptx | PPTX]]

== 2019 ==
* AGU CyberShake talk: [[:File:AGU_2019_CyberShake.pptx | PPTX]]
* SC19 USC booth talk: [[:File:SC19_Callaghan_USC_booth.pptx | PPTX]] or [[:File:SC19_Callaghan_USC_Booth.pdf | PDF]]
* SCEC Research Computing workshop lightning talk: [[:File:2019_SCEC_Research_Computing_CyberShake_lightning.pdf | PDF]]
* IHPCSS Workflow talk: [[:File:2019_IHPCSS_workflow.pptx | PPTX]]
* UseIT talk about HPC at SCEC: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202019.pptx slides (PPTX), external link]
* SSA CyberShake science talk: [[:File:2019_SSA_CyberShake_Science_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Science_Presentation.pdf | PDF]]. Here are links to the [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/point_src_gtl_v2.wmv 10 km smoothing movie] and [http://hypocenter.usc.edu/research/cybershake/study_18_5/fwd_sims/pt_src_gtl_20km_v2.wmv 20 km smoothing movie]
* SSA CyberShake technical talk: [[:File:2019_SSA_CyberShake_Technical_Presentation.pptx | PPTX]] or [[:File:2019_SSA_CyberShake_Technical_Presentation.pdf | PDF]]

== 2018 ==

* IHPCSS workflow talk: [[:File:2018_IHPCSS_workflow.pptx | PPTX]] or [[:File:2018_IHPCSS_workflow.pdf | PDF]]
* Blue Waters Symposium talk: [[:File:Callaghan_Blue_Waters_Symposium.pptx | PPTX]]
* QuakeCore GMS&V talk: [[:File:CyberShake_QuakeCore_Presentation.pptx | PPTX]] or [[:File:CyberShake_QuakeCore_Presentation.pdf | PDF]]
* Machine learning with Keras overview: [[:File:Machine_Learning_with_Keras.odp | ODP]]

== 2017 ==

* AGU CyberShake talk: [[:File:2017_AGU_CyberShake.pptx | PPTX]]
* PG&E CyberShake update: [[:File:PGE_CyberShake_update.pptx | PPTX]] or [[:File:PGE_CyberShake_update.pdf | PDF]]
* SC17 USC booth talk: [[:File:SC17_USC_booth.pptx | PPTX]] or [[:File:SC17_USC_Booth.pdf | PDF]]
* SC17 WORKS'17 talk on rvGAHP: [[:File:WORKS17_rvGAHP.pptx | PPTX]] or [[:File:WORKS17_rvGAHP.pdf | PDF]]
* SC17 Women in HPC Mentoring talk: [[:File:2017_WHPC_Workshop.pptx | PPTX]] or [[:File:2017_WHPC_Workshop.pdf | PDF]]
* SCEC Annual Meeting plenary CyberShake presentation: [[:File:2017_SCEC_AM_CyberShake.pptx | PPTX]] or [[:File:2017_SCEC_AM_CyberShake.pdf | PDF]]
* SCEC Nonlinear Workshop presentation: [[:File:2017_SCEC_Nonlinear_Workshop.pptx | PPTX]] or [[:File:2017_SCEC_Nonlinear_Workshop.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2017_IHPCSS_workflow.pptx | PPTX]] or [[:File:2017_IHPCSS_workflow.pdf | PDF]]
* UseIT Blue Waters tutorial: [[:File:2017_UseIT_HPC_tutorial.odt | tutorial text (ODT)]] and [[:File:2017_UseIT_Linux_commands.doc | Linux Command guide (DOC)]]
* UseIT HPC at SCEC talk: [http://hypocenter.usc.edu/research/presentations/SCEC%20HPC%202017.pptx slides (PPTX), external link] and [[:File:2017_UseIT_HPC_spreadsheet.xlsx | supplemental spreadsheet (XLSX)]]
* SSA CyberShake talk: [[:File:Callaghan_2017_SSA_CyberShake.pptx | PPTX]] or [[:File:Callaghan_2017_SSA_CyberShake.pdf | PDF]]
* Blue Waters workflow seminar: [[:File:Blue_Waters_Workflow_Seminar_Overview.pptx | PPTX]] or [[:File:Blue_Waters_Workflow_Seminar_Overview.pdf | PDF]]

== 2016 ==

* SC16 USC booth talk: [[:File:SC16_RSQSim_UseIT_USC_booth.pdf | PDF]] or [[:File:SC16_RSQSim_UseIT_USC_booth.odp | ODP]]
* SCEC Annual Meeting: [[:File:SCEC_2016_AM_CyberShake_CISM.pptx | PPTX]] or [[:File:SCEC_2016_AM_CyberShake_CISM.pdf | PDF]]
* XSEDE Workflow overview talk: [[File:2016_Callaghan_overview_of_workflows.pptx | PPTX]]
* IHPCSS workflow talk: [[:File:2016_IHPCSS_workflow.pptx | PPTX]] or [[:File:2016_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2016_UseIT_HPC.pptx | HPC talk (PPTX)]] and [[:File:2016_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]]
* UseIT [[:File:2016_UseIT_HPC_tutorial.odt | HPC tutorial (ODT)]] and [[:File:2016_UseIT_Linux_commands.odt | Sample Linux Commands (ODT)]]
* CyberShake [[:File:2016_CCSP.odp | CCSP presentation (ODP)]]
* CyberShake [[:File:2016_UCERF3_downsampling.odp | UCERF3 downsampling presentation (ODP)]]

== 2015 ==

* SC15 USC booth talk: [[:File:SC15_CyberShake_USC_booth.pptx | PPTX]]

== 2014 ==

* IHPCSS seismology talk: [[:File:2014_IHPCSS_seismology.pptx | PPTX]] or [[:File:2014_IHPCSS_seismology.pdf | PDF]]
* IHPCSS workflow talk: [[:File:2014_IHPCSS_workflow.pptx | PPTX]] or [[:File:2014_IHPCSS_workflow.pdf | PDF]]
* UseIT [[:File:2014_UseIT_HPC.pptx | HPC tutorial (PPTX)]] [[:File:2014_UseIT_HPC_spreadsheet.xlsx | Supplemental spreadsheet (XLSX)]] [[:File:2014_UseIT_HPC_matrix_mult.docx | Supplemental matrix multiplication (DOCX)]]

== Related Entries ==
*[[SC16]]

Broadband CyberShake Validation

2025-09-16T00:12:02Z

Scottcal: /* Multi-fault GMPEs */

This page follows on [[CyberShake BBP Verification]], moving from 1D comparisons to 3D CyberShake comparisons with both the BBP and observations.

== Process ==

These are the steps involved in comparing CyberShake and BBP results to observations for a verification event.

=== BBP ===

#Create a working directory.
#Create an src_files directory inside it.
#Copy the src file from the BBP validation directory into the src_files directory.
#Copy the station list into the working directory.
#Run run_bbp.py with the '--expert -g' arguments to create an XML file description of the run. Instead of using the defaults for the validation event, point to the station list file in the working directory and the src file in the src_files directory. Include the GP GOF, but not FAS.
#Copy the created XML file into the working directory.
#Run helper_scripts/create_srcs.sh, which will create 64 random seeds and then create 64 realizations by copying over the initial src file and changing the random seed
#Create 64 directories, one for each source.
#Run helper_scripts/prepare_lsf_files.sh script. This will copy both the XML file and the run_bbp_src.lsf script into each realization directory, and make the needed changes to each for that realization.
#Submit all 64 src_*/run_bbp_src*.lsf files.
#Once all 64 run successfully, make a purple_plot/Sims directory, and logs, indata, tmpdata, and outdata directories inside it.
#Edit stage_purple_plot.sh to have the right sim_id.
#Run stage_purple_plot.sh .
#Run utils/batch/combine_gof_gen.py -d purple_plot -o . -c gp
#Examine the .png file produced to make sure it looks OK.

=== CyberShake ===

==== Set up and run BBP validation event ====

<ol>
Setup
<li>Create working directory on local system.</li>
<li>Copy in the following scripts:
*insert_sites_from_list.py
*pop_seeds.py
*update_dist.py
*pop_rvs.py
*pop_site_ruptures.py</li>

 Create the sites.
<li>Copy over *.stl list from BBP validation event.</li>
<li>Copy stl list into a bbp_to_cs version of the stl list.</li>
<li>Run the script ./check_for_duplicate_stations.py to see if any stations used by this event are already in the CyberShake site list.</li>
<li>For the stations not in the CyberShake site list, determine their full name from https://www.strongmotioncenter.org/wserv/stations/builder/ . If no full name exists, look at Google maps and make one up. Add the abbreviation to the bbp_to_cs file, and add a full entry (lon, lat, short name, long name, 3) for each new site into a sites_to_insert.txt file.</li>
<li>Check each new site short name to make sure one doesn’t already exist in the DB.</li>
<li>Run insert_sites_from_list.py on the sites_to_insert.txt file.</li>

 Set up the rupture variations remotely.
<li>On the remote system, create a directory inside the Ruptures_erf60 directory corresponding to the source_id of the run.</li>
<li>Inside the source_id directory, create one directory for each realization, which will each be its own rupture.</li>
<li>Copy the realizations from the BBP tmpdirs in which the realizations were created, into the corresponding source directory.</li>
<li>Create a symlink to each SRF with the name <src_id>_<rup_id>_event<rup_id>.srf .</li>
<li>Create rupture geometries, <src_id>_<rup_id>.txt, for each file. Note that each of these rupture geometries will be slightly different due to the subfaults shifting. To create the rupture geometry files, run RuptureCodes/utils/extract_rup_geom on each rupture.</li>
<li>Determine the distances from each station to each rupture variation by running calc_distance.py for each variation on a site file in lon, lat, short name format.</li>
<li>Copy the rupture geometry files and the distance files back locally.</li>
<li>Copy the random_seeds.txt file from the BBP validation dir/src_files locally.</li>

 Insert rupture variations into database.
<li>Run pop_rvs.py, pointing to the rupture geometry files, to insert the rupture variations into the DB.</li>
<li>Run pop_site_ruptures.py, pointing to a site list file, the distance files, and rupture geometry files.</li>
<li>Run pop_seeds.py on the random_seeds.txt file to populate the seeds into the DB.</li>
<li>Create a new RLS file on shock with the LFNs for both the rupture geometries and the SRFs.</li>
<li>Run pegasus-rc-client to insert the LFNs into the DB.</li>
</ol>

==== Perform GoF analysis on results ====

<ol>
<li>Create a working directory.</li>
<li>Copy the src_files directory from the Broadband validation run directory.</li>
<li>Copy in the *.stl file from the BBP for this validation event.</li>
<li>Create site_list.txt, with one CyberShake site per line.
<li>From another CyberShake validation directory, copy in the following scripts:
<ul>
<li>import.lsf</li>
<li>prep.lsf</li>
<li>prep_stat.sh</li>
<li>rename.py</li>
<li>run_gof.sh</li>
<li>stage_purple_plot.sh</li>
<li>run_cs_src0.lsf</li>
</ul></li>
<li>Create a .tgz file on shock with the seismograms for all the stations and all the events.</li>
<li>Unzip this .tgz file into the working directory.</li>
<li>Submit prep.lsf. This will copy the seismograms from the station directories into the src directories, and then process them into BBP-friendly format.</li>
<li>Edit rename.py to point to the BB-to-CS STL file, and then run it to rename the seismograms to include the full BBP site names.</li>
<li>Edit import.lsf to use the correct Run ID prefix, src_id, directory name, and BBP STL file, then submit it. This script will import the seismograms into BBP working directories, so that the BBP can run GoF on them.</li>
<li>Run the BBP to create an XML file which includes running the GoF. To do this, run <pre>run_bbp.py --expert -g</pre> When prompted, select
<ul><li>'validation simulation'</li>
<li>the validation simulation created in the first part from the list</li>
<li>'GP'</li>
<li>yes custom source</li>
<li>point to BBP-provided source installed in src_files directory</li>
<li>yes rupture generator</li>
<li>custom list</li>
<li>point to list in the working directory</li>
<li>yes site response</li>
<li>yes velocity seismogram plots</li>
<li>yes acceleration seismogram plots</li>
<li>no GMPE comparisons</li>
<li>yes goodness-of-fit</li>
<li>'GP'</li>
<li>no additional metrics</li></ul>
Copy the created XML file into the working directory.
</li>
<li>Edit run_cs_src0.lsf and set SIM_ID_PREFIX, DIR_NAME, and XML_PREFIX to the correct values for this event.</li>
<li>Edit run_gof.sh to set DIR_NAME and XML_PREFIX to the same values, and modify the paths to the *.src and *.srf files used in the sed commands.</li>
<li>Run run_gof.sh, which will submit a job to calculate GoF for each of the 64 realizations.</li>
<li>Create the directory purple_plot/Sims. Inside there, create 4 directories: logs, indata, tmpdata, and outdata.</li>
<li>Edit stage_purple_plot.sh to use the correct sim id.</li>
<li>Run stage_purple_plot.sh.</li>
<li>Create the directory purple_plot_output.</li>
<li>Run bbp/utils/batch/combine_gof_gen.py -d purple_plot -o purple_plot_output -c gp to produce a purple plot, combining the GoF results from all stations and events.</li>
<li>Run bbp/utils/batch/compare_bbp_runs.py -d purple_plot -o purple_plot_output/ -c gp to generate the bias values.</li>
</ol>

=== Multi-fault GMPEs ===

The BBP, as of v22.4, isn't set up to produce realistic GMPE estimates for multi-fault ruptures. Therefore, producing meaningful GMPE comparisons requires generating the GMPE estimates outside of the BBP and then importing them. The steps for this are detailed below:

<ol>
<li>Ask someone (like Kevin) to produce GMPE estimates at a variety of periods for the event. The station list and event information must be provided.</li>
<li>This information is delivered in a series of CSV files, one per period. Convert the CSV files into .ri50 files.</li>
<li>Copy the .ri50 files into a working directory.</li>
<li>To get the observation files in *.rd50 format, you can either copy them in from a previous run, or you can generate them. To generate them, run:
<pre>$> mkdir $BBP_DATA_DIR/logs/<arbitrary run ID>
$> $BBP_DIR/comps/obs_seismograms.py $BBP_VAL_DIR/path/to/site_list.stl $BBP_VAL_DIR/path/to/observations/Acc acc_peer "" <arbitrary run ID>
$> cp -r $BBP_DATA_DIR/<arbitrary run id>/obs_seis_<event> .</pre></li>
<li>Next, run gmpe_gof.py to generate the comparison metrics:
<pre>$GMSVTOOLKIT_DIR/stats/gmpe_gof.py --gmpe-dir . --comp-dir obs_seis_<event> --station-list /path/to/site_list.stl --src-file /path/to/first/segment/src_file.src --comp-label <label> --gmpe-group nga-west2</pre></li>
<li>Finally, plot the results using plot_gmpe_gof.py:
<pre>$GMSVTOOLKIT_DIR/plots/plot_gmpe_gof.py --input-dir . --output-dir . --comp-label <label> --gmpe-group nga-west2 --station-list /path/to/site_list.stl</pre></li>
</ol>

== Northridge ==

=== 1D BBP comparisons ===

We calculated 64 realizations for Northridge for these [[Media:northridge_stations.kml | 38 stations]].

Some of the differences between the 1D BBP and 3D CyberShake results can be attributed to differences in site response, which is calculated based on the reference velocity ('vref') and the vs30 of the site. A spreadsheet with vref and Vs30 for both the BBP and CyberShake is available [[File:BBP_v_CyberShake_Northridge_vs30.xls | here.]]

==== V1 (2/14/22) ====

Initially, we used vref=500 for both the high-frequency and low-frequency site response. However, this is incorrect; vref for the low-frequency should vary depending on the properties of the 3D velocity mesh.

==== V2 (2/25/22) ====

We continued to use vref=500 for the high-frequency site response. For the low-frequency site response, we are now using the same vref we used in Study 15.12:

vref_LF_eff = Vs30 * [ VsD5H / Vs5H ]

Vs30 = 30 / Sum (1/(Vs sampled from [0.5,29.5] in 1 meter increments))

H = grid spacing

Vs5H = travel time averaged Vs, computed from the CVM in 1 meter increments down to a depth of 5*H

VsD5H = discrete travel time averaged Vs computed from 3D velocity mesh used in the SGT calculation over the upper 5 grid points

So, for H=100m Vs5H would be:

Vs500 = 500 / ( Sum ( 1 / Vs sampled from [0.5,499.5] in 1 meter increments ))

And then VsD5H is given by:

VsD500 = 5/{ 0.5/Vs(Z=0m) + 1/Vs(Z=100m) + 1/Vs(Z=200m) + 1/Vs(Z=300m) + 1/Vs(Z=400m) + 0.5/Vs(Z=500m) }

Below are the ts_process plots for a subset of 10 stations, comparing the 3D CyberShake with 1D BBP results.

{|
! Site !! TS Process plot
|-
! SCE || [[File:ts_process_SCE_src0_2_25.png|thumb|400px]]
|-
! SYL || [[File:ts_process_SYL_src0_2_25.png|thumb|400px]]
|-
! LDM || [[File:ts_process_LDM_src0_2_25.png|thumb|400px]]
|-
! PAC || [[File:ts_process_PAC_src0_2_25.png|thumb|400px]]
|-
! PKC || [[File:ts_process_PKC_src0_2_25.png|thumb|400px]]
|-
! SPV || [[File:ts_process_SPV_src0_2_25.png|thumb|400px]]
|-
! WON || [[File:ts_process_WON_src0_2_25.png|thumb|400px]]
|-
! KAT || [[File:ts_process_KAT_src0_2_25.png|thumb|400px]]
|-
! RO3 || [[File:ts_process_RO3_src0_2_25.png|thumb|400px]]
|-
! ANA || [[File:ts_process_ANA_src0_2_25.png|thumb|400px]]
|}

==== V3 (3/2/22) ====

Next, we recalculated the CyberShake results for 10 sites, using the BBP vs30 values for both the low-frequency and high-frequency elements. Note that the vref low-frequency value for CyberShake is still being derived from the velocity model.

{|
! Site !! TS Process plot
|-
! SCE || [[File:ts_process_SCE_src0_3_2.png|thumb|400px]]
|-
! SYL || [[File:ts_process_SYL_src0_3_2.png|thumb|400px]]
|-
! LDM || [[File:ts_process_LDM_src0_3_2.png|thumb|400px]]
|-
! PAC || [[File:ts_process_PAC_src0_3_2.png|thumb|400px]]
|-
! PKC || [[File:ts_process_PKC_src0_3_2.png|thumb|400px]]
|-
! SPV || [[File:ts_process_SPV_src0_3_2.png|thumb|400px]]
|-
! WON || [[File:ts_process_WON_src0_3_2.png|thumb|400px]]
|-
! KAT || [[File:ts_process_KAT_src0_3_2.png|thumb|400px]]
|-
! RO3 || [[File:ts_process_RO3_src0_3_2.png|thumb|400px]]
|-
! ANA || [[File:ts_process_ANA_src0_3_2.png|thumb|400px]]
|}



=== Observational Comparisons ===

We calculated goodness-of-fit results for both Broadband CyberShake and the BBP against observations for Northridge, using the 64 realizations and 38 stations.

TS process plots comparing the 3 results are available here: [https://g-c662a6.a78b8.36fe.data.globus.org/cybershake/Broadband_CyberShake/validation/Northridge/ts_process_nr.tgz v1 ts process plots].

==== Broadband Platform ====

{|
! Overall GoF !! GoF, best realization (#7) !! GoF, worse realization (#15)
|-
| [[File:BBP-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-GoF-NR-real7.png|thumb|400px]]
| [[File:BBP-GoF-NR-real15.png|thumb|400px]]
|}

==== CyberShake v4_8 ====

{|
! Overall GoF !! GoF, best realization (#53) !! GoF, worse realization (#54)
|-
| [[File:CyberShake-GoF-NR-4_8_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_real53.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_real54.png|thumb|400px]]
|}

==== Broadband Platform, updated frequency bands ====

We realized that our GoF comparisons were run using hard-coded frequency bands of [0.05, 50] Hz. This was correct when doing CS-to-BBP comparisons, but not correct when using observations. We updated the frequency bands and reran the GoF.

{|
! Overall GoF !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25) !! GoF, best CS realization (#40) !! GoF, worst CS realization (#37)
|-
| [[File:BBP-freqbands-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real47.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real25.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real40.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real37.png|thumb|400px]]
|}

==== CyberShake v4_8, updated frequency bands ====

As above, reran the GoF.

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#37) !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25)
|-
| [[File:CyberShake-GoF-NR-4_8_freqbands_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real37.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real47.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real25.png|thumb|400px]]
|}

==== CyberShake v4_28, BBP Vs30 ====

We recalculated the CyberShake GoF results, using the BBP Vs30 values.

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51) !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25)
|-
| [[File:CyberShake-GoF-NR-4_28_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real51.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real47.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real25.png|thumb|400px]]
|}

==== BBP, FAS ====

{|
| [[File:CyberShake-GoF-NR-BBP_FAS.png|thumb|400px]]
|}

==== CyberShake v4_7, FAS ====

{|
| [[File:CyberShake-GoF-NR-4_7_FAS.png|thumb|400px]]
|}

=== Observational Comparisons, BBP v22.4 ===

We repeated the comparisons, using BBP v22.4 for both the 1D BBP and 3D CyberShake calculations.

==== BBP ====

{|
! Overall GoF !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51) !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51)
|-
| [[File:BBP-v22.4-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real6.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real51.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real40.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real51.png|thumb|400px]]
|}

==== CyberShake ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-9_1_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real51.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real51.png|thumb|400px]]
|}

=== CyberShake, updated velocity model ===

{|
! Overall GoF !! GoF, best CS realization (#33) !! GoF, worst CS realization (#51)
|-
| [[File:CyberShake-GoF-NR-11_28_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-11_28_real33.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-11_28_real51.png|thumb|400px]]
|}

=== Study 22.12 configuration ===

These are the validation results using the Study 22.12 configuration, with risetime_coef=2.3 and hb_high_v6.1.1.

==== BBP (12/9/22) ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#9) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-12_9_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real9.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real51.png|thumb|400px]]
|}

==== CyberShake (12/11/22) ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#9) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-12_11_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real9.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real51.png|thumb|400px]]
|}

==== SRF plots ====

{|
! Best CS realization (#40)
| [[File:NR_v14_02_1_40.png|thumb|400px]]
|-
! Best BBP realization (#6)
| [[File:NR_v14_02_1_6.png|thumb|400px]]
|}

== Chino Hills ==

For our second event, we selected Chino Hills.

=== Sites ===

The BBP validation event for Chino Hills has 40 stations. A KML file with the stations is available [[:File:chino_hills_stations.kml|here]].

=== BBP ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#35) !! GoF, worst CS realization (#34)
|-
| [[File:BBP-GoF-CH-combined.png|thumb|400px]]
| [[File:BBP-GoF-CH-real24.png|thumb|400px]]
| [[File:BBP-GoF-CH-real35.png|thumb|400px]]
| [[File:BBP-GoF-CH-real34.png|thumb|400px]]
|}

{| Overall FAS
| [[File:BBP-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-GoF-CH-real35.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP Vs30 values ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-BBPvs30-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real35.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-BBPvs30-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4 ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, best BBP realization (#24) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-9_2-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real35.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4, BBP Vs30 ===

== Whittier ==

Our third event is Whittier.

=== Sites ===

The BBP validation event for Whittier has 39 stations, one of which is a duplicate. A KML file with the 38 stations used in these tests is available [[:File:whittier_stations.kml|here]].

=== BBP ===

{|
! Overall GoF !! GoF, best realization (#15) !! GoF, worst realization (#7) !! GoF, best CS realization (#62) !! GoF, worst CS realization (#3)
|-
| [[File:BBP-GoF-WH-combined.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052315.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052307.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052362.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052303.png|thumb|400px]]
|}

{| Overall FAS
| [[File:BBP-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake ===

These results are incomplete, without 2 of the stations (VER and PMN).

{|
! Overall GoF !! GoF, best realization (#62) !! GoF, worst realization (#3) !! GoF, best BBP realization (#15) !! GoF, worst BBP realization (#7)
|-
| [[File:CS-GoF-WH-combined.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061362.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061303.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061315.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061307.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP Vs30 values ===

{|
! Overall GoF !! GoF, best realization !! GoF, worst realization !! GoF, best BBP realization !! GoF, worst BBP realization
|-
| [[File:CS-BBPvs30-GoF-WH-combined.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-BBPvs30-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4 ===

{|
! Overall GoF !! GoF, best realization (#62) !! GoF, worst realization (#39) !! GoF, best BBP realization (#15) !! GoF, worst BBP realization (#7)
|-
| [[File:CS-9_4-GoF-WH-combined.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real62.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real39.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real15.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real7.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4, BBP Vs30 values ===

== Landers ==

=== Single fault realization ===

==== CS (2/15/22) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, best BBP realization (#13)
|-
| [[File:CS-GoF-Landers-2_15_combined.png|thumb|400px]]
| [[File:CS-GoF-Landers-2_15_real6.png|thumb|400px]]
| [[File:CS-GoF-Landers-2_15_real13.png|thumb|400px]]
|}

==== BBP (12/10/22) ====

{|
! Overall GoF !! GoF, best CS realization (#9) !! GoF, best BBP realization (#13)
|-
| [[File:BBP-GoF-Landers-12_10_combined.png|thumb|400px]]
| [[File:BBP-GoF-Landers-12_10_real9.png|thumb|400px]]
| [[File:BBP-GoF-Landers-12_10_real13.png|thumb|400px]]
|}

==== CyberShake (Study 22.12 configuration, 12/12/22) ====

{|
! Overall GoF !! GoF, best CS realization (#9) !! GoF, worst CS realization (#22) !! GoF, best BBP realization (#13) !! GoF, worst BBP realization (#22)
|-
| [[File:CS-GoF-Landers-12_12_combined.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real9.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real22.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real13.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real22.png|thumb|400px]]
|}

==== GMPE ====

{|
| [[File:GMPE-GoF-Landers-single.png|thumb|400px]]
|}

=== Multi fault realization ===

==== BBP ====

{|
! Overall GoF !! GoF, best CS realization (#54) !! GoF, worst CS realization (#11) !! GoF, best BBP realization (#55) !! GoF, worst BBP realization (#11)
|-
| [[File:BBP-GoF-Landers-9_22_combined.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real54.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real11.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real55.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real11.png|thumb|400px]]
|}

==== CyberShake ====

{|
! Overall GoF !! GoF, best CS realization (#54) !! GoF, worst CS realization (#11) !! GoF, best BBP realization (#55) !! GoF, worst BBP realization (#11)
|-
| [[File:CyberShake-GoF-Landers-8_25_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real54.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real11.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real55.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real11.png|thumb|400px]]
|}

==== GMPE ====

Fabio notes that the GMPE codes we have on the BBP are not set up for multi-segment events, and probably only use the first segment in the rupture.

{|
| [[File:GMPE-GoF-Landers-multi.png|thumb|400px]]
|}

== Ridgecrest ==

We looked at both the smaller Ridgecrest (7/4/19, M6.4) 'A' event and the larger (7/6/19, M7.1) multi-fault 'C' event.

=== Ridgecrest A ===

==== BBP (6/19/23) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, worst CS realization (#16) !! GoF, best BBP realization (#27) !! GoF, worst BBP realization (#16)
|-
| [[File:BBP-GoF-RidgecrestA-6_19_combined.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real06.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real16.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real27.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real16.png|thumb|400px]]
|}

==== CyberShake (9/29/23) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, worst CS realization (#16) !! GoF, best BBP realization (#27) !! GoF, worst BBP realization (#16)
|-
| [[File:CyberShake-GoF-RidgecrestA-9_29_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real06.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real16.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real27.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real16.png|thumb|400px]]
|}

==== GMPE ====

{|
| [[File:GMPE-GoF-RidgecrestA.png|thumb|400px]]
|}

=== Ridgecrest C multi-fault ===

==== BBP (10/18/23) ====

{|
! Overall GoF !! GoF, best CS realization (#32) !! GoF, best BBP realization (#49)
|-
| [[File:BBP-GoF-RidgecrestC-10_18_combined.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestC-10_18_real32.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestC-10_18_real49.png|thumb|400px]]
|}

==== CyberShake (11/29/23) ====

{|
! Overall GoF !! GoF, best CS realization (#32) !! GoF, best BBP realization (#49)
|-
| [[File:CyberShake-GoF-RidgecrestC-11_29_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestC-11_29_real32.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestC-11_29_real49.png|thumb|400px]]
|}

== North Palm Springs ==

Broadband CyberShake Validation

2025-09-15T21:39:26Z

Scottcal: /* Process */

This page follows on [[CyberShake BBP Verification]], moving from 1D comparisons to 3D CyberShake comparisons with both the BBP and observations.

== Process ==

These are the steps involved in comparing CyberShake and BBP results to observations for a verification event.

=== BBP ===

#Create a working directory.
#Create an src_files directory inside it.
#Copy the src file from the BBP validation directory into the src_files directory.
#Copy the station list into the working directory.
#Run run_bbp.py with the '--expert -g' arguments to create an XML file description of the run. Instead of using the defaults for the validation event, point to the station list file in the working directory and the src file in the src_files directory. Include the GP GOF, but not FAS.
#Copy the created XML file into the working directory.
#Run helper_scripts/create_srcs.sh, which will create 64 random seeds and then create 64 realizations by copying over the initial src file and changing the random seed
#Create 64 directories, one for each source.
#Run helper_scripts/prepare_lsf_files.sh script. This will copy both the XML file and the run_bbp_src.lsf script into each realization directory, and make the needed changes to each for that realization.
#Submit all 64 src_*/run_bbp_src*.lsf files.
#Once all 64 run successfully, make a purple_plot/Sims directory, and logs, indata, tmpdata, and outdata directories inside it.
#Edit stage_purple_plot.sh to have the right sim_id.
#Run stage_purple_plot.sh .
#Run utils/batch/combine_gof_gen.py -d purple_plot -o . -c gp
#Examine the .png file produced to make sure it looks OK.

=== CyberShake ===

==== Set up and run BBP validation event ====

<ol>
Setup
<li>Create working directory on local system.</li>
<li>Copy in the following scripts:
*insert_sites_from_list.py
*pop_seeds.py
*update_dist.py
*pop_rvs.py
*pop_site_ruptures.py</li>

 Create the sites.
<li>Copy over *.stl list from BBP validation event.</li>
<li>Copy stl list into a bbp_to_cs version of the stl list.</li>
<li>Run the script ./check_for_duplicate_stations.py to see if any stations used by this event are already in the CyberShake site list.</li>
<li>For the stations not in the CyberShake site list, determine their full name from https://www.strongmotioncenter.org/wserv/stations/builder/ . If no full name exists, look at Google maps and make one up. Add the abbreviation to the bbp_to_cs file, and add a full entry (lon, lat, short name, long name, 3) for each new site into a sites_to_insert.txt file.</li>
<li>Check each new site short name to make sure one doesn’t already exist in the DB.</li>
<li>Run insert_sites_from_list.py on the sites_to_insert.txt file.</li>

 Set up the rupture variations remotely.
<li>On the remote system, create a directory inside the Ruptures_erf60 directory corresponding to the source_id of the run.</li>
<li>Inside the source_id directory, create one directory for each realization, which will each be its own rupture.</li>
<li>Copy the realizations from the BBP tmpdirs in which the realizations were created, into the corresponding source directory.</li>
<li>Create a symlink to each SRF with the name <src_id>_<rup_id>_event<rup_id>.srf .</li>
<li>Create rupture geometries, <src_id>_<rup_id>.txt, for each file. Note that each of these rupture geometries will be slightly different due to the subfaults shifting. To create the rupture geometry files, run RuptureCodes/utils/extract_rup_geom on each rupture.</li>
<li>Determine the distances from each station to each rupture variation by running calc_distance.py for each variation on a site file in lon, lat, short name format.</li>
<li>Copy the rupture geometry files and the distance files back locally.</li>
<li>Copy the random_seeds.txt file from the BBP validation dir/src_files locally.</li>

 Insert rupture variations into database.
<li>Run pop_rvs.py, pointing to the rupture geometry files, to insert the rupture variations into the DB.</li>
<li>Run pop_site_ruptures.py, pointing to a site list file, the distance files, and rupture geometry files.</li>
<li>Run pop_seeds.py on the random_seeds.txt file to populate the seeds into the DB.</li>
<li>Create a new RLS file on shock with the LFNs for both the rupture geometries and the SRFs.</li>
<li>Run pegasus-rc-client to insert the LFNs into the DB.</li>
</ol>

==== Perform GoF analysis on results ====

<ol>
<li>Create a working directory.</li>
<li>Copy the src_files directory from the Broadband validation run directory.</li>
<li>Copy in the *.stl file from the BBP for this validation event.</li>
<li>Create site_list.txt, with one CyberShake site per line.
<li>From another CyberShake validation directory, copy in the following scripts:
<ul>
<li>import.lsf</li>
<li>prep.lsf</li>
<li>prep_stat.sh</li>
<li>rename.py</li>
<li>run_gof.sh</li>
<li>stage_purple_plot.sh</li>
<li>run_cs_src0.lsf</li>
</ul></li>
<li>Create a .tgz file on shock with the seismograms for all the stations and all the events.</li>
<li>Unzip this .tgz file into the working directory.</li>
<li>Submit prep.lsf. This will copy the seismograms from the station directories into the src directories, and then process them into BBP-friendly format.</li>
<li>Edit rename.py to point to the BB-to-CS STL file, and then run it to rename the seismograms to include the full BBP site names.</li>
<li>Edit import.lsf to use the correct Run ID prefix, src_id, directory name, and BBP STL file, then submit it. This script will import the seismograms into BBP working directories, so that the BBP can run GoF on them.</li>
<li>Run the BBP to create an XML file which includes running the GoF. To do this, run <pre>run_bbp.py --expert -g</pre> When prompted, select
<ul><li>'validation simulation'</li>
<li>the validation simulation created in the first part from the list</li>
<li>'GP'</li>
<li>yes custom source</li>
<li>point to BBP-provided source installed in src_files directory</li>
<li>yes rupture generator</li>
<li>custom list</li>
<li>point to list in the working directory</li>
<li>yes site response</li>
<li>yes velocity seismogram plots</li>
<li>yes acceleration seismogram plots</li>
<li>no GMPE comparisons</li>
<li>yes goodness-of-fit</li>
<li>'GP'</li>
<li>no additional metrics</li></ul>
Copy the created XML file into the working directory.
</li>
<li>Edit run_cs_src0.lsf and set SIM_ID_PREFIX, DIR_NAME, and XML_PREFIX to the correct values for this event.</li>
<li>Edit run_gof.sh to set DIR_NAME and XML_PREFIX to the same values, and modify the paths to the *.src and *.srf files used in the sed commands.</li>
<li>Run run_gof.sh, which will submit a job to calculate GoF for each of the 64 realizations.</li>
<li>Create the directory purple_plot/Sims. Inside there, create 4 directories: logs, indata, tmpdata, and outdata.</li>
<li>Edit stage_purple_plot.sh to use the correct sim id.</li>
<li>Run stage_purple_plot.sh.</li>
<li>Create the directory purple_plot_output.</li>
<li>Run bbp/utils/batch/combine_gof_gen.py -d purple_plot -o purple_plot_output -c gp to produce a purple plot, combining the GoF results from all stations and events.</li>
<li>Run bbp/utils/batch/compare_bbp_runs.py -d purple_plot -o purple_plot_output/ -c gp to generate the bias values.</li>
</ol>

=== Multi-fault GMPEs ===

The BBP, as of v22.4, isn't set up to produce realistic GMPE estimates for multi-fault ruptures. Therefore, producing meaningful GMPE comparisons requires generating the GMPE estimates outside of the BBP and then importing them. The steps for this are detailed below:

<ol>
<li>Ask someone (like Kevin) to produce GMPE estimates at a variety of periods for the event. The station list and event information must be provided.</li>
<li>This information is delivered in a series of CSV files, one per period. Convert the CSV files into .ri50 files.</li>
<li>Copy the .ri50 files into a working directory.</li>
<li>To get the observation files in *.rd50 format, you can either copy them in from a previous run, or you can generate them. To generate them, run:
<pre>$> mkdir $BBP_DATA_DIR/logs/<arbitrary run ID>
$> $BBP_DIR/comps/obs_seismograms.py $BBP_VAL_DIR/path/to/site_list.stl $BBP_VAL_DIR/path/to/observations/Acc acc_peer "" <arbitrary run ID>
$> cp -r $BBP_DATA_DIR/<arbitrary run id>/obs_seis_<event> .</pre></li>
<li>Next, run gmpe_gof.py to generate the comparison metrics:
<pre>$GMSVTOOLKIT_DIR/stats/gmpe_gof.py --gmpe-dir . --comp-dir obs_seis_<event> --station-list /path/to/site_list.stl --src-file /path/to/first/segment/src_file.src --comp-label <label> --gmpe-group nga-west2</pre></li>
<li>Finally, plot the results using plot_gmpe_gof.py:
</pre>$GMSVTOOLKIT_DIR/plots/plot_gmpe_gof.py --input-dir . --output-dir . --comp-label <label> --gmpe-group nga-west2 --station-list /path/to/site_list.stl</pre></li>
</ol>

== Northridge ==

=== 1D BBP comparisons ===

We calculated 64 realizations for Northridge for these [[Media:northridge_stations.kml | 38 stations]].

Some of the differences between the 1D BBP and 3D CyberShake results can be attributed to differences in site response, which is calculated based on the reference velocity ('vref') and the vs30 of the site. A spreadsheet with vref and Vs30 for both the BBP and CyberShake is available [[File:BBP_v_CyberShake_Northridge_vs30.xls | here.]]

==== V1 (2/14/22) ====

Initially, we used vref=500 for both the high-frequency and low-frequency site response. However, this is incorrect; vref for the low-frequency should vary depending on the properties of the 3D velocity mesh.

==== V2 (2/25/22) ====

We continued to use vref=500 for the high-frequency site response. For the low-frequency site response, we are now using the same vref we used in Study 15.12:

vref_LF_eff = Vs30 * [ VsD5H / Vs5H ]

Vs30 = 30 / Sum (1/(Vs sampled from [0.5,29.5] in 1 meter increments))

H = grid spacing

Vs5H = travel time averaged Vs, computed from the CVM in 1 meter increments down to a depth of 5*H

VsD5H = discrete travel time averaged Vs computed from 3D velocity mesh used in the SGT calculation over the upper 5 grid points

So, for H=100m Vs5H would be:

Vs500 = 500 / ( Sum ( 1 / Vs sampled from [0.5,499.5] in 1 meter increments ))

And then VsD5H is given by:

VsD500 = 5/{ 0.5/Vs(Z=0m) + 1/Vs(Z=100m) + 1/Vs(Z=200m) + 1/Vs(Z=300m) + 1/Vs(Z=400m) + 0.5/Vs(Z=500m) }

Below are the ts_process plots for a subset of 10 stations, comparing the 3D CyberShake with 1D BBP results.

{|
! Site !! TS Process plot
|-
! SCE || [[File:ts_process_SCE_src0_2_25.png|thumb|400px]]
|-
! SYL || [[File:ts_process_SYL_src0_2_25.png|thumb|400px]]
|-
! LDM || [[File:ts_process_LDM_src0_2_25.png|thumb|400px]]
|-
! PAC || [[File:ts_process_PAC_src0_2_25.png|thumb|400px]]
|-
! PKC || [[File:ts_process_PKC_src0_2_25.png|thumb|400px]]
|-
! SPV || [[File:ts_process_SPV_src0_2_25.png|thumb|400px]]
|-
! WON || [[File:ts_process_WON_src0_2_25.png|thumb|400px]]
|-
! KAT || [[File:ts_process_KAT_src0_2_25.png|thumb|400px]]
|-
! RO3 || [[File:ts_process_RO3_src0_2_25.png|thumb|400px]]
|-
! ANA || [[File:ts_process_ANA_src0_2_25.png|thumb|400px]]
|}

==== V3 (3/2/22) ====

Next, we recalculated the CyberShake results for 10 sites, using the BBP vs30 values for both the low-frequency and high-frequency elements. Note that the vref low-frequency value for CyberShake is still being derived from the velocity model.

{|
! Site !! TS Process plot
|-
! SCE || [[File:ts_process_SCE_src0_3_2.png|thumb|400px]]
|-
! SYL || [[File:ts_process_SYL_src0_3_2.png|thumb|400px]]
|-
! LDM || [[File:ts_process_LDM_src0_3_2.png|thumb|400px]]
|-
! PAC || [[File:ts_process_PAC_src0_3_2.png|thumb|400px]]
|-
! PKC || [[File:ts_process_PKC_src0_3_2.png|thumb|400px]]
|-
! SPV || [[File:ts_process_SPV_src0_3_2.png|thumb|400px]]
|-
! WON || [[File:ts_process_WON_src0_3_2.png|thumb|400px]]
|-
! KAT || [[File:ts_process_KAT_src0_3_2.png|thumb|400px]]
|-
! RO3 || [[File:ts_process_RO3_src0_3_2.png|thumb|400px]]
|-
! ANA || [[File:ts_process_ANA_src0_3_2.png|thumb|400px]]
|}



=== Observational Comparisons ===

We calculated goodness-of-fit results for both Broadband CyberShake and the BBP against observations for Northridge, using the 64 realizations and 38 stations.

TS process plots comparing the 3 results are available here: [https://g-c662a6.a78b8.36fe.data.globus.org/cybershake/Broadband_CyberShake/validation/Northridge/ts_process_nr.tgz v1 ts process plots].

==== Broadband Platform ====

{|
! Overall GoF !! GoF, best realization (#7) !! GoF, worse realization (#15)
|-
| [[File:BBP-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-GoF-NR-real7.png|thumb|400px]]
| [[File:BBP-GoF-NR-real15.png|thumb|400px]]
|}

==== CyberShake v4_8 ====

{|
! Overall GoF !! GoF, best realization (#53) !! GoF, worse realization (#54)
|-
| [[File:CyberShake-GoF-NR-4_8_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_real53.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_real54.png|thumb|400px]]
|}

==== Broadband Platform, updated frequency bands ====

We realized that our GoF comparisons were run using hard-coded frequency bands of [0.05, 50] Hz. This was correct when doing CS-to-BBP comparisons, but not correct when using observations. We updated the frequency bands and reran the GoF.

{|
! Overall GoF !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25) !! GoF, best CS realization (#40) !! GoF, worst CS realization (#37)
|-
| [[File:BBP-freqbands-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real47.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real25.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real40.png|thumb|400px]]
| [[File:BBP-freqbands-GoF-NR-real37.png|thumb|400px]]
|}

==== CyberShake v4_8, updated frequency bands ====

As above, reran the GoF.

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#37) !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25)
|-
| [[File:CyberShake-GoF-NR-4_8_freqbands_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real37.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real47.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_8_freqbands_real25.png|thumb|400px]]
|}

==== CyberShake v4_28, BBP Vs30 ====

We recalculated the CyberShake GoF results, using the BBP Vs30 values.

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51) !! GoF, best BBP realization (#47) !! GoF, worst BBP realization (#25)
|-
| [[File:CyberShake-GoF-NR-4_28_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real51.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real47.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-4_28_real25.png|thumb|400px]]
|}

==== BBP, FAS ====

{|
| [[File:CyberShake-GoF-NR-BBP_FAS.png|thumb|400px]]
|}

==== CyberShake v4_7, FAS ====

{|
| [[File:CyberShake-GoF-NR-4_7_FAS.png|thumb|400px]]
|}

=== Observational Comparisons, BBP v22.4 ===

We repeated the comparisons, using BBP v22.4 for both the 1D BBP and 3D CyberShake calculations.

==== BBP ====

{|
! Overall GoF !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51) !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51)
|-
| [[File:BBP-v22.4-GoF-NR-combined.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real6.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real51.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real40.png|thumb|400px]]
| [[File:BBP-v22.4-GoF-NR-real51.png|thumb|400px]]
|}

==== CyberShake ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#51) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-9_1_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real51.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-9_1_real51.png|thumb|400px]]
|}

=== CyberShake, updated velocity model ===

{|
! Overall GoF !! GoF, best CS realization (#33) !! GoF, worst CS realization (#51)
|-
| [[File:CyberShake-GoF-NR-11_28_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-11_28_real33.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-11_28_real51.png|thumb|400px]]
|}

=== Study 22.12 configuration ===

These are the validation results using the Study 22.12 configuration, with risetime_coef=2.3 and hb_high_v6.1.1.

==== BBP (12/9/22) ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#9) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-12_9_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real9.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_9_real51.png|thumb|400px]]
|}

==== CyberShake (12/11/22) ====

{|
! Overall GoF !! GoF, best CS realization (#40) !! GoF, worst CS realization (#9) !! GoF, best BBP realization (#6) !! GoF, worst BBP realization (#51)
|-
| [[File:CyberShake-GoF-NR-12_11_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real40.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real9.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real6.png|thumb|400px]]
| [[File:CyberShake-GoF-NR-12_11_real51.png|thumb|400px]]
|}

==== SRF plots ====

{|
! Best CS realization (#40)
| [[File:NR_v14_02_1_40.png|thumb|400px]]
|-
! Best BBP realization (#6)
| [[File:NR_v14_02_1_6.png|thumb|400px]]
|}

== Chino Hills ==

For our second event, we selected Chino Hills.

=== Sites ===

The BBP validation event for Chino Hills has 40 stations. A KML file with the stations is available [[:File:chino_hills_stations.kml|here]].

=== BBP ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#35) !! GoF, worst CS realization (#34)
|-
| [[File:BBP-GoF-CH-combined.png|thumb|400px]]
| [[File:BBP-GoF-CH-real24.png|thumb|400px]]
| [[File:BBP-GoF-CH-real35.png|thumb|400px]]
| [[File:BBP-GoF-CH-real34.png|thumb|400px]]
|}

{| Overall FAS
| [[File:BBP-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-GoF-CH-real35.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP Vs30 values ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-BBPvs30-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-BBPvs30-GoF-CH-real35.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-BBPvs30-GoF-CH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4 ===

{|
! Overall GoF !! GoF, best realization (#24) !! GoF, worst realization (#34) !! GoF, best BBP realization (#24) !! GoF, worst BBP realization (#35)
|-
| [[File:CS-9_2-GoF-CH-combined.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real34.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real24.png|thumb|400px]]
| [[File:CS-9_2-GoF-CH-real35.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4, BBP Vs30 ===

== Whittier ==

Our third event is Whittier.

=== Sites ===

The BBP validation event for Whittier has 39 stations, one of which is a duplicate. A KML file with the 38 stations used in these tests is available [[:File:whittier_stations.kml|here]].

=== BBP ===

{|
! Overall GoF !! GoF, best realization (#15) !! GoF, worst realization (#7) !! GoF, best CS realization (#62) !! GoF, worst CS realization (#3)
|-
| [[File:BBP-GoF-WH-combined.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052315.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052307.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052362.png|thumb|400px]]
| [[File:BBP-GoF-WH-2022052303.png|thumb|400px]]
|}

{| Overall FAS
| [[File:BBP-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake ===

These results are incomplete, without 2 of the stations (VER and PMN).

{|
! Overall GoF !! GoF, best realization (#62) !! GoF, worst realization (#3) !! GoF, best BBP realization (#15) !! GoF, worst BBP realization (#7)
|-
| [[File:CS-GoF-WH-combined.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061362.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061303.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061315.png|thumb|400px]]
| [[File:CS-GoF-WH-2022061307.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP Vs30 values ===

{|
! Overall GoF !! GoF, best realization !! GoF, worst realization !! GoF, best BBP realization !! GoF, worst BBP realization
|-
| [[File:CS-BBPvs30-GoF-WH-combined.png|thumb|400px]]
|}

{| Overall FAS
| [[File:CS-BBPvs30-GoF-WH-FAS-combined.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4 ===

{|
! Overall GoF !! GoF, best realization (#62) !! GoF, worst realization (#39) !! GoF, best BBP realization (#15) !! GoF, worst BBP realization (#7)
|-
| [[File:CS-9_4-GoF-WH-combined.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real62.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real39.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real15.png|thumb|400px]]
| [[File:CS-9_4-GoF-WH-real7.png|thumb|400px]]
|}

=== CyberShake, BBP v22.4, BBP Vs30 values ===

== Landers ==

=== Single fault realization ===

==== CS (2/15/22) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, best BBP realization (#13)
|-
| [[File:CS-GoF-Landers-2_15_combined.png|thumb|400px]]
| [[File:CS-GoF-Landers-2_15_real6.png|thumb|400px]]
| [[File:CS-GoF-Landers-2_15_real13.png|thumb|400px]]
|}

==== BBP (12/10/22) ====

{|
! Overall GoF !! GoF, best CS realization (#9) !! GoF, best BBP realization (#13)
|-
| [[File:BBP-GoF-Landers-12_10_combined.png|thumb|400px]]
| [[File:BBP-GoF-Landers-12_10_real9.png|thumb|400px]]
| [[File:BBP-GoF-Landers-12_10_real13.png|thumb|400px]]
|}

==== CyberShake (Study 22.12 configuration, 12/12/22) ====

{|
! Overall GoF !! GoF, best CS realization (#9) !! GoF, worst CS realization (#22) !! GoF, best BBP realization (#13) !! GoF, worst BBP realization (#22)
|-
| [[File:CS-GoF-Landers-12_12_combined.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real9.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real22.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real13.png|thumb|400px]]
| [[File:CS-GoF-Landers-12_12_real22.png|thumb|400px]]
|}

==== GMPE ====

{|
| [[File:GMPE-GoF-Landers-single.png|thumb|400px]]
|}

=== Multi fault realization ===

==== BBP ====

{|
! Overall GoF !! GoF, best CS realization (#54) !! GoF, worst CS realization (#11) !! GoF, best BBP realization (#55) !! GoF, worst BBP realization (#11)
|-
| [[File:BBP-GoF-Landers-9_22_combined.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real54.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real11.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real55.png|thumb|400px]]
| [[File:BBP-GoF-Landers-9_22_real11.png|thumb|400px]]
|}

==== CyberShake ====

{|
! Overall GoF !! GoF, best CS realization (#54) !! GoF, worst CS realization (#11) !! GoF, best BBP realization (#55) !! GoF, worst BBP realization (#11)
|-
| [[File:CyberShake-GoF-Landers-8_25_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real54.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real11.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real55.png|thumb|400px]]
| [[File:CyberShake-GoF-Landers-8_25_real11.png|thumb|400px]]
|}

==== GMPE ====

Fabio notes that the GMPE codes we have on the BBP are not set up for multi-segment events, and probably only use the first segment in the rupture.

{|
| [[File:GMPE-GoF-Landers-multi.png|thumb|400px]]
|}

== Ridgecrest ==

We looked at both the smaller Ridgecrest (7/4/19, M6.4) 'A' event and the larger (7/6/19, M7.1) multi-fault 'C' event.

=== Ridgecrest A ===

==== BBP (6/19/23) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, worst CS realization (#16) !! GoF, best BBP realization (#27) !! GoF, worst BBP realization (#16)
|-
| [[File:BBP-GoF-RidgecrestA-6_19_combined.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real06.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real16.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real27.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestA-6_19_real16.png|thumb|400px]]
|}

==== CyberShake (9/29/23) ====

{|
! Overall GoF !! GoF, best CS realization (#6) !! GoF, worst CS realization (#16) !! GoF, best BBP realization (#27) !! GoF, worst BBP realization (#16)
|-
| [[File:CyberShake-GoF-RidgecrestA-9_29_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real06.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real16.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real27.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestA-9_29_real16.png|thumb|400px]]
|}

==== GMPE ====

{|
| [[File:GMPE-GoF-RidgecrestA.png|thumb|400px]]
|}

=== Ridgecrest C multi-fault ===

==== BBP (10/18/23) ====

{|
! Overall GoF !! GoF, best CS realization (#32) !! GoF, best BBP realization (#49)
|-
| [[File:BBP-GoF-RidgecrestC-10_18_combined.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestC-10_18_real32.png|thumb|400px]]
| [[File:BBP-GoF-RidgecrestC-10_18_real49.png|thumb|400px]]
|}

==== CyberShake (11/29/23) ====

{|
! Overall GoF !! GoF, best CS realization (#32) !! GoF, best BBP realization (#49)
|-
| [[File:CyberShake-GoF-RidgecrestC-11_29_combined.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestC-11_29_real32.png|thumb|400px]]
| [[File:CyberShake-GoF-RidgecrestC-11_29_real49.png|thumb|400px]]
|}

== North Palm Springs ==

CyberShake Study Database Archiving

2025-09-07T04:39:47Z

Scottcal: Added --skip-add-drop-table option so preexisting tables aren't dropped.

== SQLite Archiving ==

The following procedure should be used when we want to archive a study to SQLite which is either in the production or data access database to disk, to free up room in the database.

First, dump the old database contents into a new directory by running the following commands.

Note that if you don't want to lock the tables, you can replace '--lock-all-tables' with '--single-transaction=TRUE' in the following commands.

<ol>
<li>Determine the Study ID you want to archive, from looking at the Studies table in the DB:</li>
select * from Studies;
<li>Dump the PeakAmplitudes, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Run_ID in (select R.Run_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake PeakAmplitudes > peak_amps.sql
<li>Dump Hazard_Datasets, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake Hazard_Datasets > hazard_datasets.sql
<li>Dump Hazard_Curves, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Hazard_Dataset_ID in (select D.Hazard_Dataset_ID from Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curves > hazard_curves.sql
<li>Dump Hazard_Curve_Points, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Hazard_Curve_ID in (select C.Hazard_Curve_ID from Hazard_Curves C, Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curve_Points > hazard_curve_points.sql
<li>Dump CyberShake_Runs, using:</li>
mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake CyberShake_Runs > runs.sql
<li>You now need the rest of the input tables. They used to be pretty small, but now they're up to ~70GB with indices. As of the completion of Study 22.12, here are their approximate sizes (in the DB, not as dump files):
{| border="1"
! Table !! Size (GB)
|-
| AR_Hazard_Curve_Points || 44.6
|-
| CyberShake_Site_Ruptures || 10.3
|-
| Ruptures || 2.3
|-
| Rupture_Variations || 2.6
|-
| AR_Hazard_Curves || 1.4
|-
| Other tables || 0.5
|}
You can either:
<ul>
<li>Dump all of the input tables -- they are small enough that we don't mind capturing data which wasn't directly used in this study.</li>
mysqldump --skip-add-drop-table -u cybershk -p CyberShake AR_Hazard_Curve_Points AR_Hazard_Curves AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Ruptures CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Points Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rupture_Variations Ruptures Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
<li>Dump only the sections of the large input tables that you need. Note that the Points table isn't used anymore, so don't bother to dump it.
<ol>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'AR_Hazard_Curve_ID in (select distinct C.AR_Hazard_Curve_ID from AR_Hazard_Curves C where C.AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) )' CyberShake AR_Hazard_Curve_Points > ar_hazard_curve_points.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'CS_Site_ID in (select R.Site_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake CyberShake_Site_Ruptures > cs_site_ruptures.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Ruptures > ruptures.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where '(Rup_Var_Scenario_ID, ERF_ID) in (select R.Rup_Var_Scenario_ID, R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Rupture_Variations > rupture_variations.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p --where 'AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID)' CyberShake AR_Hazard_Curves > ar_hazard_curves.sql</li>
<li>mysqldump --lock-all-tables --skip-add-drop-table -u cybershk -p CyberShake AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
</ol>
</ul>

</ol>

Next, convert the SQL dumps into SQLite format using mysql2sqlite:

#For each of the dump files, run:
mysql2sqlite <SQL dump file> > <SQLite dump file>
Example: ./mysql2sqlite peak_amps.sql > peak_amps.sqlite
For large tables this may take an hour or two.

Create a SQLite database and import the tables. Use sqlite3 3.7.11 or later, or there will be an error reading the dump files. If you get errors about too many entries, upgrade to a more recent version and try again.
<ol>
<li>Create a database for this study:</li>
sqlite3 <study name>
<li>For each dump file, run the following command:</li>
.read <path/to/dump/file.sqlite>
</ol>

Run a few queries on the original table on the database, and on the sqlite files to check that the count is the same.
<ol>
<li>Check the number of PeakAmplitudes:</li>
select count(*) from PeakAmplitudes P, CyberShake_Runs R where R.Study_ID=<study_id> and P.Run_ID=R.Run_ID;
<li>Check the number of rupture variations for each site:</li>
select count(*) from CyberShake_Runs R, CyberShake_Site_Ruptures SR, Rupture_Variations V where R.Site_ID=SR.CS_Site_ID and SR.Source_ID=V.Source_ID and SR.Rupture_ID=V.Rupture_ID and R.ERF_ID=V.ERF_ID and R.ERF_ID=SR.ERF_ID and V.Rup_Var_Scenario_ID=R.Rup_Var_Scenario_ID and R.Study_ID=<study id>;
</ol>

Create index on Run_ID and IM_Type_ID in PeakAmplitudes table to speed up access.
<ol>
<li>Copy over the original version to a new file.</li>
<li>Set the SQLITE_TMPDIR variable to point to a filesystem with lots of free space.</li>
<li>Using a current version of sqlite3, open the new database file and run:</li>
CREATE INDEX "idx_PeakAmplitudes_Run_ID_IM_Type_ID" ON "PeakAmplitudes" (`Run_ID`, `IM_Type_ID`);
</ol>

Move the files to the archive location on project.
<ol>
<li>Tar up the sqlite files:</li>
tar czvf <study_name>.tgz *.sqlite
<li>SFTP the tgz file to the study sqlite archive location on project at CARC (/project/scec_608/cybershake/results/sqlite_studies/<study name>), using hpc-transfer1.</li>
<li>Extract the database to /project/scec_608/cybershake/results/sqlite_studies/<study_name> .</li>
tar xzvf sqlite_dumps/<study_name>.tgz <study_name>.sqlite
</ol>

== Move study to from production DB to data access DB ==

CyberShake Study Database Archiving

2025-09-02T21:39:29Z

Scottcal: /* SQLite Archiving */

== SQLite Archiving ==

The following procedure should be used when we want to archive a study to SQLite which is either in the production or data access database to disk, to free up room in the database.

First, dump the old database contents into a new directory by running the following commands.

Note that if you don't want to lock the tables, you can replace '--lock-all-tables' with '--single-transaction=TRUE' in the following commands.

<ol>
<li>Determine the Study ID you want to archive, from looking at the Studies table in the DB:</li>
select * from Studies;
<li>Dump the PeakAmplitudes, using:</li>
mysqldump --lock-all-tables -u cybershk -p --where 'Run_ID in (select R.Run_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake PeakAmplitudes > peak_amps.sql
<li>Dump Hazard_Datasets, using:</li>
mysqldump --lock-all-tables -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake Hazard_Datasets > hazard_datasets.sql
<li>Dump Hazard_Curves, using:</li>
mysqldump --lock-all-tables -u cybershk -p --where 'Hazard_Dataset_ID in (select D.Hazard_Dataset_ID from Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curves > hazard_curves.sql
<li>Dump Hazard_Curve_Points, using:</li>
mysqldump --lock-all-tables -u cybershk -p --where 'Hazard_Curve_ID in (select C.Hazard_Curve_ID from Hazard_Curves C, Hazard_Datasets D where D.Study_ID=<study id to archive>)' CyberShake Hazard_Curve_Points > hazard_curve_points.sql
<li>Dump CyberShake_Runs, using:</li>
mysqldump --lock-all-tables -u cybershk -p --where 'Study_ID=<study id to archive>' CyberShake CyberShake_Runs > runs.sql
<li>You now need the rest of the input tables. They used to be pretty small, but now they're up to ~70GB with indices. As of the completion of Study 22.12, here are their approximate sizes (in the DB, not as dump files):
{| border="1"
! Table !! Size (GB)
|-
| AR_Hazard_Curve_Points || 44.6
|-
| CyberShake_Site_Ruptures || 10.3
|-
| Ruptures || 2.3
|-
| Rupture_Variations || 2.6
|-
| AR_Hazard_Curves || 1.4
|-
| Other tables || 0.5
|}
You can either:
<ul>
<li>Dump all of the input tables -- they are small enough that we don't mind capturing data which wasn't directly used in this study.</li>
mysqldump -u cybershk -p CyberShake AR_Hazard_Curve_Points AR_Hazard_Curves AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Ruptures CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Points Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rupture_Variations Ruptures Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
<li>Dump only the sections of the large input tables that you need. Note that the Points table isn't used anymore, so don't bother to dump it.
<ol>
<li>mysqldump --lock-all-tables -u cybershk -p --where 'AR_Hazard_Curve_ID in (select distinct C.AR_Hazard_Curve_ID from AR_Hazard_Curves C where C.AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) )' CyberShake AR_Hazard_Curve_Points > ar_hazard_curve_points.sql</li>
<li>mysqldump --lock-all-tables -u cybershk -p --where 'CS_Site_ID in (select R.Site_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>)' CyberShake CyberShake_Site_Ruptures > cs_site_ruptures.sql</li>
<li>mysqldump --lock-all-tables -u cybershk -p --where 'ERF_ID in (select R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Ruptures > ruptures.sql</li>
<li>mysqldump --lock-all-tables -u cybershk -p --where '(Rup_Var_Scenario_ID, ERF_ID) in (select R.Rup_Var_Scenario_ID, R.ERF_ID from CyberShake_Runs R where R.Study_ID=<study id to archive>) and (Source_ID, Rupture_ID) in (select distinct SR.Source_ID, SR.Rupture_ID from CyberShake_Site_Ruptures SR, CyberShake_Runs R where SR.CS_Site_ID=R.Site_ID and SR.ERF_ID=R.ERF_ID and R.Study_ID=<study id to archive>)' CyberShake Rupture_Variations > rupture_variations.sql</li>
<li>mysqldump --lock-all-tables -u cybershk -p --where 'AR_Hazard_Dataset_ID in (select distinct D.AR_Hazard_Dataset_ID from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat>=(select distinct D.Min_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lat<=(select distinct D.Max_Lat from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon>=(select distinct D.Min_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID) and Lon<=(select distinct D.Max_Lon from AR_Hazard_Datasets D, CyberShake_Runs R where R.Study_ID=<study id to archive> and D.Time_Span_ID=1 and D.Prob_Model_ID=1 and D.ERF_ID=R.ERF_ID and D.Velocity_Model_ID=R.Velocity_Model_ID)' CyberShake AR_Hazard_Curves > ar_hazard_curves.sql</li>
<li>mysqldump --lock-all-tables -u cybershk -p CyberShake AR_Hazard_Datasets Atten_Rel_Metadata Atten_Rels CyberShake_Site_Regions CyberShake_Site_Types CyberShake_Sites ERF_IDs ERF_Metadata ERF_Probability_Models IM_Types Rupture_Variation_Probability_Modifier Rupture_Variation_Scenario_IDs Rupture_Variation_Scenario_Metadata Rup_Var_Seeds SGT_Variation_IDs SGT_Variation_Metadata Studies Time_Spans Velocity_Models > input_tables.sql</li>
</ol>
</ul>

</ol>

Next, convert the SQL dumps into SQLite format using mysql2sqlite:

#For each of the dump files, run:
mysql2sqlite <SQL dump file> > <SQLite dump file>
Example: ./mysql2sqlite peak_amps.sql > peak_amps.sqlite
For large tables this may take an hour or two.

Create a SQLite database and import the tables. Use sqlite3 3.7.11 or later, or there will be an error reading the dump files. If you get errors about too many entries, upgrade to a more recent version and try again.
<ol>
<li>Create a database for this study:</li>
sqlite3 <study name>
<li>For each dump file, run the following command:</li>
.read <path/to/dump/file.sqlite>
</ol>

Run a few queries on the original table on the database, and on the sqlite files to check that the count is the same.
<ol>
<li>Check the number of PeakAmplitudes:</li>
select count(*) from PeakAmplitudes P, CyberShake_Runs R where R.Study_ID=<study_id> and P.Run_ID=R.Run_ID;
<li>Check the number of rupture variations for each site:</li>
select count(*) from CyberShake_Runs R, CyberShake_Site_Ruptures SR, Rupture_Variations V where R.Site_ID=SR.CS_Site_ID and SR.Source_ID=V.Source_ID and SR.Rupture_ID=V.Rupture_ID and R.ERF_ID=V.ERF_ID and R.ERF_ID=SR.ERF_ID and V.Rup_Var_Scenario_ID=R.Rup_Var_Scenario_ID and R.Study_ID=<study id>;
</ol>

Create index on Run_ID and IM_Type_ID in PeakAmplitudes table to speed up access.
<ol>
<li>Copy over the original version to a new file.</li>
<li>Set the SQLITE_TMPDIR variable to point to a filesystem with lots of free space.</li>
<li>Using a current version of sqlite3, open the new database file and run:</li>
CREATE INDEX "idx_PeakAmplitudes_Run_ID_IM_Type_ID" ON "PeakAmplitudes" (`Run_ID`, `IM_Type_ID`);
</ol>

Move the files to the archive location on project.
<ol>
<li>Tar up the sqlite files:</li>
tar czvf <study_name>.tgz *.sqlite
<li>SFTP the tgz file to the study sqlite archive location on project at CARC (/project/scec_608/cybershake/results/sqlite_studies/<study name>), using hpc-transfer1.</li>
<li>Extract the database to /project/scec_608/cybershake/results/sqlite_studies/<study_name> .</li>
tar xzvf sqlite_dumps/<study_name>.tgz <study_name>.sqlite
</ol>

== Move study to from production DB to data access DB ==