What might cause the "Sequence Duplication Levels" failures in FastQC report?

[elrohir610]

Hello Everyone,
We are dealing with exome sequencing data of tumor samples.
After using FastQC to assess the quality of data,
we found that those data failed at the "Sequence Duplication Levels" part
and got a warning at the "Kmer Content" part.

Moreover, according to the report of CASAVA,
read1 and read2 had a very different per base mapping score pattern.
(attachemnt: R1_vs_R2.jpg ).

The FastQC report also gave similar per base quality score patterns.

So..... what might cause these failures?

We have realigned the fasta files by BWA,
but the result was similar.
Therefore, the problem seems to result from sample preparation
or library preparation.........but, which one??

Our guess is that the DNA extracted from those sample had degraded.
Or actually this is a common phenomenon
when dealing DNA sequencing data of tumor samples?

Any response is welcome, thx.

[Heisman]

How many PCR cycles were done during the protocol? Also, how many reads were their total?

[simonandrews]

High duplication is either going to be the result of technical duplication (too many PCR cycles, as Heisman suggested), or over-sequencing (very high fold coverage). In your case you'll be able to tell between the two by aligning your sequences back to your reference and then seeing if you have high, even, coverage over your exome, or if you are seeing biased amplification of some parts. At the risk of repeating myself (I posted this yesterday in a different thread), it might be worth looking at this blog post, which goes over the different types of problems the duplicate plot can spot.

For the Kmer result, the most common reason to see a progressive pattern through a long read is that you're sequencing through your insert into the 3' adapter. In your case it's somewhat unusual that most of the overrepresented patterns are single nucleotide repeats, so there may be something else going on here. In any case it's worth looking at running an adapter trimmer on any dataset over 50bp.

[elrohir610]

Thank you both for reply.
The total number of reads is 415517084 and the length of reads is 100 bp.

The protocol we used is the standard protocol provided by Illumina.
Cancer DNA (100ng)-> TruSeq sample prep-> 10 cycle PCR
-> 500 ng DNA -> Exome capture ->10 cycle PCR -> Sequencing

However, we also sequenced other normal samples with same protocol
Normal DNA (1ug) -> TruSeq sample prep-> 10 cycle PCR
-> 500 ng -> Exome capture ->10 cycle PCR -> Sequencing

Even though the initial amount of tumor DNA was significantly lower,
the PCR still produced enough DNA to be sequenced.
The FastQC report of the normal sample also showed similar failure and warning.
(Attachment files)

Another interesting phenomenon is that,
some of the read2 from tumor sample are fusions:
The first half of those reads aligned on chrA,
but the second half of those reads aligned on chrB.
Both over sequencing and adapter contamination cause the
sequence duplication failure, but do any of them result in fusion read?

We will try the method suggested by simonandrews, hope they work.
Thanks.

[Heisman]

I've only done Agilent exomes but over 400 million reads seems like a very large amount. We get good coverage from under 100 million reads. It does not surprise me that you have a very high duplication rate with that many reads.

[sehrrot]

hi elrohir610

Could you upload your bioanalyzer profile for both? I've also experienced this kind of problem, but I don't think either PCR cycles or over-sequencing is the sole reason, of course they might affect some. Illumina sequencer is likely to sequence more for adapter dimers, even if they are only few ngs in the samples. Please check your bioA profile (HS chip preferred) or information of Base-pair composition by cycles in your SAV (if you see very zigged graph, not equally distributed, it would really be dimer contamination)

[simonandrews]

Given that you have 400 million reads that profile doesn't look too bad. You only have fairly low level duplication and you may just be hitting the diversity limit of either your sample or your library. I'd not spend too much time worrying about this sample if it was one of ours we'd let it through for downstream analysis.