ITSx chimera detection

[catnipping]

I was wondering if the chimera detection function embedded in ITSx was robust enough to be reliable without the need of an additional chimera detection step (e.g., uchime_ref or uchime_denovo in vsearch).

Looking into ITSx manual, this is their definition of chimeric sequence: "[chimeric sequences] are sequences with### domains located in the wrong order. This is useful on full-length or near full length data sets, but should not be used on short reads as it could increase the number of false negatives when run on short sequences." Moreover, it states "Note that this is not a robust measure against chimeras of all kinds". Lastly, regarding the option --allow_reorder: "If turned off, a file of potentially chimeric sequences (with profile matches in the wrong order) is written, allowing for, e.g., rudimentary assembly chimera detection."

My understanding is that ITSx would not detect a sequence as chimeric if the chimera resulted from the hybridisation of two different organisms, but the amplicon maintained the correct order (e.g. SSU-ITS1-5.8S from Fungus1 hybridised with ITS2-LSU from Fungus2).
During a PCR reaction, a chimera is generated by the extension of an aborted amplicon that functions as a primer in the next PCR cycle; this generates amplicons that are "half something and half something else", rather than an amplicon with a complete structural rearrangement (e.g., ITS2 before ITS1, etc). As a consequence, I believe the results of ITSx chimera detection function should be handled with care (as the developers themselves suggest).

I think it would be a good idea to add the --uchime_denovo function of vsearch rather than relying on ITSx only. The reason why I tend to prefer it to the --uchime_ref function (at least if my data include loads of poorly annotated sequences) is a topic for another discussion :)

[blex-max]

This is interesting, thank you. It sounds like we do need more chimera detection. Having said that, why you prefer --uchime_denovo seems very relevant for this discussion before I implement!

[blex-max]

You recommend chimera detection immediately before ITSx then?

[catnipping]

##SPOILER: very long post##

I'd turn off the chimera detection function of ITSx (function --allow_reorder F ) and run a chimera detection before ITSx. However, it would be interesting to compare the results of chimera detection with ITSx (withouth vsearch) and of standalone-vsearch.

As for the question --uchime_denovo vs --uchime_ref, my thoughts below. It's a choice of the utmost importance and it deserves a deeper discussion. I recently have a second thought about the suitability of the de novo mode for Sanger sequences.

In this paper https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3150044/ Edgar et al say:
"UCHIME requires either a database with adequate coverage of the phylogenetic diversity in the input sequences (reference mode), or an estimate of unique amplicon sequences and their abundances (de novo mode)".
I may be wrong, but what worries me about the referenced mode is that poorly represented fungal taxa will be discarded as suspect chimera. Datasets with poorly known sequences coming from a unique PCR reaction and a run of Sanger sequencing (as a matter of probability, less prone to chimeras than the multi-step-PCR NGS technologies such as Illumina) may be prone to false positives just because the tool, while searching the database, cannot find anything similar enough to those sequences. However, I do not know exactly how the referenced mode operates, and how it compares the query to the database. It would be useful to find out.

As for the denovo mode, the authors say:
"In de novo mode, UCHIME starts with an empty reference database. Sequences are considered in the order of decreasing abundance. If a sequence is classified as chimeric, it is discarded; otherwise it is added to the reference database. Candidate parents are required to have abundance at least λ times that of the query sequence, on the assumption that a chimera has undergone fewer rounds of amplification and will therefore be less abundant than its parents. The parameter λ is called the abundance skew, and by default λ=2, assuming at least one more round of amplification for the parents.".
If these are the assumptions, the denovo mode may not be suitable for Sanger sequencing, as every single sequence has abundance=1.

To compare referenced and denovo methods, I tried --uchime_denovo and --uchime_ref on my dataset of 408 Sanger-generated sequences. I used UNITE fungal db in the referenced mode, which reported 81 chimeras+23borderline seqs; the denovo mode reported zero chimera. I manually checked the chimeric sequences from the ref mode using the –uchimeout output, where the accession# of each parent sequence (assuming that: chimera=parent_seq_A+parent_seq_B) is specified for each chimera. I wanted to check if the putative parent sequences were in the list of accessions resulting from blasting those sequences on UNITE fungi (analysis ran separately; 20 blast hits per sequence considered). My logic was that if a sequence is chimeric, I should find its parent sequences when blasting the dataset. In conclusion, out of 104 chimeric+borderline sequences, only 23 had both parent sequences in the blast dataset.

This raises the question whether the results of –uchime_ref are actually inflated with false positives, as so many putative parent sequences do not even appear in the blast search.

[catnipping]

In conclusion, to answer your previous comment "Having said that, why you prefer --uchime_denovo seems very relevant for this discussion before I implement!": I am not convinced that the denovo mode is best anymore. At the same time, I am not sure the referenced more is suitable, either. If you are working on sequences which are better represented than mine in UNITE, it may be worth repeating the little exercise I did above on your data.