Difference between revisions of "DirectSynth"

From SCECpedia
Jump to navigationJump to search
(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.

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).
    1. Reads in header information, broadcasts to everyone.
    2. Determines which SGTs go to which SGT handlers, sends to handlers.
    3. While there is still work to do:
      1. Gathers data from workers and writes to files
      2. 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

Improvement over previous post-processing

Limitations