Hi! I have a fairly basic question, but could not find the answer by searching in here, so maybe someone can help me out with this. We have a large Lexogen QuantSeq 3' end RNAseq dataset of a human cohort based on blood samples. Due to the size, the dataset was sequenced on an Illumina NovaSeq in two batches (Batch 1: 1056 samples, Batch 2: 135 samples). Independent of all downstream analytical batch handling considerations, does it make any difference whether we run all 1191 samples together in one nf-core rnaseq run on our HPC cluster or use two separate runs? Would it be advised to use different pipeline runs for different sequencing batches? Most steps in the pipeline seem to run within-sample processing operations, but we'd like to make sure that we are not overlooking any steps that may make use e.g. of any between-sample information or distribution estimates - apart from overall statistics, of course. I'd appreciate any feedback, thanks!

Nearly every step in nf-core/rnaseq is strictly per-sample: trimming, alignment/pseudoalignment, rRNA removal, quantification, featureCounts, RSeQC, dupRadar, Preseq, etc. None of these borrow information across samples, so a sample gives identical output whether it's processed in a 1191-sample run or alone. Reference indices are built once from the genome/annotation, not your data, so no batch-dependent effect there either. The exception is the DESeq2 exploratory QC (PCA plot, sample correlation heatmap). It computes size factors and variance-stabilization across whichever samples are in that run, so a combined run's PCA plot will differ numerically from two separate runs' plots, even for the same samples. But that's QC output only, it doesn't feed into the counts you'd take forward for differential expression. So for actual quantification outputs, splitting by batch is equivalent to one combined run. You just lose a single combined PCA/heatmap view across all 1191 samples, aggregate stats aside. Given your cohort size, also worth a look:

--skip_quantification_merge

. It makes the pipeline fully sample-centric, outputs under

<outdir>/<sample_id>/

, and skips the merge steps that load every sample into one process (tximport, SummarizedExperiment, RSEM merge, merged MultiQC), so memory doesn't scale with cohort size. Works well either way, one run or two. One caveat:

*gene_counts_length_scaled.tsv

isn't published in this mode since per-sample lengthScaledTPM isn't cross-sample comparable, so you'd re-run tximport across all quant.sf files afterwards if you need it.

Perfect, thanks a lot for the quick and comprehensive clarification!