Hi QIIME forum!
I am currently stuck at the denoising phase, where my data has really low pair-end merging rates and lots of loss due to chimeras. I am a total newbie to metabarcoding so while I have read a lot of posts on the forum and tweaked some parameters, I would love some specific guidance on my project. I (briefly) include my pipeline in case I am missing something in the early stages that's contributing to the problem.
Background: I am running a diet study on Piping Plover fecal samples using two genes, COI (ANML primer; Jusino et al. (2019), target amplicon length 157bp) and 16S (16S degenerate primers; Deagle et al. (2008), target amplicon length 190-210bp) using Novaseq 2x150 bp. I received demultiplexed data from the sequencer (as in, every fastq.gz file was R1 or R2 of a sample) and did further 'demultiplexing' to parse each sample into COI and 16S data respectively, similar to this QIIME forum post.
My pipeline is as follows:
- Trimming primers with standalone cutadapt (no quality filters, just pulling reads with target primers into their respective files)
-
16S:
cutadapt -g ^GACGAKAAGACCCTA -G ^CGCTGTTATCCCTADRGTAACT \ --p-discard-untrimmed \ -o trim-16s/${s}.R1.fastq.gz \ -p trim-16s/${s}.R2.fastq.gz \ ./${s}.R1.fastq.gz ./${s}.R2.fastq.gz -
COI:
cutadapt -g ^GGTCAACAAATCATAAAGATATTGG -G ^GGWACTAATCAATTTCCAAATCC \ --p-discard-untrimmed \ -o trim-coi/${s}.R1.fastq.gz \ -p trim-coi/${s}.R2.fastq.gz \ ./${s}.R1.fastq.gz ./${s}.R2.fastq.gz
-
- Import to QIIME + check quality of demultiplexing
-
16S-trim-viz.qzv (337.5 KB)
-
COI-trim-viz.qzv (335.8 KB)
-
After trimming primers, my reads (from the Demultiplexed sequence length summary) are 135+130 for 16S, and 125+126 for COI, which gives an estimated overlap for paired end merging of
- 16S: 135+130 - 210 = 55
- COI: 125+126 - 157 = 94
-
- ASV Denoising with DADA (I decided not to do any truncating because I felt that the quality drops I saw in my data were scattered rather than dropping towards the ends of reads, so I opted for --p-trunc-q = 20 instead. I chose --p-min-overlap = 25 following advice here)
-
16S:16S-denoising-stats.qzv (344.5 KB)
-
qiime dada2 denoise-paired --i-demultiplexed-seqs 16S-trim.qza \ --p-trunc-len-f 0 --p-trunc-len-r 0 \ --p-trunc-q 20 --p-min-overlap 25 \ --o-representative-sequences 16S-representative-sequences.qza \ --o-table 16S-table.qza \ --o-denoising-stats 16S-denoising-stats.qza \ --o-base-transition-stats 16S-base-transition-stats.qzaCOI:COI-denoising-stats.qzv (345.9 KB)
qiime dada2 denoise-paired --i-demultiplexed-seqs .COI-trim.qza \ --p-trunc-len-f 0 --p-trunc-len-r 0 \ --p-trunc-q 20 --p-min-overlap 25 \ --o-representative-sequences COI-representative-sequences.qza \ --o-table COI-table.qza \ --o-denoising-stats COI-denoising-stats.qza \ --o-base-transition-stats COI-base-transition-stats.qza
-
I have the denoising qzv files linked, but here's screenshots of the COI one for illustrative purposes. Majority of my reads pass filtering, only to get really pinched in merging and chimera filtering. I am not sure why... I do also notice that the % retained for merged reads and chimeras are very similar, but am not sure if that means they are linked or related in any way.
I have a few ideas based on various forum posts about why this issue is occurring, but I am not sure if the issue stems from a denoising parameter or something further up the pipeline.
- I read posts like this and this that suggest remnant primers/ non-biological sequences may cause paired end reads to merge incorrectly or get flagged as chimeras, but I'm pretty sure I did the primer trimming right. I do use anchored primers (with ^ added to the g flag) during the trimming step, which I chose because the cutadapt documentation said it was useful for merging overlapping paired end reads. Do you see any issues with the way I've trimmed the data?
- Additionally, is my reasoning for choosing not to truncate reads sound? I had previously attempted denoising where 16S was truncated to --p-trunc-len-f 135 and --p-trunc-len-r 128, while COI was set to --p-trunc-len-f 125 and --p-trunc-len-r 126, but only 10-13% of reads passed filtering after that. At the time, I wasn't aware that reads shorter than the trunc-len get discarded, so I could maybe try truncating to an even shorter length like 130+120 for 16S and 110+110 for COI, but I'm not sure if that is a productive line of thinking.
- I am aware that I can set the --p-min-fold-parent-over-abundance to 8 or 16 to address some of the chimeras, but should I focus on improving the merging rates first? Does chimera removal come after merging or are they done at the same time?
Hopefully this was detailed enough without getting too long, I really appreciate those of you who gave this a read! Thanks!
> denoising 
> chimera checking 
( I will certainly rectify this for publication). Do you think seeing the raw data in QIIME will help us understand what's going on with the poor merging, or could we try something else first?
