The first command is :
qiime demux summarize --i-data demux-joined-filtered.qza --o-cisualization numbertest.qzv
And this is the file numbertest.qzv numbertest.qzv (287.3 KB)
This file proves that there are sequences more than 560 bases.
However, when I type in the following command:
qiime deblur denoise-16S --i-demultiplexed-seqs demux-joined-filtered.qza --p-trim-length 560 --o-representative-sequences rep-seqs.qza --o-table table.qza --p-sample-stats --o-stats deblur-stats.qza
It returns:
Plugin error from deblur:
No sequences passed the filter. It is possible the trim_length (%d) may exceed the longest sequence, that..............
Could anyone tell me why this may happen?
ps: the commands listed above follows the toturial Moving Picture.
This is a rather odd looking quality plot, nothing I’ve personally come across from an Illumina run.
A few things come to mind. In your provenance it looks as though you imported paired-end sequences but the plot you show has only 1 direction of the reads. It looks to me as though perhaps the forward and reverse reads were just attached to each other from a 2x300bp run giving you ~ 600bp long reads. Or something else fishy is going on. Could you provide some more detail about the original reads prior to importing them into qiime? Were there any modifications, merging/trimming, or quality control made to your reads prior to import ?
Are these indeed 16S targeted reads using the Illumina platform? I ask because that is currently what deblur is designed to work with.
Also consider that since deblur only uses the forward reads you don’t really even need to import paired-end reads.
Once we get a bit more information on this hopefully it can troubleshooted further
Is it possible that one of the samples in your dataset does not contain any sequences that are 560nt (or longer)? The quality plot suggests quite few sequences are 560nt or longer. I’m unfortunately not able to download the posted demux.qza at the moment as I’m on limited WiFi.
@Mehrbod_Estaki, Deblur is agnostic to whether the data are forward, reverse, or paired. However, I’m not aware of a formal assessment using Deblur with paired data.
@wasade, you're right of course and that property was actually what I was trying to utilize. I just meant that in the event that the problem is occurring at the joining of the paired reads for whatever reason, a quick (less than ideal) solution would be to just ignore that step and import the forward reads only, essentially skipping the potentially problematic step. But that would just be ignoring the underlying problem, I'll bow out here and let the experts figure this out
It is important to remember that for many studies and questions, the forward read is sufficient. There have been quite a few excellent studies published using just the first 90 or 100nt of the 16S V4 region.
I think the error means that none of them contain any sequences are 560bp longer, which conflict the quality plot. Because I will do more analysis later, I just want to find out why this conflict happan…
That exception will arise if any sample lacks sequence that are >= 560bp. If that is a possibility then it may be worth setting a more conservative trim length. Does that make sense?
Hi Daniel,
So assume Sample A and B each have two reads, A1=A2=500bp, B1=B2=600bp. The quality plot unfortunately selected B1 and B2 on the chart. So if I trim it at 600bp according to the chart, the error will occur because Sample A have no read this long. Is this what you mean? Really thank for your patience!
Happy to be able to help! And yes, exactly. The processing is per-sample, and the trim length is applied to each sample. So if after trim, a sample has zero reads, I’d expect this exception to be thrown.
