Adding to CyberShake

Below we outline the steps required to add new kinds of input data to CyberShake.

New ERF

To add a new ERF, the database needs to know about it, the rupture files have to be registered in the RC so Pegasus can symlink them, and the right XML file needs to be used in creating curves. Here are detailed instructions:

Database modifications

1. A new ERF ID should be added to the ERF_IDs table of the CyberShake database.
2. An entry for the Rupture Surface Resolution (either the grid spacing, in km, or the element area, in km^2) must be added to the ERF_Metadata table for the new ERF ID, as this is required.
3. A list of ruptures (or rupture variations) with magnitudes and probabilities must be created externally, and added to the Ruptures table (and Rupture_Variations, if variations are created).
4. The CyberShake_Site_Ruptures table must be populated for each site we plan to compute curves for with the new ERF, so CyberShake knows which ruptures to include.
5. The Rupture_Variations table must be populated (ideally including hypocenter locations). This can either be done by using a rupture generator to create and count rupture variations, or the ERF which already supplies rupture variations, such as RSQSim-generated ERFs. Note that Rupture Variation Scenario ID 8 is used for rupture variations which come from the ERF directly, rather than being generated.

Stage ruptures

A physical copy of all the ruptures of interest must be staged on the remote clusters we plan to calculate curves on. Follow the steps

1. Copy the ruptures (and rupture variations, if they exist) to the remote cluster, in the <CyberShake root>/ruptures/Rupture_erf<ERF_ID> directory. I recommend using Globus to do the directory transfer.
2. Create a list of all the rupture files which can be used to register the ruptures into the RC. To do this, run the script in <CyberShake root>/software/RuptureCodes/utils/rupture_geom_file_list.py. A sample invocation is

   ./rupture_geom_file_list.py 49 8 gsiftp://bw-gridftp.ncsa.illinois.edu/ bluewaters /projects/sciteam/baln/CyberShake/ruptures/Ruptures_erf49/ bluewaters-e49-rv8.rls 

3. If the rupture variations are also supplied in the ERF, you need to create a list of those as well. For this, run the script <CyberShake root>/software/RuptureCodes/utils/RLSFileGen_UsingFind.pl. A sample invocation is

   ./RLSFileGen_UsingFind.pl /projects/sciteam/baln/CyberShake/ruptures/Ruptures_erf49/ gsiftp://bw-gridftp.ncsa.illinois.edu/ bluewaters 49 8 

4. Copy the list(s) back to shock, to the /home/scec-02/cybershk/runs/config directory.

Register ruptures in the replica catalog (RC)

The ruptures on the remote system must be registered in the Replica Catalog on shock.

1. For each list file created in the previous step, run

   pegasus-rc-client -i <file>

This may take some time to run.

Make changes to DAX generator

The ERF XML file picked up by the Curve Calculation and Disaggregation steps needs to be modified if it is not using the UCERF2 ERF. You will edit the DAX generator, CyberShake_DB_DAXGen.java to pick up the correct file.

1. Check out CyberShake_DB_DAXGen.java from the SVN repository (https://source.usc.edu/svn/cybershake/import/trunk/dax-generator-3/org/scec/cme/cybershake/dax3/CyberShake_DB_DAXGen.java).
2. Around line 42, add a new public static final String variable pointing to the new ERF file.
3. In the disaggregation job method (around line 370), add another clause to the if statement to select the appropriate ERF file.
4. For the 3 curve calc jobs - geometric mean (line 455), RotD50 (line 590) and RotD100 (line 520), add another clause to the if statement to select the appropriate ERF file.
5. Commit the edited file.
6. Update the file on shock (run 'svn update dax-generator' from the /home/scec-02/cybershk/runs directory). It will get compiled automatically when a workflow is created.

You should now be ready to perform CyberShake runs with the new ERF.