should the de novo search be conducted within samples?

[carlo pacioni]

Hello again,
Can I please ask if somebody can confirm that the following is
correct?

Given that the most common cause of chimeras is incomplete template
extension, the (UCHIME) De Novo search for chimeras should be
conducted within samples (i.e. one search for each PCR reaction, which
most commonly will be identified with sample labels).
If the above is correct, could you confirm that when running
pick_otus.py –m usearch –x the search is conducted within each sample?

Thank you very much,

Carlo

[Tony Walters]

Hello Carlo,

This is in the queue to be done, but is not implemented yet.  It is different than the original OTUPipe implementation that was wrapped in QIIME.  It's not quite as easy as simply splitting apart the input sequences and running through the pipeline multiple times, as there has to be a merging process before the second clustering step to allow de novo clustering.  It's possible that the cluster size filtering parameter may need to be relaxed/disabled if one were to run individual samples though uchime manually.

-Tony

[Mike]

Hi,

I wanted to follow-up on this. Is the per-sample implementation of uchime in the works? We have been using uchime on some of our data and the results can obviously differ between running uchime on the entire data set vs per-sample. But as Carlo mentions, it is more correct to run uchime on a per-sample basis. Currently, we are using mothur to process my data on a per-sample basis (as the per-sample approach is implemented there, using the data grouping options) and then I continue down stream within QIIME.

I suppose the other option would be to run uchime via pick_otus.py at 99% similarity on each sample (making separate sample files with split_fasta_on_sample_ids.py script) and then, at the very end, concatenate the output of all those runs. Finally, run a standard pick_otus.py again (w/o uchime of course) on the concatenated output with the standard 97% similarity?

-Thanks!

-Mike

[Tony Walters]

No Mike,

There isn't changes like this for usearch 5.0.  It's being worked on for the chimera checking component of usearch 6.0 (which isn't going to be implented as part of the pipeline like OTUPIPE, as this creates problems with maintaining sequence identity, you can look into this if you follow the steps after the initial clustering/consensus sequence generation step of OTUPIPE).  With the usearch 6.0 implementation, the pick_otus.py script strictly does the OTU picking component of usearch (ref, de novo, or ref + de novo), and the chimera checking is all going to be within identify_chimeric_seqs.py.

--
 
---
You received this message because you are subscribed to the Google Groups "Qiime Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qiime-forum...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mike]

As always, thanks for the update Tony! :-)

So, if I understand you correctly, uchime chimera checking will eventually be removed from pick_otus.py and added to identify_chimeric_seqs.py?

-Mike

[Tony Walters]

Not quite-we're leaving the 5.X implementation as is-but the 6.X version is being crafted in that manner (clustering in pick_otus.py already done, chimera checking partially complete), which should be available in the near future on the github version of qiime.