Workflow Engines (Snakemake, Nextflow): Difference between revisions
No edit summary |
|||
| Line 74: | Line 74: | ||
== Nextflow == | == Nextflow == | ||
Nextflow is another widely used workflow engine, popular in bioinformatics (for example the [https://nf-co.re/ 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 [[Environment Modules|bucket]]. Loading it pulls in Java 25 as a dependency: | |||
<syntaxhighlight lang="bash"> | |||
module load 2025 | |||
module load Nextflow/25.10.2 | |||
</syntaxhighlight> | |||
Check that it works: | |||
<syntaxhighlight lang="bash"> | |||
nextflow info | |||
</syntaxhighlight> | |||
If you run pipelines that use containers (all nf-core pipelines do), also load Apptainer: | |||
<syntaxhighlight lang="bash"> | |||
module load utilities Apptainer | |||
</syntaxhighlight> | |||
=== Keep Nextflow out of your home directory === | |||
By default Nextflow and Apptainer store their caches in <code>$HOME</code>. 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 <code>~/.bashrc</code> — to point them at fast, large storage instead: | |||
<syntaxhighlight lang="bash"> | |||
export NXF_HOME=/path/to/scratch/.nextflow | |||
export NXF_APPTAINER_CACHEDIR=/path/to/scratch/.apptainer-cache | |||
</syntaxhighlight> | |||
* <code>NXF_HOME</code> — where Nextflow keeps its own files: downloaded pipeline code (<code>nextflow run nf-core/...</code> caches the pipeline here), plugins, and secrets. Never point this at <code>$HOME</code>. | |||
* <code>NXF_APPTAINER_CACHEDIR</code> — where container images pulled by Nextflow are stored. Images are single large files and add up fast. Never point this at <code>$HOME</code>. | |||
Neither variable points to your home directory after this step — log out and back in, or <code>source ~/.bashrc</code>, to apply. | |||
=== SLURM configuration === | |||
To make Nextflow submit jobs to SLURM, add a profile to the pipeline's <code>nextflow.config</code> (or to your personal <code>$NXF_HOME/config</code> so it applies to every pipeline you run): | |||
<syntaxhighlight lang="groovy"> | |||
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 | |||
} | |||
} | |||
} | |||
</syntaxhighlight> | |||
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 <code>--help</code> to list them: | |||
<syntaxhighlight lang="bash"> | |||
nextflow run nf-core/rnaseq --help | |||
</syntaxhighlight> | |||
The ones you almost always need are a sample sheet and an output directory: | |||
<syntaxhighlight lang="bash"> | |||
--input samplesheet.csv --outdir /path/to/output | |||
</syntaxhighlight> | |||
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: | |||
<syntaxhighlight lang="bash"> | |||
nextflow run nf-core/rnaseq -profile slurm \ | |||
--input samplesheet.csv --outdir /path/to/output | |||
</syntaxhighlight> | |||
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 <code>-resume</code>. Nextflow reuses every step that already finished and only repeats what is missing: | |||
<syntaxhighlight lang="bash"> | |||
nextflow run nf-core/rnaseq -profile slurm \ | |||
--input samplesheet.csv --outdir /path/to/output -resume | |||
</syntaxhighlight> | |||
<!-- TODO: add a Nextflow section for Anunna — how to load or install Nextflow, the SLURM executor configuration (nextflow.config: process.executor = 'slurm'), and a minimal example. --> | <!-- TODO: add a Nextflow section for Anunna — how to load or install Nextflow, the SLURM executor configuration (nextflow.config: process.executor = 'slurm'), and a minimal example. --> | ||
Revision as of 16:09, 22 July 2026
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