New pipeline: nf-core/nanotax

[dialvarezs]

Pipeline title/name

nanotax

Keywords

nanopore, 16s, 18s, its, metabarcoding

What is it about?

A metabarcoding pipeline specially designed for Oxford Nanopore data.

Please provide a schematic diagram of the proposed pipeline

I confirm my proposed pipeline will follow nf-core guidelines. Most importantly, my pipeline will:

• be built with Nextflow.
• pass nf-core lint tests and use standardized parameters.
• be community-owned and developed within the nf-core organization.
• open source under the MIT license with proper credits and acknowledgments.
• have a descriptive, all lowercase, and without punctuation name.
• use the nf-core pipeline template and predominantly use official nf-core modules.
• focus on a specific data/analysis type with appropriate scope.
• have properly maintained documentation.
• be bundled using versioned Docker/Singularity containers.

Why do we need a new pipeline?

Metabarcoding analysis in nf-core is handled by ampliseq, which supports short-read technologies and PacBio sequencing. However, Oxford Nanopore makes traditional ASV and OTU clustering approaches difficult to use given its higher error rate.

Typically, Nanopore reads are assigned taxonomy directly instead of being grouped into molecular units, which is the approach taken by the official EPI2ME workflow. There are also specialized tools like EMU that use an expectation-maximization algorithm to generate more accurate abundance profiles.

This use case is not completely covered in nf-core currently. It could be difficult to add this feature to ampliseq because it relies heavily on ASV/OTU formation, but we can develop and share subworkflows where this is applicable (post-analysis mainly).

Who would be interested?

Researchers analyzing the composition of microbial samples sequenced with Oxford Nanopore, which keeps getting more popular given its low entry barrier and ease of use.

What has been done so far

We have a initial version for 16S using MMseqs that we use internally in our lab.
Currently, we are refactoring it in subworkflows to have a more modular design and make easy to add support for other amplicons (18S, ITS) and other classification tools. We also have been porting local modules to nf-core in this process.

URL to existing work (if applicable)

https://github.com/catg-umag/nanotax

Are there any similar existing nf-core pipelines?

ampliseq

[nf-core-bot]

Approval status: ✅ Approved

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
✅ Approved (Core)	@mashehu, @jfy133
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[d4straub]

The difference to ampliseq conceptually seems to me that ampliseq usually reconstructs sequences while that proposal seems to skip sequence reconstruction and rushes directly to abundance tables. But even that doesnt hold up entirely, because the multiple region analysis also goes straight to abundance tables already.
Edit: EMU however was proposed for ampliseq and I sort of used the same line of thought to question its addition: nf-core/ampliseq#741 (I am open to it though, but nobody took action until now to add nanopore analysis to ampliseq)

[dialvarezs]

Hi @d4straub! Conceptually yes, Nanopore metabarcoding usually performs taxonomic assignment directly on full-length raw reads. There have been some clustering-based approaches (for example https://github.com/genomicsITER/NanoCLUST), but in practice ONT workflows have always focused on direct read assignment. The reference implementation from ONT itself used BLAST initially, and now Minimap2 or Kraken. In that sense, the logic is actually closer to what taxprofiler does than to ampliseq.

Ampliseq is a very comprehensive pipeline that is fundamentally designed around ASV and OTU inference using DADA2 and QIIME2. And as you point out (and as noted in the referenced issue), the Nanopore approach does not use any of that and moves directly from QC to taxonomic assignment and then to downstream analysis.

Integrating a full ONT workflow into ampliseq would require adding several ONT-specific tools and steps for QC, filtering and classification. This would result in two largely independent analysis paths that only converge at the final stage. These ONT-specific components would not be used by Illumina data, and the ASV-focused components would not be used for ONT data either. Ampliseq is already a fairly complex pipeline, and this would make it even more.

In addition, our planned implementation includes the option to start directly from raw POD5 files with Dorado basecalling if the user has a GPU available. This is completely outside the intended scope of ampliseq.

For these reasons, we believe that this should be an independent pipeline. ampliseq would remain as the ASV-based workflow for Illumina, PacBio and IonTorrent data, while nanotax would focus specifically on Nanopore metabarcoding and its common practices as they evolve.

We 100% agree with the nf-core principle of avoiding unnecessary duplication. In that sense, our plan is to design the functionality around reusable subworkflows (when possible), and share them with ampliseq and/or other pipelines . This will help to keep the maintenance simple.

And of course, this is our take in how this should be approached, but if we reach the conclusion that the best path within nf-core is to integrate this into ampliseq, we are open to that and willing to put in the effort required to make it happen.

[d4straub]

I agree with the closeness of the proposed pipeline to taxprofiler and most other points. I also agree that ampliseq is complex enough as it currently is, actually.

I personally miss from your plot very much the primer removal and associated quality control and would therefore only reluctantly use it as proposed (but maybe I just failed to see it, and its just one to two additional steps).

But if there is a feasible way or an interest from whatever side to integrate ASV/OTU-& Nanopore-based analysis into ampliseq then I hope this new proposed pipeline will not be a blocker. For example, DADA2 is sometimes applied and was in the past already demonstrated to work with Nanopore data and with increasing Nanopore data quality that might come into focus more.

[dialvarezs]

I personally miss from your plot very much the primer removal and associated quality control and would therefore only reluctantly use it as proposed (but maybe I just failed to see it, and its just one to two additional steps).

In Nanopore, primer removal is currently handled by Dorado itself. It works right out of the box for ONT-provided kits but it also support custom primer trimming.

But if there is a feasible way or an interest from whatever side to integrate ASV/OTU-& Nanopore-based analysis into ampliseq then I hope this new proposed pipeline will not be a blocker.

I agree. If, in the future, strategies that allow ONT data to be processed effectively with what ampliseq already provides proliferates, essentially treating it as a lower-quality PacBio dataset, then it would make sense to support that within ampliseq. But if ONT-specific approaches continue to develop separately (for example, tools like Emu), then it would be more appropriate to keep that functionality within this new pipeline.

[JoseEspinosa]

So then @d4straub your suggestion will be to accept this pipeline or integrate the proposed functionality under the umbrella of ampliseq?

[d4straub]

I merely discussed it as someone interested and invested in amplicon sequencing analysis (mostly) with ampliseq. The conclusions are not up to me.

[samuell]

Edit: EMU however was proposed for ampliseq and I sort of used the same line of thought to question its addition: nf-core/ampliseq#741 (I am open to it though, but nobody took action until now to add nanopore analysis to ampliseq)

For the record: We (@sofstam, @AnnaNoren and I) at Karolinska were considering adding Emu to Ampliseq, but it turned out to become just a completely separate track in the pipeline, with almost no reuse of code, and so we decided to continue developing the pipeline already in development within Genomic Medicine Sweden, which is now in a good shape for 16S, and ailable here: https://github.com/genomic-medicine-sweden/TRANA

(It has gone through a couple of renamings, from gms_16S -> TACO -> TRANA).

Our work on TRANA has included updating it to a pretty recent nf-core template, and improving the adherence to the template, although it is not currently planned to become an official nf-core project.

There might be possibilities for re-use or cooperation here though. I.e. we are interested in ITS as a next step.

[sofstam]

Being a little biased here and after the discussions of integrating emu to ampliseq, I think it would be nice to see this ONT-functionality as a seperate pipeline.

[mashehu]

I guess this is fine then. looking forward to the logo 😁

/approve

[jfy133]

Based on the comments on @samuell and @sofstam on the difficulty of integrating other tools (I guess?:) into ampliseq, I will give an approval on their behalf. It would be good however to see if there can be some collaboration with the TRANA team (I dunno if there would be interested to make an official nf-core project @samuell ?, even if not planned)

/approve