Running LazypipeX on Roihu

LazypipeX is available to users with a CSC account as a preinstalled dataset module on , the supercomputer of the . The dataset carries the pipeline, its toolchain and all reference databases — nothing needs to be installed!

For questions related to LazypipeX and LazypipeX Roihu module please contact our research group: .

For questions related to Roihu projects, disk quotas and other technical matter please contact the CSC service desk:

On this page:

To analyse more than a handful of samples, continue to .

1. Load the module

The dataset directory is not on the module search path by default, so two commands are needed — module load lazypipe alone will report that the module does not exist:

module use /dataset/project_2020379/modulefiles
module load lazypipe/3.1

Do not load other modules on top of lazypipe. The modulefile already loads every tool the pipeline needs, at the versions the reference databases were built against. A separately loaded diamond or blast module will shadow the shipped build and can produce results that do not match the installed databases.

2. Run one sample

The dataset project supplies files only: it has no compute allocation and no writable space. Run jobs from your own CSC project, bill them to that project, and write the output there. The examples use the placeholders $project_id and $project_name; replace them with a real CSC project id (of the form project_1234567) and a working directory name that means something to you.

PROJDIR=/scratch/$project_id/$project_name
mkdir -p $PROJDIR && cd $PROJDIR

lazypipe.pl -p main --hostgen Homo_sapiens --anns vi.chain3.env -1 reads_R1.fastq.gz -s mysample -r $PROJDIR/results -v

• -p main runs the routine chain of steps: preprocessing, background filtering, assembly, read realignment, annotation, reporting, statistics, packing and cleanup.
• -1 gives the R1 file; R2 is inferred from its name. Name it explicitly with -2, or pass --se for single-end data.
• --hostgen names one or more background genomes, comma-separated — typically the host genome, plus human to catch handling and library-preparation contamination (--hostgen Homo_sapiens,Mus_musculus). See lazypipe.pl --filters.
• --anns selects an . vi.chain3.env is the recommended default.
• -s sets the sample name; results go to <res-dir>/<sample>/.
• Always pass -r. The shipped configuration sets res: "$data/results"; if -r is omitted and $data is unset, the results path expands to a relative path under your current directory.

Do not run this on a login node: even a small library will exceed the login-node limits. Use srun on the interactive partition for a test, and sbatch for real work ().

3. Working files and local disk

While a sample is being analysed the pipeline writes a large amount of intermediate data: filtered reads, the assembly and its indices, alignments, and raw annotation output. These working files go to fast disk on the compute node itself ($TMPDIR) and are deleted automatically when the job ends. Allow roughly ten times the size of your compressed FASTQ input — a 4 GB pair of fastq.gz files needs some 40 GB of working space.

How much of that space you get is decided by the partition you submit to, not by the pipeline:

• small partition, samples up to ~2 GB of compressed reads — the default is enough; nothing to change.
• medium or large partition, samples of any size — again nothing to change. These partitions give each job a whole node, and with it far more local disk.
• small partition, samples above ~2 GB — the default space is shared with the other jobs on the node and will run out. Write the working files to your own scratch instead, with --tmpdir <path>. This works, but scratch is slower than node-local disk.

A run that exhausts its working space stops part-way with no space left on device.

4. Choosing a partition, cores and memory

Because medium and large allocate and bill a whole node regardless of what you ask for, request the whole node: a run at 24 cores on medium costs the same as a run at 64 cores and leaves 40 cores idle.

Suggested starting point for a paired-end Illumina library of 2–8 GB gzipped reads with an .env strategy:

#SBATCH --partition=medium
#SBATCH --cpus-per-task=64
#SBATCH --mem=240G
#SBATCH --time=12:00:00

Memory is the value to watch: the measured runs below peaked at 53–73 GB of resident memory, so 240 GB on a whole node is ample, while 80 GB is about the practical floor. Reserve at least 4 GB of RAM per core.

5. Measured runtimes on Roihu

The figures below come from the first large production run of the Roihu dataset module (August 2026): paired-end Illumina libraries screened for viruses with --anns vi.chain3.env, with background filtered against the host genome and human.

If you run many samples as an array job, limit how many of them run at the same time. Each running sample holds roughly 20 GB of working files until its clean step, so 47 samples starting at once would need close to 1 TB of scratch space between them.

The limit is the number after the % sign in the array range:

#SBATCH --array=1-47%25 # 47 samples in total, at most 25 running at any moment

6. A batch job

#!/bin/bash -l
#SBATCH --job-name=lazypipe
#SBATCH --account=$project_id
#SBATCH --partition=medium
#SBATCH --time=12:00:00
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=64
#SBATCH --mem=240G
#SBATCH --output=logs/%x.%j.log
#SBATCH --error=logs/%x.%j.log

module use /dataset/project_2020379/modulefiles
module load lazypipe/3.1

PROJDIR=/scratch/$project_id/$project_name
cd $PROJDIR
mkdir -p logs results

lazypipe.pl -p main --hostgen Homo_sapiens --anns vi.chain3.env -1 reads_R1.fastq.gz -s mysample -t $SLURM_CPUS_PER_TASK -r $PROJDIR/results --logs $PROJDIR/logs -v

Bill the job to your own project. A dataset project has no compute allocation and cannot be billed.

Useful Slurm commands:

7. Inspecting what is installed

lazypipe.pl --databases # installed reference databases, with versions
lazypipe.pl --filters # host and background genomes available to --hostgen
lazypipe.pl -h # all command-line options
module help lazypipe # a condensed version of this page

The dataset currently ships core_nt (the NT replacement), RefSeq 236, UniRef100 with both BLAST and DIAMOND indices, Pfam and NeoRdRp viral HMM profiles, NCBI and ICTV VMR taxonomies, and background genomes for more than twenty host species. Every result directory records the database versions used, so a run can be reproduced later.

Databases are pre-installed and read-only. Do not run install_db.pl — it has nothing to do here and cannot write to the dataset.

8. Configuration

lazypipe.pl looks for ./config.yaml in the current directory and falls back to the shipped $LAZYPIPE_INSTALL_DIR/config.yaml; --config <file> overrides both. The shipped configuration already points at the databases in the dataset project, so copy it locally only when you need to change parameters:

cp /dataset/project_2020379/LazypipeX/config.yaml .

9. Troubleshooting

For anything else, including questions about interpreting results, write to . Include your job id and the log of the sample that failed.