Two peaks on FastQC plot "Per sequence GC content"

[Tommyliu]

Hi,
I just got illumina DNA genome re-sequencing data. All the items in FastQC reports passed but "Per sequence GC content". There are two peaks on the plot of "Per sequence GC content". The major peak centers around 40% GC content, while the minor peak centers around 70% GC content.

I would appreciate it if you can explain to me how this happened and what I should do to correct it or discard the minor peak.

Thanks in advance!

[mastal]

It suggests that maybe you have some kind of contamination.

What %GC content are you expecting for the species you are sequencing?

I would do adapter trimming/quality trimming and rerun FastQC afterwards to see whether that gets rid of the problem or not.

[Wallysb01]

Its probably the adapters. Do some trimming and it will go away.

[simonandrews]

If the secondary peak is very sharp it's probably a specific contaminant - often something which is found by the overrepresented sequences module.

If the peak is fairly sharp and not too far from your main distribution it could be long read through into adapters as suggested above.

If the secondary peak is quite broad then it might be that you have contamination with a different species. You could use something like fastq_screen to check for other species you work with regularly, but this won't pick up other odd sources of contamination.

[MichalGordon]

The “Per base sequence content” and “Per base GC content” graphs should not show contamination of the adapters?

[simonandrews]

The “Per base sequence content” and “Per base GC content” graphs should not show contamination of the adapters?

They might show some effects. If you have adapter dimers then you'll see the adapter sequence superimposed on the sequence content graphs. If your adapters have markedly different GC content than your library in general then you might also see an overall effect on the GC level.

In the latest fastqc release there is a graph specifically to measure adapter content which will show exactly what proportion of the library is composed of read-through adapter which will illustrate this much better than trying to use sequence content plots.

[MichalGordon]

Thank you!

[chariko]

They might show some effects. If you have adapter dimers then you'll see the adapter sequence superimposed on the sequence content graphs. If your adapters have markedly different GC content than your library in general then you might also see an overall effect on the GC level.

In the latest fastqc release there is a graph specifically to measure adapter content which will show exactly what proportion of the library is composed of read-through adapter which will illustrate this much better than trying to use sequence content plots.

I am having a similar problem with my run (2x150), As you can see there are two peaks in my run. I expect to have a 40% of GC content (bacterial genome) but I don know why did I obtain these two peaks.

[PASS] Basic Statistics
[PASS] Per base sequence quality
[PASS] Per sequence quality scores
[FAIL] Per base sequence content
[FAIL] Per base GC content
[WARNING] Per sequence GC content
[PASS] Per base N content
[WARNING] Sequence Length Distribution
[WARNING] Sequence Duplication Levels
[WARNING] Overrepresented sequences
[WARNING] Kmer Content

Oversequencing is probably not the problem because in fact I obtained less reads as expected. Could it be due to a adaptor problem? Any clue would be really appreciated

[nucacidhunter]

I think it will be helpful if you could provide more information such as library type, input material, kit used for library prep and graphs from new version of FastQC.

[chariko]

I think it will be helpful if you could provide more information such as library type, input material, kit used for library prep and graphs from new version of FastQC.

I updated FastQC to the 11.2 version and my error disappeared. I wonder it was an old version problem...

[simonandrews]

I updated FastQC to the 11.2 version and my error disappeared. I wonder it was an old version problem...

The per base GC plot was removed in the latest version since it mostly replicated information which was in the per base composition plot. You should still be able to see the biased positions as a deviation in the composition of C or G content at the same positions, but it's possible it's not enough of a deviation to trigger a warning.

[chariko]

The per base GC plot was removed in the latest version since it mostly replicated information which was in the per base composition plot. You should still be able to see the biased positions as a deviation in the composition of C or G content at the same positions, but it's possible it's not enough of a deviation to trigger a warning.

As you can see in the per base composition plot the C content goes down on position 5 (as seen in the per base GC plot before and goes up on position 9. I assume as the manual tells, the first 12 positions could be a selection bias.
I assume everything is OK then since the GC content in the specie s around 40%,


It was an Nextera MiSeq bacterial genome sequencing experiment.

Thank you very much for your help

[GenoMax]

Everything is ok

[Khillo81]

Hi!

I have two problems: one is two peaks in the per sequence GC-content and another is a weird profile which I'm attaching here.

We're trying out Agilent's SureSelect enrichment protocol for Exome-Seq and have just concluded our first run on samples that were already done before using Illumina's Nextera kit (so we have another run with which to compare our results). The first run was sequenced on the Illumina HiSeq while this run was done on a MiSeq. Also, the first run was a 100bp paired end run while this was 150bp paired end run. Anyway, upon running a QC on the Fastq files I got this weird profile for the per-sequence GC content. I had already removed the low-quality reads and trimmed the adaptors but that didn't change anything. The only thing that helped was trimming 25 nucleotides from each end of the reads. Since we lose a lot of information that way, I'd prefer not to do this and want to ask if anyone has seen anything like this. I have no idea what might cause this.

[Brian Bushnell]

This is sometimes a sign of contamination, though if trimming the reads reduces it, that's a bit odd. Is this supposed to be human data? Human should peak around 50%, which does not correspond to either of your peaks. The most important question is what organism this is supposed to be, and what it's average GC% is.

Also, please post an insert-size histogram, which will help determine if the problem is caused by short inserts. You can get one quickly using BBMerge:

bbmerge.sh in1=read1.fq in2=read2.fq ihist=ihist.txt