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:
Category | Result |
---|---|
"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: