Chimera removal dilemma in 16S V3–V4: necessary when using Kraken2/Bracken?

Question

[Christopher]

Hi everyone, I would like to know how you usually deal with chimeras in 16S data, given that Kraken2 does not explicitly remove them (and, as far as I understand, it might actually handle them relatively well).

Here’s the dilemma I’m having with my colleagues: should we remove chimeras or not? Personally, I think it might not be strictly necessary because Kraken2 can classify them, but my colleagues argue that chimera removal is still required.

The problem is that if I remove chimeras, I need to work with ASVs (via DADA2), but then I can’t directly use Bracken afterwards for abundance re-estimation. This makes the pipeline inconsistent for relative abundance estimates.

My current workflow is basically: cutadapt > bbduk > bowtie2 > qiime2 > dada2 > kraken2 > krona > (bracken > krona ?)

Do you think chimera removal is still necessary in this case? How do you usually handle this when combining ASV pipelines with Kraken2/Bracken?

[GenoMax]

cutadapt > bbduk > bowtie2 > qiime2 > dada2 > kraken2 > krona

Curious as to why you have cutadapt and bbduk. bbduk should be able to do everything that cutadapt can (or vice versa). In the same way bowtie2 (not sure why you have it there) could be easily replaced by bbmap. Flipping back and forth between programs sounds like more trouble.

[Christopher]

You are right. I initially decided to keep Cutadapt because I feel more confident using it for primer removal, and it is the tool most commonly found in QIIME2-based pipelines. Regarding the rest, I will follow your advice: I’ll remove Cutadapt and use the BBMap suite to handle adapter/quality trimming and host decontamination instead. Thanks a lot for the feedback!

Answer 1

[Kevin Blighe]

Chimera removal remains essential in 16S rRNA sequencing pipelines, even when using Kraken2 for classification. Chimeras arise as PCR artifacts and can lead to incorrect taxonomic assignments or inflated diversity estimates. Kraken2 classifies sequences based on k-mer matches, but it does not explicitly detect or remove chimeras. A chimeric sequence may match multiple taxa, resulting in assignment to the lowest common ancestor or misclassification, which compromises accuracy. Studies on 16S data processing emphasize that tools like DADA2 effectively identify and eliminate chimeras during ASV generation, improving downstream reliability.

In your workflow (cutadapt > bbduk > bowtie2 > qiime2 > dada2 > kraken2 > krona > bracken?), retaining DADA2 for chimera removal is advisable. The concern about inconsistency with Bracken stems from ASVs being unique denoised sequences rather than raw reads. However, you can adapt the pipeline: after DADA2 produces an ASV table and representative sequences, classify the representative sequences with Kraken2 using the --report option to generate a report file. Then, run Bracken on this report for abundance re-estimation, adjusting for read lengths typical in 16S data (e.g., 250-500 bp). This maintains consistency by using ASV counts for relative abundances.

If you skip chimera removal, you risk artifacts dominating low-abundance taxa. In my experience with similar metagenomic analyses, integrating DADA2 upstream of Kraken2/Bracken yields robust results without significant loss in abundance estimation. For example, process as follows:

qiime dada2 denoise-paired \
  --i-demultiplexed-seqs demux.qza \
  --p-trunc-len-f 240 \
  --p-trunc-len-r 200 \
  --o-table table.qza \
  --o-representative-sequences rep-seqs.qza \
  --o-denoising-stats stats.qza

Then classify rep-seqs.qza with Kraken2 against a 16S database like SILVA.

The comment suggesting BBMap consolidation is valid for simplification, but it does not address chimeras directly.

Kevin