Running Ursa on a slurm cluster

Ursa may be run on a slurm cluster in one of two ways. First, ursa may be run within a single job submission. Second, ursa may be run by running snakemake on the login node (with cluster administrator approval). For most use cases the former option should be more than sufficient.

Single job submission

This is the typical approach for running ursa on a slurm cluster. Ursa will run a workflow for a specific fire within a single job. The number of nodes and total run time may be estimated based on the typical resource usage. Below is an example slurm submission script.

#!/bin/bash
#
#SBATCH --job-name=<job name>
#SBATCH -A <account>
#SBATCH -N <number of nodes>
#SBATCH -t <walltime in DD-HH:MM:SS>
#SBATCH --mem-per-cpu <memory>

module switch PrgEnv-cray PrgEnv-gnu
source activate ursa-env

snakemake -s workflow/Snakefile \
  --use-conda \
  --rerun-incomplete \
  --cores 'all' \
  --nolock \
  --benchmark-extended \
  -T 3 \
  --resources mem_mb=<total memory available>

Assuming this script is called submit.sh and it is located within an ursa project directory, it may be submitted with:

sbatch submit.sh

Snakemake on the login node

Alternatively, snakemake may be executed directly on the login node and run in the background. Snakemake will then submit each rule of the workflow as an individual job.

At present, ursa is not optimized for this approach and it has not been tested. The purpose of this user guide section is to document notes should this approach be needed in the future.

Notes