Here I am, with another question regarding the vsearch workflow. For what I understand, the workflow should be something like this:
trim adapters (done)
merge paired end reads (done)
quality filtering (done)
chimera filtering
dereplicating
otu clustering
I am a bit confused at this point, as I read in some of the tutorials that I need to trim the reads to equal length, possibly using cutadapt, is that correct? I am struggling to find the proper command to do it.
Thank you for your kind attention. I have seen those tutorials, but I still think I am missing something. Actually, I have just reviewed the workflow here:
From that it looks like chimera filtering comes after the clustering step. Am I correct? As an alternative, would it be correct to just use the deblur output as input to clustering?
From my perspective this is probably a bit more of a “best practice” rather than a requirement, although perhaps @cduvallet can shed some light on that section of the tutorial.
The amplicons generated by the 515F-806R primers (and for that matter probably any other amplicon) are not exactly the same length across the taxonomic spectrum, there are single nucleotide indels here and there, relative to the majority. That will give a dominant size and some shorter/longer (1-2 nt on either side). If you truncate to the most common size and remove anything shorter you will lose some taxa. If you trim the longer sequences from one end you will have a terminal gap in those sequences following a multiple sequence alignment and an internal gap in the dominant size sequences. Not sure if/how these would impact OTU calling as compared to leaving them as they are. But I would definitely not remove sequences that are a few nucleotides shorter than average. You can always extract them and see if they are a district taxon or a potential artifact.
Best,
The length trimming step is more important for dramatically different length reads (like the output of single-end sequencing like the older 454 pyrosequencing). I wouldn’t worry about trimming if the reads are just a few bp’s different (like @mpodar mentioned).
Having different length reads will affect your OTU calling differently depending on which similarity function you’re calling. Check out the vsearch documentation (see the --id and --iddef section). fwiw, it doesn’t look like the qiime2 implementation of vsearch allows for the --iddef flag to be changed.
In general I agree with @thermokarst that it probably makes more sense to do either denoising or clustering, unless you have a specific reason for wanting to do both.