CyberShake Study 21.12
CyberShake 21.12 is a computational study to use a new ERF with CyberShake, generated from an RSQSim catalog. We plan to calculate results for 335 sites in Southern California using the RSQSim ERF, a minimum Vs of 500 m/s, and a frequency of 1 Hz. We will use the CVM-S4.26.M01 model, and the GPU implementation of AWP-ODC-SGT enhanced from the BBP verification testing. We will begin by generating all sets of SGTs, on Summit, then post-process them on a combination of Summit and Frontera.
- 1 Status
- 2 Data Products
- 3 Science Goals
- 4 Technical Goals
- 5 ERF
- 6 Sites
- 7 Velocity Model
- 8 Verification Tests
- 9 Technical and Scientific Updates
- 10 Output Data Products
- 11 Computational and Data Estimates
- 12 Lessons Learned
- 13 Stress Test
- 14 Events During Study
- 15 Performance Metrics
- 16 Production Checklist
- 17 Presentations, Posters, and Papers
This study is complete.
It began on December 15, 2021 at 8:39:28 am PST. and finished on January 13, 2022 at 1:06:24 am PST.
In general, the Study 21.12b maps are preferred, unless showing the effect of changing RSQSim frictional parameters.
Hazard maps for this study are available here.
Comparisons of Study 21.12 and Study 15.4 are available here.
Results from Study 21.12b are available here.
Comparisons of Study 21.12b and Study 15.4 are available here.
The science goals for this study are:
- Calculate a regional CyberShake model using an alternative, RSQSim-derived ERF.
- Compare results from an RSQSim ERF to results using a UCERF2 ERF (Study 15.4).
- Quantify effects of source model non-ergodicity
- Compare spatial distribution of ground motions (including directivity) to empirical and kinematic models
The technical goals for this study are:
- Perform a study using OLCF Summit as a key compute resource.
- Evaluate the performance of the new workflow submission host, shock-carc.
- Use Globus Online for staging of output data products.
The ERF was generated from an RSQSim catalog, with the following parameters:
- 715kyr catalog (the first 65k years of events were dropped, so that every fault's first event is excluded)
- 220,927 earthquakes with M6.5+
- All events have equal probability, 1/715k
Additional details are available on the catalog's metadata page, and the catalog and input fault geometry files can be downloaded from zenodo. This is the catalog used in Milner et al., 2021, which used 0.5 Hz CyberShake simulations performed in May, 2020.
We will run a list of 335 sites, taken from the site list that was used in other Southern California studies. The order of execution will be:
- 10 sites used in Milner et al. (2021), each with top mesh point Vs at the 500 m/s floor: USC, SMCA, OSI, WSS, SBSM, LAF, s022, STNI, WNGC, PDE
- PAS hard rock site
- 20 km site grid
- 10 km site grid
- Remaining POIs, select 5km grid sites also used in Study 15.4
We will use CVM-S4.26.M01.
To better represent the near-surface layer, we will populate the velocity parameters for the surface point by querying the velocity model at a depth of (grid spacing)/4. For this study, the grid spacing is 100m, so we will query UCVM at a depth of 25m and use that value to populate the surface grid point. The rationale is that the media parameters at the surface grid point are supposed to represent the material properties for [0, 50m], and this is better represented by using the value at 25m than the value at 0m.
USC Hazard Curves
Hazard curve comparisons for site USC, between:
- ERF 58: 0.5 Hz RSQSim ERF used for Milner et al. (2021) calculations, May 2020
- ERF 61: 0.5 Hz RSQSim production ERF with the same catalog
- ERF 62: 1 Hz RSQSim production ERF with the same catalog
The first test run of ERF 61 used the wrong (older) mesh lower depth of 40 km, which is why the top right plot differs slightly from the top left. The middle left plot agrees perfectly with the top left.
|ERF 58, Original||ERF 61 w/ wrong depth|
|ERF 61 w/ corrected depth||ERF 62 (1 Hz) with old simulation parameters|
|ERF 62 (1 Hz) with proposed (new) simulation parameters||ERF 62 ccatter comparing new parameters (y) and old parameters (x)|
The first 1 Hz test run uses (bottom right above) uses the same simulation paramters as used with ERF 58 and 61, changing only the frequency. Some differences are apparent, which also persist for longer period (5s) curves:
|ERF 61, 5s Sa, 0.5 Hz, old simulation parameters||ERF 62, 5s Sa, 1 Hz, old simulation parameters|
Here are seismograms and RotD's for the largest amplitude rupture for this 0.5 Hz vs 1 Hz test:
3s Amplitude Scatter plots
These plots show that (left) ERF 61 exactly reproduces ERF 58, and (right) that there are indeed differences going from 0.5 Hz to 1 Hz:
1 Hz vs 0.5 Hz comparisons
Here is a comparison of 1 Hz runs (y axis) and 0.5 Hz runs (x axis). The top row is a recent USC run with the RSQSim ERF. The bottom row is a previous test with UCERF2-CyberShake and the WNGC site. The columns are 3s, 5s, and 10s SA, respectively, all geometric mean.
Technical and Scientific Updates
Since our last study we have made a number of scientific updates to the platform, many as a result of the BBP verification effort.
- Several bugs were found and fixed in the AWP code.
- We have switched from stress insertion to velocity insertion of the impulse when generating SGTs.
- The sponge zone used in the absorbing boundary condition was increased from 50 to 80 points.
- By default, we use a depth of h/4 when querying UCVM to populate the surface grid point.
- The padding between the nearest fault or site and the edge of the volume was increased from 30 to 50 km.
- We fixed a bug in the coordinate conversion between RWG and AWP: previously we were adding 1 to the RWG z-coordinate to produce the AWP z-coordinate, but both codes use z=1 to represent the surface and therefore no increment should be applied.
- When calculating Qs in the SGT header generation code, a default Qs of 25 was always used. This has been changed to Qs=0.05Vs.
- We have turned off the adjustment of mu and lambda.
- FP was increased from 0.5 to 1.0. <-- This was not picked up correctly by the wrapper, so 0.5 was still used.
- We modified the lambda and mu calculations in AWP to use the original media parameter values from the velocity mesh rather than the FP-modified ones when calculating strains, to be consistent with RWG.
Study 18.8 Lessons Learned
- Consider separating SGT and PP workflows in auto-submit tool to better manage the number of each, for improved reservation utilization.
- Create a read-only way to look at the CyberShake Run Manager website.
- Consider reducing levels of the workflow hierarchy, thereby reducing load on shock.
- Determine advance plan for SGTs for sites which require fewer GPUs.
- Determine advance plan for SGTs for sites which exceed memory on nodes.
- Create new velocity model ID for composite model, capturing metadata.
We modified the database to enable composite models, but for this study we are just using a single model.
- Verify all Java processes grab a reasonable amount of memory.
- Clear disk space before study begins to avoid disk contention.
- Add stress test before beginning study, for multiple sites at a time, with cleanup.
- In addition to disk space, check local inode usage.
Only 1% of the inodes are used on shock-carc; we will assume /project has sufficient inodes, as we can't check them.
- Establish clear rules and policies about reservation usage.
- If submitting to multiple reservations, make sure enough jobs are eligible to run that no reservation is starved.
We are not planning to run this study with reservations.
- If running primarily SGTs for awhile, make sure they don't get deleted due to quota policies.
We will stage the SGTs to HPSS if there is a delay in post-processing them. Summit has a 90-day purge policy, so we will have some time.
Output Data Products
File-based data products
We plan to produce the following data products which will be stored at CARC:
- Seismograms: 2-component seismograms, 8000 timesteps (400 sec) each
- PSA: X and Y spectral acceleration at 44 periods (10, 9.5, 9, 8.5, 8, 7.5, 7, 6.5, 6, 5.5, 5, 4.8, 4.6, 4.4, 4.2, 4, 3.8, 3.6, 3.4, 3.2, 3, 2.8, 2.6, 2.4, 2.2, 2, 1.66667, 1.42857, 1.25, 1.11111, 1, .66667, .5, .4, .33333, .285714, .25, .22222, .2, .16667, .142857, .125, .11111, .1 sec)
- RotD: PGV, and RotD50, the RotD50 azimuth, and RotD100 at 22 periods (1.0, 1.2, 1.4, 1.5, 1.6, 1.8, 2.0, 2.2, 2.4, 2.6, 2.8, 3.0, 3.5, 4.0, 4.4, 5.0, 5.5, 6.0, 6.5, 7.5, 8.5, 10.0 sec)
- 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%.
Database data products
We plan to store the following data products in the database:
- PSA: none
- RotD: RotD50 and RotD100 at 10, 7.5, 5, 4, 3, and 2 sec, and PGV.
- Durations: acceleration 5-75% and 5-95% for X and Y components
Computational and Data Estimates
We based these estimates by scaling from site USC (the average site has 3.8% more events and a volume 9.7% larger).
|UCVM runtime||UCVM nodes||SGT runtime||SGT nodes||Other SGT workflow jobs||Summit Total|
|USC||372 sec||80||2628 sec||67||1510 node-sec||106.5 node-hrs|
|Average (est)||408 sec||80||2883 sec||67||1550 node-sec||116.8 node-hrs|
Adding 10% overrun margin gives us an estimate of 43k node-hours for SGT calculation.
|DirectSynth runtime||DirectSynth nodes||Summit Total|
Adding 10% overrun margin gives an estimate of 4.2k node-hours for post-processing.
|Velocity mesh||SGTs size||Temp data||Output data|
|USC||243 GB||196 GB||439 GB||4.5 GB|
|Average||267 GB||203 GB||470 GB||4.7 GB|
|Total||87 TB||66 TB||153 TB||1.5 TB|
This is a total of 307 TB, which we could reach if we calculate all the SGTs first and don't delete anything. The default quota on Summit is 50 TB, so I suggest we request a quota increase to at least 300 TB so we don't need to rely on cleanup.
If we need to keep the SGTs for awhile before performing post-processing, the quota on HPSS is 100 TB, so we could store them there.
We estimate 1.5 TB in output data, which will be transferred back to CARC.
The study should use approximately 200 GB in workflow log space on /home/shock. This drive has approximately 1.7 TB free.
The PeakAmplitudes table uses approximately 100 bytes per entry.
100 bytes/entry * 17 entries/event * 76786 events/site * 335 sites = 41 GB. The drive on moment with the mysql database has 919 GB free.
The stress test began on 12/10/21 at 23:05 PST. We selected 21 sites for running both SGT and PP.
The stress test concluded on 12/12/21 at 19:41 PST.
- Workflows aren't being recognized as running by the Run Manager and are prematurely moved into an error state.
Fixed issue with correctly extracting Condor ID from run.
- Output SGTs are being registered in a local RC rather than a global one, so the PP workflow can't find them.
Modified parameters in properties file.
- Memory requirements for planning PP Synth workflow is high, so if too many run at once the Java process aborts.
Set JAVA_HEAPMAX to 10240.
- Too many Globus emails.
Auto-moved them to a different folder.
- Wrong ERF file used in curve calculations.
Fixed ERF file used in DAX generator.
Below are comparison curves between ERF 62 and ERF 58.
|Site||10 sec||5 sec||3 sec|
Events During Study
On 12/18, we discovered that some SGT jobs weren't finishing in 60 minutes. We increased the runtime to 90 minutes.
On 12/19, we reduced the runtime of the PostAWP job from 2 hours to 20 minutes, and of the NaN_Check job from 1 hour to 15 minutes.
The dtn36 node was restarted on 12/31 at 00:30 EST, but this was not discovered until 1/1 at 22:50 EST, so all workflow jobs were moved into a held state. The rvgahp daemon was restarted and jobs were released.
The dtn36 node was restarted again on 1/2 at 23:05 EST, so the rvgahp daemon was restarted on 1/3 at 22:05.
The production runs began on 12/15/21 at 8:39:28 am PST and finished on 1/13/22 at 1:06:24 am PST, for a duration of 688.4 hrs.
Before starting the stress test, the usage on Summit was 237,103 for GEO112 and 8127 for user callag.
After the stress test, the usage on Summit was 240,817 for GEO112 and 11055 for user callag. That's 139 node-hours per site.
Before starting the production runs, the usage on Summit was 244,307 for GEO112 and 11062.9 for user callag.
After the production run, the usage on Summit for user callag was 76532.8. Total usage was 65469.9 node-hours.
- Makespan: 688.4 hrs
- Uptime: 631.1 hrs (rvgahp down due to dtn36 node restarts)
Note: uptime is what's used for calculating the averages for jobs, nodes, etc.
- 313 runs in production + 22 in testing
- 116,800 unique rupture variations considered (335 sites)
- 25,723,289 seismogram pairs generated (335 sites)
- 3,884,216,639 intensity measures generated (151 per seismogram pair) (335 sites)
- 16,415 jobs executed
- Per run: 11 directory create, 13 local, 9 staging, 2 register, 14 remote
Note: we're including core-hour counts for backward comparisons, but since most of the work was done on GPUs this isn't very meaningful.
- 65469.9 node-hrs used (2749735.8 core-hrs)
- 209.2 node-hrs per site (8785.1 core-hrs). This is 80% more than our original estimate, and 50% more than the stress test showed.
- On average, 2.5 jobs running, with a max of 36
- Average of 102 nodes used, with a maximum of 2128 (89376 cores/12462 GPUs, 46.2% of Summit)
- 670 workflows run
- ? successful
- ? SGT
- ? PP
- ? failed
- ? SGT
- ? PP
- ? successful
- Total data generated: ?
- 72 TB SGTs generated (220 GB per single SGT)
- 165 TB intermediate data generated
- 1.9 TB output data (102,893,156 files)
Delay per job (using a 7-day, no-restarts cutoff: ? workflows, ? jobs) was mean: ? sec, median: ?, min: ?, max: ?, sd: ?
|Jobs per bin||?||?||?||?||?||?||?||?||?||?||?||?||?||?||?||?|
- Application parallel node speedup (node-hours divided by makespan) was ?x. (Divided by uptime: ?x)
- Application parallel workflow speedup (number of workflows times average workflow makespan divided by application makespan) was ?x. (Divided by uptime: ?x)
- The average makespan of a workflow (7-day cutoff, workflows with retries ignored, so ?/? workflows considered) was ? sec (? hrs), median: ? (? hrs), min: ?, max: ?, sd: ?
- For SGT workflows (736 workflows), mean: ? sec (? hrs), median: ? (? hrs), min: ?, max: ?, sd: ?
- For PP workflows (735 workflows), mean: ? (? hrs), median: ? (? hrs), min: ?, max: ?, sd: ?
- Workflow parallel core speedup (? workflows) was mean: ?, median: ?, min: ?, max: ?, sd: ?
- Workflow parallel node speedup (? workflows) was mean: ?, median: ?, min: ?, max: ?, sd: ?
Confirm that ERF 62 test produces results which closely match ERF 61 Restore improvements to codes since ERF 58, and rerun USC for ERF 62 Fix h/4 issue and rerun USC test. Create prioritized site list. Hold science readiness review. Add link to fault geometry on Zenodo, either on the wiki or the fault metadata page. Add copy of science readiness review slides to wiki. Generate 0.5 Hz v 1 Hz scatterplot from UCERF2 ERF run. Go through config updates as a pair to confirm they have been correctly applied.
Approach OLCF for the following requests: Quota increase to 300 TB 8 jobs ready to run 5 jobs in bin 5.
- To be able to bundle jobs, fix issue with Summit glideins.
- To run post-processing, resolve issues using GO to transfer data back to /project at CARC.
Tag code Modify job sizes and runtimes. Test auto-submit script. Prepare pending file. Create XML file describing study for web monitoring tool.
- Get usage stats for Summit.
Prepare cronjob on Summit for monitoring jobs. Activate script for monitoring x509 certificate. Modify workflows to not insert or calculate curves for PSA data. Test that workflows don't insert or calculate curves for PSA data. Modify dax-generator to use h/4 as default for surface point. Modify dax-generator to use ERF62 parameter file for generating GMPE comparison curves. Hold technical readiness review. Modify nt to 8000 (400 sec). Add calculation of PGV. Test calculation and insertion of PGV. Test SGT-only create/plan/run scripts. Test PP-only create/plan/run scripts. Fix issue with moving runs into Verified state Wrote and tested pegasus-transfer wrapper to handle GO transfers to CARC.