I have paired-end data and usually perform merging the paired-end reads (-fastq_mergepairs/vsearch) as the first step, then I trim the primers (cutadapt) and finally run the quality filtering (-fastq_filter/vsearch). Following your tutorial, I wonder why do you suggest starting with trimmed reads before merging them. Wouldn麓t it be better to do the merging first?
From paper: "One such difference is that the DADA2 pipeline performs merging of paired-end reads after denoising. This is because the core denoising algorithm uses the empirical relationship between the quality score and the error rates. When reads are merged, this relationship will differ between the
forward-only, overlapping, and reverse-only portions of the merged read. That variation interferes with the denoising algorithm, and therefore greater accuracy can be achieved by denoising before merging, albeit at some computational cost."
Ok Ben,
thanks a lot!
Can you please elaborate why more information on a base position makes the denoising worse? That does not compute in my brain. Or is it too complicated to have two denoising "settings"?
@andzandz11 The reason is described above: https://github.com/benjjneb/dada2/issues/161#issuecomment-263940652
What specifically is unclear? More information is good, but in practice read merging programs assign quality scores that aren't the same (in relationship to the actual error rate) as what the sequencer assigned.
Most helpful comment
From paper: "One such difference is that the DADA2 pipeline performs merging of paired-end reads after denoising. This is because the core denoising algorithm uses the empirical relationship between the quality score and the error rates. When reads are merged, this relationship will differ between the
forward-only, overlapping, and reverse-only portions of the merged read. That variation interferes with the denoising algorithm, and therefore greater accuracy can be achieved by denoising before merging, albeit at some computational cost."