Yet another question regarding OTU clustering

Dear Qiimers,

Here I am, with another question regarding the vsearch workflow. For what I understand, the workflow should be something like this:

  1. trim adapters (done)
  2. merge paired end reads (done)
  3. quality filtering (done)
  4. chimera filtering
  5. dereplicating
  6. 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.

Looking forward to your suggestions,
Max

Hi @mstagliamonte - have you seen this tutorial? https://docs.qiime2.org/2019.1/tutorials/otu-clustering/ Also, this one: https://docs.qiime2.org/2019.1/tutorials/chimera/

Hi, @thermocast ,

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:

https://docs.qiime2.org/2019.1/tutorials/overview/

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?

Best,
Max

Yes.

Yes, although atypical — while not incorrect, people tend to either go with ASV methods (like deblur or DADA2) or clustering — not both.

Not necessarily — where did you read that?

1 Like

Great, thank you.

I need to trim the reads to equal length, possibly using cutadapt, is that correct?

Not necessarily — where did you read that?

Here:

https://docs.qiime2.org/2019.1/tutorials/qiime2-for-experienced-microbiome-researchers/#merging-reads

got to OTU clustering --> Length trimming.

While my raw paired end reads are the same length, merged reads are not. Maybe I am just misunderstanding it.

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.

1 Like

Thank you for your kind explanation. I look forward to @cduvallet 's feedback. In the meantime, I will go ahead with the pipeline.

Best,
Max

1 Like

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,

Mircea

3 Likes

I agree with everything that’s been said!

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.

3 Likes

That is great information from you all,

I am trying to implement both ASV and OTU strategies (separately) and I think I have a better idea of the two workflows now.

Thanks everybody for your kind help
Max

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.