Table of Contents
The way that we interface with the schedulers is through a scheduler driver. The scheduler driver is an extension of the base driver and are loaded from the
batch > exec_func directory. Valid classes override the @ef_base_driver class and are in the form of
@ef_([0-9a-zA-Z])_driver the name that shows in pop_run_htb is the capture group in the expression. You may add more drivers by extending the @ef_base_driver and leaving the new class folder in the same directory. You may copy any of the drivers as a starting point.
Overriding the Base Driver
Make a constructor that returns a new object with the base class as the parent, see our included examples for how to do that
Override the base class format_scheduler method, this is the command line that is run from the submit.sh script. The inputs are consistent with the values passed from submit_line. See the file for the available fields.
Override the base class read_jobs method, this should take a string of the command line output from the scheduler and return a list of job ids in a cell array that correspond to the jobs submitted for each data file. The most basic one is only 3 lines using regular expressions.
- sqsub Since we use SHARCNET system we have included the scheduler for the legacy systems at SHARCNET, this is the sqsub wrapper.
- sbatch Most clusters are moving to using Slurm as their scheduler and therefore we have included the sbatch driver.
- current_base A special driver that does not override the base driver but runs the jobs in the current context.
- qsub_grid Implements options available for the specific qsub implementation associated with the GRID Engine. This driver is restricted to only allow certain fields that we have support for.
Note: A more general qsub is not available currently. You may need to adapt an existing scheduler driver to add qsub for your particular environment due to qsub being non-standard.
Updated/Verified by Brad Kennedy on 2017-08-08