Workflow Engines (Snakemake, Nextflow)

From HPCwiki
Jump to navigation Jump to search

Workflow engines let you describe a multi-step analysis as a set of rules — which steps depend on which, and how to run each — and then execute the whole pipeline reproducibly, submitting the individual steps to the scheduler for you. The two most common on Anunna are Snakemake and Nextflow.

Using a workflow engine has real advantages on an HPC cluster: steps run as SLURM jobs with the right resources, only the parts that need to run are rerun, and the same pipeline can be shared and reproduced by others.

Snakemake

Snakemake describes a pipeline as a set of rules in a Snakefile. It can submit each rule's work to SLURM and manage the dependencies between steps.

Set up

Snakemake is usually installed in a conda environment. If you do not have conda/Miniforge yet, see Python. Create an environment containing Snakemake and your pipeline's dependencies:

conda create --name my-pipeline --file requirements.txt
conda activate my-pipeline
pip install snakemake-executor-plugin-slurm   # or add to requirements.txt

Giving the environment the same name as the pipeline makes it easy to find later.

SLURM profile

To let Snakemake submit jobs to SLURM, create a profile. Make a directory for it:

mkdir -p ~/.config/snakemake/my-pipeline

and create a config.yaml inside it that tells Snakemake how to submit jobs, for example:

executor: slurm
jobs: 10
software-deployment-method: conda
default-resources:
  slurm_partition: "main"      # your Anunna partition
  slurm_account: "your_account"
  runtime: 60                  # minutes
  mem_mb: 16000
  cpus_per_task: 16
# per-rule overrides:
# set-resources:
#   big_rule:
#     mem_mb: 64000
#     runtime: 240

Adjust the resources (time, memory, cores) to what your rules need.

Configure and run

Open the pipeline's own config.yaml and set the input and output paths, keeping the variable names already in the file:

OUTDIR: /path/to/output
READS_DIR: /path/to/reads/
ASSEMBLY: /path/to/assembly
PREFIX: output_name

Because pipelines can take a long time, run Snakemake inside a persistent session (screen or tmux) so it keeps running if your connection drops. First do a dry run to check what will happen:

snakemake -np

If the steps and commands look right, run the pipeline with your profile:

snakemake --profile my-pipeline

The jobs are submitted to SLURM and you can follow the progress in your terminal and with the usual tools — see Monitoring Jobs.

Nextflow

Nextflow is another widely used workflow engine, popular in bioinformatics (for example the nf-core pipelines). It describes a pipeline as a set of processes connected by data channels, and it can submit each process to SLURM just like Snakemake does.

Set up

Nextflow is available from the 2025 bucket. Loading it pulls in Java 25 as a dependency:

module load 2025
module load Nextflow/25.10.2

Check that it works:

nextflow info

If you run pipelines that use containers (all nf-core pipelines do), also load Apptainer:

module load utilities Apptainer

Keep Nextflow out of your home directory

By default Nextflow and Apptainer store their caches in $HOME. On Anunna this will fill your home quota very quickly: nf-core pipelines alone download several gigabytes of reference files and container images. Set these environment variables — for example in your ~/.bashrc — to point them at fast, large storage instead:

export NXF_HOME=/path/to/scratch/.nextflow
export NXF_APPTAINER_CACHEDIR=/path/to/scratch/.apptainer-cache
  • NXF_HOME — where Nextflow keeps its own files: downloaded pipeline code (nextflow run nf-core/... caches the pipeline here), plugins, and secrets. Never point this at $HOME.
  • NXF_APPTAINER_CACHEDIR — where container images pulled by Nextflow are stored. Images are single large files and add up fast. Never point this at $HOME.

Neither variable points to your home directory after this step — log out and back in, or source ~/.bashrc, to apply.

SLURM configuration

To make Nextflow submit jobs to SLURM, add a profile to the pipeline's nextflow.config (or to your personal $NXF_HOME/config so it applies to every pipeline you run):

profiles {
  slurm {
    workDir = '/path/to/scratch/work'  // Nextflow's working directory; use fast shared storage
    process {
      executor = 'slurm'
      queue = 'main'                   // your Anunna partition
      clusterOptions = '--account=your_account'
      cpus = 4
      memory = '16 GB'
      time = '1h'

      // per-process overrides, by process name:
      withName: BIG_STEP {
        memory = '64 GB'
        time = '4h'
      }
      // or by label, if the pipeline sets them (nf-core pipelines do):
      withLabel: process_high {
        memory = '64 GB'
        time = '4h'
      }
    }
    executor {
      queueSize = 10                   // maximum number of jobs in SLURM at once
    }
    apptainer {
      enabled = true
    }
  }
}

Adjust the resources (time, memory, cores) to what the pipeline needs.

Configure and run

nf-core pipelines take their options as command-line flags; run a pipeline with --help to list them:

nextflow run nf-core/rnaseq --help

The ones you almost always need are a sample sheet and an output directory:

--input samplesheet.csv --outdir /path/to/output

Because pipelines can take a long time, run Nextflow inside a persistent session (screen or tmux) so it keeps running if your connection drops. Then launch the pipeline with your profile:

nextflow run nf-core/rnaseq -profile slurm \
    --input samplesheet.csv --outdir /path/to/output

Each process is submitted to SLURM as its own job; follow the progress in your terminal and with the usual tools — see Monitoring Jobs.

If the run stops — a failed job, a full disk, a dropped session — fix the cause and rerun the same command with -resume. Nextflow reuses every step that already finished and only repeats what is missing:

nextflow run nf-core/rnaseq -profile slurm \
    --input samplesheet.csv --outdir /path/to/output -resume


See also