Hi @p_auritus,
RE 1:
As you've found, it is inappropriate to send merged data to qiime dada2 denoise-single .... My understanding is that the merged reads will have a very different error profile than what DADA2 expects. If you look at a quality plot of the merged reads, you'll see that within the region of overlap between the two reads, i.e. the center of the single merged read, will have high quality scores. That is, the quality scores up until that center point (from both directions) might vary or decline until it hits that high quality center region. That region of overlap ends up having higher quality scores as both reads are calling the same base at the same position, thus increasing the confidence of the base call at those positions. To be honest, I am not sure why they just do not use a complete vsearch / deblur approach, as outlined here in the old user docs.
More on this later...
RE 2:
There are two types of chimera removal, de novo and "reference-based". The de novo approach became popular with userach / uchime, then later adopted by DADA2. This approach obviates the need for a curated reference database, which can be difficult to develop and curate. Often these curated reference databases used to be rare, and mainly SSU/LSU rRNA gene specific. Though, this is not as much of an issue these days... Anyway, it is not uncommon to use both, especially if you have access to a well trusted reference database, that covers most of the expected taxa in your sample . That is, it is possible that the de novo approach may not detect a chimera, when it in fact is a chimera, or vice versa.
Anyway to minimize the work required for making a reference database for every gene, the de novo approach was developed. However, there are some caveats with de novo chimera removal... in some cases they can remove real data, even highly abundant real data. So, you need to look closely at the chimera checking parameters for the various tools. Always try a few parameter settings, although default is often "good enough" many can run into problems, and end up hacking together inappropriate pipelines rather than simply using the tools built-in functinality.
There are two options I often suggest with DADA2: first, make sure you trim the reads appropriately. Having too much overlap can increase the chances of mismatch detection between the two reads, which can cause read merging failures. Obviously, reads being too short will not merge at all. Secondly, you may want to consider adjusting other DADA2 settings. For example, I often set --p-min-fold-parent-over-abundance to 8 or 16 as outlined here.
Given RE 1 above, if DADA2 does not work as well on your data you can modify the above linked deblur approach, by adding uchime-denovo available within qiime vsearch uchime-denovo --p-method uchime3 ... on your deblur /dada2 output. See here.
Speaking from my own personal experience, I'd strongly recommend processing the data yourself. ![]()