Quality trimming of 16S MiSeq data before or after merging paired reads?

[chris_s]

Hi everyone,

I am usually accustomed to perform quality trimming on 16S-targeted MiSeq PE reads prior to merging them, however my sequencing facility suggested that they had obtained very good results by quality trimming after merging the reads.

In a way this makes sense. In the good old days of Sanger sequencing, we would combine paired reads into a contig which would be a quality check in itself. We would then quality check and trim the merged reads.

Has anyone been performing the quality trimming after read merging? Does anyone know how this choice may impact the data down the line?

All inputs will be greatly appreciated!

Cheers,


Chris

[lorendarith]

I guess the result will depend on which tool you are using for overlapping since most of them do different things - some include and require adapter sequences, others just merge by looking at the quality score, others trim and merge...

Here's a good read and source of read mergers:

http://thegenomefactory.blogspot.de/2012/11/tools-to-merge-overlapping-paired-end.html

I don't understand why you would do quality trimming after merging though. Most trimmers assume a drop in quality at the 3' end of the read. After you overlap reads, won't you have the "good" 5' start on both ends of the assembled contig and the middle/overlap part with lower quality depending on the actually quality of the read ends?

If the quality drop at the 3' end was really bad, I would trim the reads first and then try to overlap them in order to get better/more overlapping reads. But if your facility says the run was really good, I don't see why not just go for overlapping directly since probably only a smaller number of reads won't overlap due to quality issues, depending on the insert and fragment size respectively.

[Brian Bushnell]

BBMerge tends to work better without trimming first. It attempts to merge each pair, and if unsuccessful, it trims them and tries again.