I and my team including @Charles Plessy are ready for your pipeline review and dont know where to start as we cannot find any documentation that explains these procedures. We also are have our pipeline released recently https://nf-co.re/pairgenomealign/dev/ but awaiting review and I am wondering if its possible to assist cross reviewed each other's pipeline.

<!subteam^S016E36N7TQ> Kindly assist clarify on the possibility of this...

Hi I am facing the following error when running the scnanoseq pipeline on my computing cluster.

Caused by:
  Process `NFCORE_SCNANOSEQ:SCNANOSEQ:BLAZE (t4_shCTRL)` terminated with an error exit status (1)

Command executed:

  main.py \
      --expect-cells 10000 \
      --full-bc-whitelist /home/tmhaxs421/brannanlab/tmhaxs421/STAMP/LongRead_Nextflow_scnanoseq/reference/3M-february-2018.zip \
      --output-prefix t4_shCTRL. \
      --threads 6 \
      --kit-version 3v3 \
      $(pwd)
  
  
  tail -n +2 t4_shCTRL.putative_bc.csv > t4_shCTRL.putative_bc.no_header.csv
  
  cat t4_shCTRL.putative_bc.no_header.csv | \
      cut -f2 -d',' | \
      sort -T $(pwd) | \
      uniq -c | \
      awk '{print $2","$1}'> t4_shCTRL.bc_count.txt
  
  cat <<-END_VERSIONS > versions.yml
  "NFCORE_SCNANOSEQ:SCNANOSEQ:BLAZE":
      blaze: 2.2.0
  END_VERSIONS

Command exit status:
  1

Command output:
  [93mYou are using 3M-february-2018.zip as the full barcode whitelist. Note that the barcodes not listed in the file will never be found.[0m
  [91mError: can not find /home/tmhaxs421/brannanlab/tmhaxs421/STAMP/LongRead_Nextflow_scnanoseq/reference/3M-february-2018.zip[0m

Command error:
  INFO:    Environment variable SINGULARITYENV_TMPDIR is set, but APPTAINERENV_TMPDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_TASK_WORKDIR is set, but APPTAINERENV_NXF_TASK_WORKDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_DEBUG is set, but APPTAINERENV_NXF_DEBUG is preferred
  Matplotlib created a temporary cache directory at /tmp/matplotlib-0bvxxktx because the default path (/home/tmhaxs421/.config/matplotlib) is not a writable directory; it is highly recommended to set the MPLCONFIGDIR environment variable to a writable directory, in particular to speed up the import of Matplotlib and to better support multiprocessing.
  [93mYou are using 3M-february-2018.zip as the full barcode whitelist. Note that the barcodes not listed in the file will never be found.[0m
  [91mError: can not find /home/tmhaxs421/brannanlab/tmhaxs421/STAMP/LongRead_Nextflow_scnanoseq/reference/3M-february-2018.zip[0m
  tail: cannot open 't4_shCTRL.putative_bc.csv' for reading: No such file or directory

Work dir:
  /condo/brannanlab/tmhaxs421/STAMP/LongRead_Nextflow_scnanoseq/scripts/work/b9/bfbfff130bd36eac64bfcf82178f88

My file for the --full-bc-whitelist exists but the error mentions that it is not found. Can someone help me with troubleshooting this issue please. I will really appreciate it. Thanks in advance

Hi @mashehu, Thank you for the review! We have a couple questions back to you whenever you have a chance. We do have questions on what further steps we need to take with regards to the first release once review is completed. I know there’s also enabling Zenodo and changing default branch, but is there any other major steps we’re missing beyond that? Thanks, Austyn

Hello, I am running the scnanoseq pipeline on an HPC system and I am encountering some issues with Java heap space during FASTQC_NANOPLOT_PRE_TRIM:FASTQC step. The pipeline consistently fails with a

java.lang.OutOfMemoryError

.

ERROR ~ Error executing process > 'NFCORE_SCNANOSEQ:SCNANOSEQ:FASTQC_NANOPLOT_PRE_TRIM:FASTQC (BEB19013)'
 
Caused by:
 Process `NFCORE_SCNANOSEQ:SCNANOSEQ:FASTQC_NANOPLOT_PRE_TRIM:FASTQC (BEB19013)` terminated with an error exit status (3)
 
 
Command executed:
 
 printf "%s %s\n" BEB19013.merged.fastq.gz BEB19013.raw.gz | while read old_name new_name; do
   [ -f "${new_name}" ] || ln -s $old_name $new_name
 done
  
 fastqc \
    \
   --threads 6 \
   BEB19013.raw.gz
  
 cat <<-END_VERSIONS > versions.yml
 "NFCORE_SCNANOSEQ:SCNANOSEQ:FASTQC_NANOPLOT_PRE_TRIM:FASTQC":
   fastqc: $( fastqc --version | sed '/FastQC v/!d; s/.*v//' )
 END_VERSIONS
 
Command exit status:
 3
 
Command output:
 application/gzip
 Terminating due to java.lang.OutOfMemoryError: Java heap space
 
Command error:
 Started analysis of BEB19013.raw.gz
 Approx 5% complete for BEB19013.raw.gz
 Approx 10% complete for BEB19013.raw.gz
 Approx 15% complete for BEB19013.raw.gz
 Approx 20% complete for BEB19013.raw.gz
 Approx 25% complete for BEB19013.raw.gz
 Approx 30% complete for BEB19013.raw.gz
 Approx 35% complete for BEB19013.raw.gz
 Approx 40% complete for BEB19013.raw.gz
 Approx 45% complete for BEB19013.raw.gz
 
Work dir:
 /data/project/rizzardilab/drbhatta/long_read/scnanoseq/D13_SUP_PDD/work/7b/b6d20f015d9b46b2c8e30026d5601a
 
Tip: when you have fixed the problem you can continue the execution adding the option `-resume` to the run command line
 
 -- Check '.nextflow.log' file for details
ERROR ~ Pipeline failed. Please refer to troubleshooting docs: <https://nf-co.re/docs/usage/troubleshooting>
 
 -- Check '.nextflow.log' file for details

Command Used:

export NXF_OPTS='-Xms1g -Xmx4g
nextflow run nf-core/scnanoseq -r dev \
 --params-file params.yaml \
--split_amount: 200000 \
 -profile cheaha

While the pipeline is running, I can see two jobs submitted with the following allocations: • 36 GB of memory and 6 CPUs for one job. • 12 GB of memory and 2 CPUs for another. I have not tried using a custom config file yet. I am running this pipeline on just one sample from a PromethION flow cell, which contains 177M reads. Any insights or suggestions would be greatly appreciated! Thank you in advance for your help.

<!channel> @Austyn Trull and I are incredibly proud to have a first release of

nf-core/scnanoseq

🎉 It has been a journey to develop this pipeline, and we are happy to see it released. As a note, we will be releasing a pre-print in the near future which includes further details of this development including the comprehensive validation that we have done. Special thanks to @mashehu and @Lili Andersson-Li for their reviews and all community feedback!

Hi @Lara Ianov — cool workflow! I saw this on twitter and I was wondering if you could give some more insight/statistics on how scnanoseq compares against other workflows such as wf-single-cell or sicelore? Is it faster? Higher accuracy barcode assignment? Etc.

Hi, just a minor comment, the workflow image in the github readme is not readable in darkmode. White background instead of transparent should fix it. Thanks!

Hi all, has anyone here ran into caching issues running

scnanoseq

(in an HPC environment)? After multiple attempts, nothing is ever cached, so it's not just one specific process that is getting mixed. Wondering if it might be on my end. Code example:

#SBATCH stuff

export NXF_WORK="$VSC_SCRATCH/work"

nextflow run nf-core/scnanoseq \
	--input /some/path/scnanoseq/samplesheet.csv \
	--outdir /some/path/scnanoseq/results \
	--fasta /some/path/fasta/genome.fa \
	--gtf /some/path//genes/genes.gtf \
	--whitelist /some/path//cellranger_arc_rna.737K-arc-v1.txt.gz \
	--barcode_format 10X_3v3 \
	--split_amount 500000 \
	-c /some/path/scnanoseq/custom_scnanoseq.conf \
	-profile vsc_kul_uhasselt,wice,singularity \
	-resume

Hi @Austyn Trull and @Lara Ianov, During this week I would love to start having a dig at implementing the DNA-specific steps into

scnanoseq

. However, I'm not sure if either of you already had some ideas/plans in mind with how to best implement this? Particularly where to specify whether the input is going to be genomic or transcriptomic data. I was thinking of two potential ways: 1. Specifying the type of data and the barcode_format only as a parameter. 2. Specifying it in the samplesheet with 1-2 extra columns (genomic/transcriptomic and barcode_format). I think the second way is nicer as it also would allow mixing of transcriptomic/genomic data (assuming reference genome would be then the same). Looking forward working with you guys! Cheers, Luuk PS: I'm also available for a meeting if that is easier!

Hi folks, thanks for releasing this exciting and wonderful pipeline! 🤩 For a cost estimation of a research proposal, I need an idea of the size of the output files and the work directory files generated when running the pipeline with 20 samples, totaling 60 TB of input file size. Is there a standard output-to-input ratio that could help me calculate this if I keep the pipeline parameters default? Regarding compute power, if I decide to use Azure Batch as the executor, which VM size would you recommend? Since completing the analysis quickly is my top priority, how many VMs would you suggest using for the run? Additionally, do you have an estimate of how long it might take with the recommended VM count and type?

Hi, I am running the pipeline for a small part of my data to test if the pipeline works for my data set. The data is from two flowcells of a PromethION for one sample. It seems to run through the analysis just fine until the final steps. I get an error message at the seurat transcript step, but it is not entirely clear to me why it fails. Thank you for your help! Best, Annbjørg Here is the error message: ERROR ~ Error executing process > ‘NFCORE_SCNANOSEQSCNANOSEQSEURAT_TRANSCRIPT (GIST-T1-670)’ Caused by: Process

NFCORE_SCNANOSEQ:SCNANOSEQ:SEURAT_TRANSCRIPT (GIST-T1-670)

terminated with an error exit status (137) Command executed: seurat_qc.R \ \ -i GIST-T1-670.transcript_counts.tsv \ -s GIST-T1-670.dedup.sorted.flagstat \ -d GIST-T1-670 \ -r GIST-T1-670 cat <<-END_VERSIONS > versions.yml “NFCORE_SCNANOSEQSCNANOSEQSEURAT_TRANSCRIPT”: r-base: $(echo $(R --version 2>&1) | sed ‘s/^.*R version //; s/ .*$//’) r-seurat: $(Rscript -e “library(Seurat); cat(as.character(packageVersion(‘Seurat’)))“) END_VERSIONS Command exit status: 137 Command output: (empty) Command error: Attaching SeuratObject .command.sh: line 7: 32 Killed seurat_qc.R -i GIST-T1-670.transcript_counts.tsv -s GIST-T1-670.dedup.sorted.flagstat -d GIST-T1-670 -r GIST-T1-670 Work dir: /media/datastore/Leonardo_GIST/nf-core-test/work/0f/9d817f383e251ec682110bd1f7c8bb Tip: you can try to figure out what’s wrong by changing to the process work dir and showing the script file named

.command.sh

-- Check ‘.nextflow.log’ file for details ERROR ~ Pipeline failed. Please refer to troubleshooting docs: https://nf-co.re/docs/usage/troubleshooting -- Check ‘.nextflow.log’ file for details -[nf-core/scnanoseq] Pipeline completed with errors-

Hey everyone, I have been working with single cell long read data for a while now and came across your pipeline. Love the idea of a reproducible pipeline. I was wondering if there is a plan to implement 10X_5v3 as barcode option or can you also input custom barcode/umi length? They only made the UMIs 2 bp longer and use a new whitelist, so the changes are quite small. Cheers, Jonas

<!channel> FYI v.1.1.0 of nf-core/scnanoseq was just released. Among other changes, a key enhancement was the addition of the workflow needed for

oarfish

quantification (and the ability to now run either one of the 2 currently available quantifiers or both noting that oarfish is faster than IsoQuant if this suits your needs for downstream quantification). https://github.com/nf-core/scnanoseq/releases/tag/1.1.0

<!channel>: the pre-print for scnanoseq was released today: https://www.biorxiv.org/content/10.1101/2025.04.08.647887v1 Sending it here since we mentioned this a while back. The validation and benchmarks are in the supplementary (still part of the main doc). We structured it this way with a target in mind for a journal. We hope that this is a good complementary resource about the pipeline.

Hi folks! Looks like there was an error in your

.nf-core-config.yml

file that was preventing the automated template sync from working. I just merged the fix by @mashehu and re-ran the sync workflow and it seems to now be working. As a result you have a shiny new PR to update your pipeline to the latest nf-core template ✨ 🙂 https://github.com/nf-core/scnanoseq/pull/69

Hi everyone. I hope this is ok to ask here! I’m trying to run the pipeline on a fairly large dataset and I’m having a bit of trouble. I’ve subsetted the data down from approx. 80 million reads to 6 million, and the pipeline is still taking a long time (around 20 hours). Does this seem normal? I’ve updated the config file to try and increase the memory and time allowed for some tasks. When I tried with the full dataset the pigz uncompress step would always run out of time. Thanks so much for any help with this. Currently I am using the following resources (on the Dardel HPC in Stockholm) on an 11GB gzipped FASTQ file: • 256GB RAM • 80 CPUs (can’t control this, upper limit set by RAM requested) • 20 hours

process
{
    withName: '.*:.*FASTQC.*'
    {
       cpus = 80
       memory = '200.GB'
    }
}
 
process
{
    withName: '.*:BLAZE'
    {
       cpus = 80
       memory = '200.GB'
    }
}
 
process
{
    withName: '.*:TAG_BARCODES'
    {
       cpus = 80
       memory = '200.GB'
    }
}
 
process
{
    withName: '.*:SAMTOOLS_SORT'
    {
       cpus = 80
       memory = '200.GB'
    }
}

process
{
    withName: '.*:MINIMAP2_ALIGN'
    {
       cpus = 80
       memory = '200.GB'
    }
}
 
process
{
    withName: '.*:ISOQUANT'
    {
       cpus = 80
       memory = '200.GB'
    }
}

process
{
    withName: '.*:PIGZ_UNCOMPRESS'
    {
       cpus = 80
       time = '15.h'
       memory = '200.GB'
    }
}

<!channel>: We just released v1.2.0 of nf-core/scnanoseq. This release includes a number of bug fixes and enhancements, including upgrading BLAZE to allow the pipeline to support the new 10X 3' v4 and 10X 5' v3 kits and outputting all files produced by IsoQuant to the output directory. https://github.com/nf-core/scnanoseq/releases/tag/1.2.0

Hello everyone and thank you developers for the amazing tool! I am encountering an issue where I am losing majority of the reads at the barcode correction step. Has anyone encountered the problem before? Sounds to me like a barcode sequence issue. I would greatly appreciate any pointers! 🙂

Hi everyone, I just have a quick question. In the docs it says the barcode tag in the BAMs is 'CR' but in the tag_barcodes script I can see the corrected barcode tag is 'CB'. So should I be using the CB tag for any downstream analyses? Thanks

<!channel>: We released v 1.2.1 today. This release contains a fix for

-resume

. Thanks to @Luuk Harbers for the contributions towards this fix! https://github.com/nf-core/scnanoseq/releases/tag/1.2.1

<!channel>: just a note that the peer-reviewed version of scnanoseq’s article is now available in Oxford Bioinformatics: https://academic.oup.com/bioinformatics/article/41/9/btaf487/8247965?searchresult=1&amp;login=true Please use this citation moving forward, instead of the pre-print. We will be sure to update the citation in the nf-core website and scnanoseq’s repositories very soon. But wanted to at least start by sharing that here.

Hi everyone. I'm not sure if this might be the right channel for this, but I am having an issue with resuming a scnanoseq pipeline run. When I initially tried to resume the pipeline (using the same command as my initial run but with

-resume

added), the pipeline failed due to inability to acquire lock. I then manually deleted the LOCK file and resumed the pipeline again, which worked this time, but instead of resuming from the last step that failed, it is re-doing some of the earlier step as it was unable to find the cache for those? The initial run of the pipeline failed after 36 hours so I would ideally not want to re-do the computation again if I can resume just from the last failed step. Is there more information available on how to resume a scnanoseq pipeline run? Thanks!

Hi everyone. I have a question regarding the BLAZE barcode detection step as this step is taking a very long time for me and are causing my jobs to fail due to exceeding the time limit in SLURM. According to the pipeline summary, the BLAZE step is meant to be just for extracting the list of 'present' barcode in the sample, with the barcode extraction and barcode correction done at subsequent steps on the nextflow pipeline. However, the current BLAZE setup involves running the demultiplexing (assign reads to cell) step, which is quite time consuming (my job failed at this part after running for 6.5hrs for this part alone) and also wasteful as I don't believe this demultiplexed FASTQ file is being used in any of the downstream steps? Would it be possible to disable the BLAZE demultiplexing step so that we can make this step runs faster (it will save at least 8+ hours of runtime for my current sample)? I am also happy to submit a pull request to disable BLAZE demultiplexing as well if this step can actually be skipped/disabled.

Hi (again) everyone. I am facing a space issue when running scnanoseq pipeline. I am currently trying to run scnanoseq on 3 samples (totalling to 380 GB of fastq.gz file) and my current nextflow work directory has consumed about 7.5TB so far (without any of the 3 samples finishing unfortunately due it running out of disk space). For context, I am running each sample on separate nextflow runs, so there are some duplications that can be avoided (e.g. genome indexes) though I believe this does not significantly contribute to the issue. When checking nextflow

work

folder, I noticed that the main culprit taking up this space are the uncompressed FASTQ files. I am also using splitting when processing my samples, which further exacerbates the issue as I have multiples of uncompressed, split, concatenated 'plain' FASTQ files, which is taking up a lot of space. I've been going through the mermaid diagram and the workflow nf file to try and understand which steps requires uncompressed FASTQ files and if I understand correctly, I believe Nanofilt is the reason for the decompression step as it require plain FASTQ input, with the remaining steps - Post trim QC and BLAZE - being able to handle both compressed and uncompressed FASTQ file (I know barcode extraction currently only support uncompressed file, but the script should be able to easily be modified to support compressed FASTQ file). Is it possible at all to keep the FASTQ files always compressed when on disk instead of having uncompressed FASTQ files? I understand that Nanofilt works on uncompressed input only, but the Nanofilt mentioned it can work with piping in the uncompressed fastq file and piping out to a gzip stream. (I also noticed that nanofilt is now deprecated in favour of chopper according to their github?) Alternatively, do you have suggestions on how I can minimise disk usage while also keeping the run-time of the pipeline manageable? Should I disable the splitting parameter entirely?

Hello! I am rerunning the release megatests at the moment to make sure all pipelines have it displayed. The

test_full

profile fails for me with:

.command.sh: line 3: /usr/local/bin/samtools: Argument list too long

Could someone take a look please? https://cloud.seqera.io/orgs/nf-core/workspaces/AWSmegatests/watch/1BObgMVfLfxc4t/v2/logs

Hi @Lara Ianov, I am looking to work on issue #75 and just joined the hackathon. I wanted to run a quick test of the scnanoseq pipeline and need sample fastq files that is known to work with the pipeline. Is there a location you can point me to get a few fastq files to test the pipeline before I start working on the BLAZE issue

Hi there! I also plan to contribute to the scnanoseq project as a part of the hackathon. Could you please let me know which issues are not assigned and need more investigation? Thanks!

Hi all, I'm working on adding Parabricks GPU accelerated minimap2 to the scnanoseq pipeline this hackathon. I'll also be adding some subworkflow and pipeline level testing since I don't see any already in the repo.

Hi all <!channel>, V 1.3.0 is finally out. We have had some of these changes in dev for quite a while, but was just now able to push forward with the release. We should also now be strict syntax compliant. Please see <github.com/nf-core/…/1.3.0> for details. I do want to give special thanks to Nick Youngblut for the initial work that reduces some of the space/storage reqs. Also, the authors of IsoQuant have worked hard in improving its scalability, and thus anyone using this workflow can get through IsoQuant faster with much less cpus (we did forget to update the docs with our new recommendation but will do it in the next release 😅 ; but 6-10 is usually sufficient for the speed gain).