Difference between revisions of "DirectSynth"
(Created page with 'DirectSynth is a CyberShake post-processing code authored by Scott Callaghan in early 2015. It provides an alternative to separate SGT extraction and seismogram synthesis/PSA/Ro…') |
|||
| Line 3: | Line 3: | ||
== Overview == | == Overview == | ||
| − | At a high level, DirectSynth works by reading in SGTs across a large number of processors. Another set of processors works through a list of seismogram synthesis/PSA/RotD tasks, requesting the SGTs needed for synthesis from the processor(s) which have them in memory. Since the total quantity of SGTs needed to synthesize | + | At a high level, DirectSynth works by reading in SGTs across a large number of processors. Another set of processors works through a list of seismogram synthesis/PSA/RotD tasks, requesting the SGTs needed for synthesis from the processor(s) which have them in memory. Since the total quantity of SGTs needed to synthesize a seismogram may be larger than what can fit into a single processor's memory, the requests are divided up so as not to exceed 1 GB at a time. Since multiple rupture variations will use the same SGTs, as many rupture variations as can fit into a processor's memory will be synthesized at the same time. Output files (seismograms, PSA, RotD) are sent to a single process for writing. Whenever all the rupture variations for a rupture are completed, that file is fsync()ed and the source and rupture ID are recorded in a checkpoint file. |
| + | |||
| + | == Details == | ||
| + | |||
| + | The processes in DirectSynth have 1 of 4 roles: | ||
| + | |||
| + | * Master (process rank 0). | ||
| + | *# Reads in header information, broadcasts to everyone. | ||
| + | *# Determines which SGTs go to which SGT handlers, sends to handlers. | ||
| + | *# While there is still work to do: | ||
| + | *## Gathers data from workers and writes to files | ||
| + | *## Updates checkpoint file as ruptures finish | ||
| + | |||
| + | * SGT Handlers (processes 1 - <num SGT handlers-1>) | ||
| + | |||
| + | * Task Manager (process <num SGT handlers>) | ||
| + | |||
| + | * Workers (process <num SGT handlers + 1> - end) | ||
== Communication patterns == | == Communication patterns == | ||
| + | |||
Revision as of 15:35, 21 April 2015
DirectSynth is a CyberShake post-processing code authored by Scott Callaghan in early 2015. It provides an alternative to separate SGT extraction and seismogram synthesis/PSA/RotD jobs, and requires fewer SUs and less I/O, making it a more efficient choice for CyberShake runs at frequencies at or above 1 Hz.
Contents
Overview
At a high level, DirectSynth works by reading in SGTs across a large number of processors. Another set of processors works through a list of seismogram synthesis/PSA/RotD tasks, requesting the SGTs needed for synthesis from the processor(s) which have them in memory. Since the total quantity of SGTs needed to synthesize a seismogram may be larger than what can fit into a single processor's memory, the requests are divided up so as not to exceed 1 GB at a time. Since multiple rupture variations will use the same SGTs, as many rupture variations as can fit into a processor's memory will be synthesized at the same time. Output files (seismograms, PSA, RotD) are sent to a single process for writing. Whenever all the rupture variations for a rupture are completed, that file is fsync()ed and the source and rupture ID are recorded in a checkpoint file.
Details
The processes in DirectSynth have 1 of 4 roles:
- Master (process rank 0).
- Reads in header information, broadcasts to everyone.
- Determines which SGTs go to which SGT handlers, sends to handlers.
- While there is still work to do:
- Gathers data from workers and writes to files
- Updates checkpoint file as ruptures finish
- SGT Handlers (processes 1 - <num SGT handlers-1>)
- Task Manager (process <num SGT handlers>)
- Workers (process <num SGT handlers + 1> - end)
