quality-filter is... making all my reverse reads forward reads?

[neocallimastix]

This is my first time using QIIME2, and somewhere along the line the program has stopped recognizing that my paired-end reads are in fact paired-end.

I imported my raw paired-end reads, already demultiplexed, as artifacts of type "SampleData[PairedEndSequencesWithQuality]" and of format "CasavaOneEightSingleLanePerSampleDirFmt", containing both a forward read set and a reverse read set. Running "demux summarize" on them tells me that QIIME2 recognizes this, and the quality scores look great. A+, no notes.

So I go to quality-filter the reads using "quality-filter q-score". All parameters are left as default. I only have the --i-demux, --o-filtered-sequences, and --o-filter-stats. When I run "demux summarize" on them, apparently QIIME2 has not only not done much filtering at all but also forgotten that half of the reads are reverse reads.

"But wait", you may ask, "why did neocallimastix do quality filtering without trimming the reads first?!"

Well, I actually tried that first before taking the route above because I'm going to employ q2-dada2 post-filtering, and I went the route of trimming my reads in cutadapt trim-pairs before I decided it may actually just be easier trim adapters/truncate my reads for quality in q2-dada2. I employed the following for my 16S and ITS2 reads, respectively (all unnecessary other code that doesn't need to be fixed is removed from this sample):

16S:

qiime cutadapt trim-paired --i-demultiplexed-sequences $16Spath/rawFASTQs/$16Ssample-fastq-gz.qza --p-cores 4 --p-match-read-wildcards --p-adapter-f $forwardadapter --p-adapter-r $reverseadapter --o-trimmed-sequences $16Spath/trimmedFASTQs/$16Ssample-fastq-gz-trimmed.qza --verbose   

ITS2:

qiime itsxpress trim-pair-output-unmerged --i-per-sample-sequences $ITS2path/rawFASTQs/$ITS2sample-fastq-gz.qza --p-region 'ITS2' --p-threads 4 --p-cluster-id 1.0 --o-trimmed $ITS2path/trimmedFASTQs/$ITS2sample-fastq-gz-trimmed.qza --verbose

and got this, which implies to me that it's quality-filter that's giving me the forward-reverse misreading problems (but also, is it *not trimming my reads?!):

Why is quality-filter mistaking my reverse reads for forward reads and what can I do to make it not do that?

Thanks!

[jwdebelius (Justine Debelius)]

Hi @neocallimastix,

There are two issues here, the second a symptom of the first.

@neocallimastix

Well, I actually tried that first before taking the route above because I'm going to employ q2-dada2 post-filtering, and I went the route of trimming my reads in cutadapt trim-pairs before I decided it may actually just be easier trim adapters/truncate my reads for quality in q2-dada2

DADA2 assumes yoru reads are demultiplexed and have the primers/adapters removed. It does the quality filtering internally and IIRC pre-quality filtering can affect your ability to properly train the denoising algorithm.

So, you should probably drop this initial QC filtering step and just run through DADA2.

I think the assumption behind this is that if you're joining reads for deblur or OTU clustering, you've joined your reads in vsearch and then passed them into the quality filtering, meaning that only forward reads are processed.

Best,
Justine