A wrapper is now available to run auto_submit.py and queue_monitor.py at the same time.

Basic usage

To use this wrapper use the following command:

python $gmsim/workflow/scripts/cybershake/run_cybershake.py [Path to cybershake root directory] [User name] [Config file path]

Where:

  • the path to the cybershake directory may be absolute or relative to the current directory
  • The user name is your name for submitting slurm scripts
  • The config file path points to a yaml file with a list of tasks to be performed

Config file

The config file must be in yaml format and contain a list of tasks followed by which realisations these tasks should be performed on.

The two simplest realisation descriptions are ALL and NONE which will run the task on all realisation in the current installation, or none of them, respectively.

Additionally ONCE my be given to specify that only the first realisation of each fault should have this task performed on it.

Advanced users may use a string to describe which tasks they want the tasks to apply to using an SQLite formatted string. Note that SQLite uses the % symbol for wild cards.

It is important to note that realisation categories and task names are case sensitive.

Available realisation categories:

CategoryResult
"ALL"All realisations will have the tasks performed on them
"ONCE"Only the first realisation of each fault will have the task performed on it
"NONE"The task will not be performed on any realisations. Equivalent to not including the task in the config file
"Wai%"All realisations beginning with 'Wai' will have the task performed on them
"%_REL01"All realisations that are the first in their fault group will have the task performed on them. Equivalent to using ONCE
"Wai%_REL10"The tenth realisation of every fault beginning with 'Wai' will have the task performed on it

Available tasks

The available tasks are as follows:

  • EMOD3D
  • merge_ts
  • HF
  • BB
  • IM_calculation
  • IM_plot [Currently not available]
  • rrup [Currently not available]
  • Empirical [Currently not available]
  • Verification [Currently not available]
  • clean_up
  • LF2BB
  • HF2BB

For more information on tasks see Workflow dependencies.

Note that task dependency auto adding is disabled when using the auto submit wrapper to allow wider user flexability.

Only the tasks that need to be run need to be put in the config, otherwise the NONE realisation category may be used.

Example config file

EMOD3D: ALL
HF: ALL
BB: ONCE
IM_calc: ALL
clean_up: ALL
LF2BB: "%_REL03"
HF2BB: "%_REL02"

The above config file will run:

  • EMOD3D and HF for all realisations
  • BB for all REL01 realisations
  • HF2BB for all REL02 realisations
  • LF2BB for all REL03 realisations
  • IM_calc and clean_up for all realisations as they finish

Note that BB, HF2BB and LF2BB are all possible dependencies for IM_calc.

IM_calc will be run on each realisation soon after its (HF2/HF2)BB task has completed.

Config file to run EMOD3D, HF, BB, IM_calc, clean_up

EMOD3D: ALL
HF: ALL
BB: ALL
IM_calc: ALL
clean_up: ALL

Under the hood

The wrapper script creates two threads, one for the queue monitor and one for tasks that are to be run by all realisations.

Even if no tasks are to be run on all realisations these threads are created, as the all realisation thread is responsible for updating the database from squeue.

Once these threads are started the realisation categories are taken in turn and auto_submit is run using them for one iteration of the main loop each.

When the all realisation auto submit thread has run through the main loop once for each realisation category in use without anything happening (Nothing in squeue, nothing set to running in the management db), it will automatically terminate

The queue monitor thread will be signaled to terminate and the script will end.

A visualisation of how the wrapper works is available below:



  • No labels