Tweet
Someone asked me whether it makes sense to remove duplicate reads to get the library size down to fit RAM limit. I think it is a bad strategy as explained here -
-
I think duplicated reads removed to avoid biases that resulted from library preparation (for example) and not for reduction of data for de-novo assembly.
Ilia -
That's a good point. Some filtering is necessary to take care of pileup of reads due to biases. I do that for alignment and SNP discovery, but think twice about it during de novo assembly. If no underlying genome is known, it is hard to tell whether the duplicated reads come from error or real sequence.Comment
-
So when you assemble reads in to contigs, you will prefer that at least several reads will support the assembly. If you will have identical reads, you might obtain false contigs.
IliaComment
-
It does not work that way for K-mer based assembler. Would you please explain your rationale? Why would one get false contigs?Comment
-
Let me rephrase my last comment:
If duplicated reads don't contribute to downstream the de novo assembly pipe, it will be good idea to remove them.
IliaComment
-
Love this - good data definitely starts from good input, and poor input can only give relatively poor data. I particularly like the mention of Nanodrop/absorbance based methods for quantification. It's such a toss up if you'll get an accurate reading or what amounts to a randomly generated number, and a lot of library/sequencing related issues can be traced back to poor quant.07-01-2026, 11:43 AM
-
I’m not a sequencing expert. I’m a purification scientist who uses NGS to evaluate workflows my group develops. With this perspective, we think about the sample first and the NGS workflow second. The sequencer is an exceptionally honest reporter, but it can only report on what you give it, so whether you get clean, interpretable data from an NGS workflow is largely determined before you begin.
Here are nine questions we think about, in roughly the order they matter, before...
Comment