# 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](resources.md). Below is an example slurm submission script. ```bash #!/bin/bash # #SBATCH --job-name= #SBATCH -A #SBATCH -N #SBATCH -t #SBATCH --mem-per-cpu 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= ``` Assuming this script is called `submit.sh` and it is located within an ursa project directory, it may be submitted with: ```bash 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 - Before using this approach improvements to the snakefile might include: - specify resources needed for each rule - specify job grouping so that multiple jobs may be submitted together. - . - See also for details on executing snakemake in this manner.