FastQC : Bad quality at first positions

[melseq]

Hi everybody,
I have not found any threads answering to my issue.
I sequenced 50 bp reads with Illumina HiSeq.
My FastQC report shows a really good quality (between 32 and 40 along all the sequence) but I can not understand why the first positions of the reads (1 to 16 bp) exhibit worse quality than the end of the reads.
Would you have ideas regarding the cause of this?
I can not say if it is linked, but the first positions also show high percentage of A, compared to C, G and T and then %A/T lines meet as well as %G/C lines.

I have an additional question : what is for you the "threshold" of duplicated reads level between "good" and "bad" sequences?

Thank you very much.

[simonandrews]

When you say the reads show worse quality how much worse do you mean? Many Hi-Seq runs will show slightly reduced quality for the first few bases, but only by a few Phred points so not normally something which should cause concern.

Having biased sequence composition can also cause a loss of quality but this normally needs to be fairly severe to really cause a problem with the run.

[melseq]

Thank you for your answer.
The first positions show a median value of 33 and after the 14th positions, this median is equal or higher than 39. Hence, I think it does not cause a real problem. What is the cause of this loss of quality in the first positions specifically with HiSeq?
For the sequence composition, do you have explanations about this kind of bias?

Thank you again

[simonandrews]

Thank you for your answer.
The first positions show a median value of 33 and after the 14th positions, this median is equal or higher than 39.

That sounds like the sort of pattern we commonly see (increasing Phred scores early in the run, but always pretty good). I seem to remember hearing that RTA does a re-calibration after a few cycles which allows it to increase the maximum confidence it can assign - but don't quote me on that.

For the sequence composition, do you have explanations about this kind of bias?

It looks like the algorithm RTA uses has a problem when there is extreme bias in a run. Certainly we've seen on many runs that if you have the same base in all reads (the common one is a consistent T when using custom adapters), then this position will have low quality and a high proportion of Ns. We've even seen this in index reads where the balancing of indices wasn't very good such that one sequence was the majority of the run.