Illumina NextSeq: Overrepresented sequences, strings of G's, A's

[ksw9]

Hi,
I've just got Illumina NextSeq genomic DNA sequence data back and have several samples that include overrepresented sequences - long strings of G's and A's - in the middle of the reads. This also introduces problems into the Per base sequence content and the Per sequence G-C content in FastQC quality control. The contaminated reads only represent a small fraction of reads ~2-3 %, but I'm worried about how to filter these reads out to best make use of the remaining sequence data. Is this a common NextSeq error? Would it make sense to use cutadapt to filter out any reads with strings of repeated nucleotides?

Thank you!

Overrepresented sequences table:
Sequence Count Percentage Possible Source
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAA 8524 0.458029623619369 No Hit
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAAA 8153 0.4380942657635753 No Hit
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAAAA 7458 0.4007490536078431 No Hit
GGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAAAAAAAAAAAAA 5428 0.2916687936421791 No Hit
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG 4282 0.23008949417387825 No Hit
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAAAAA 3288 0.17667778067344972 No Hit

[nucacidhunter]

Could you post the whole sequences of a few full reads (both pairs if paired-end) with the G/A string.

[GenoMax]

@ksw9: Take a look at this blog post.

[ksw9]

Thank you both for fast replies!

@GenoMax, yes this is consistent with my issue. My data have high-Q poly-G strings. However, they're additionally preceded by poly-A strings. I see there's an option to trim high-Q poly-G strings with cutadapt (trim-nextseq), but this does not remove the poly-A strings. I plan to run an additional cutadapt run to trim these sequences - does that make sense? Is this implemented in trim_galore?

@nucacidhunter, posting example paired-end reads below.

# R1
@NB501727:39:HWKGCAFXX:1:11101:4074:1056 1:N:0:TTGGTATG+NAGGACAC
GATCGGAAGAGCGGTTCAGCAGGAATGCCGAGACCGATCTCTTGGTATGATCTCGTATGCCGTCTACTGCTTGAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+
AAAAAEEEEEEEEEEEAEEEEEEEAE6/EAEEEE<EEEE//EEE//EE/EE/EA//E6EE/EEEE//////E/EEAEEEEEEE/AE/EEEA/E6AAE/A/66/////////////EAA/E//////AA/E//EAA<E/<EE/EEAEE///A
--
@NB501727:39:HWKGCAFXX:1:11101:21440:1247 1:N:0:TTGGTATG+AAGGACAC
GATCGGAAGAGCGGTTCAGCAGGAATGCCGAGACCGATCTCTTGGTATGATCTCGTATGCCGTCTTCTGCTTGAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+
AAAAAEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE6AEEAEEEEEEEEEEEEEAEEEEEEEEEEEE/E/EEEEEEEAEEEEEEEEEEEEEEEEEEEAEEEEEEEEEAEAEEEEEEEE<EEE<EA/EEAEEE<EEE
# R2
@NB501727:39:HWKGCAFXX:1:11101:4074:1056 2:N:0:TTGGTATG+NAGGACAC
GGGGGGGGGAAGGGGGGGGGAGGGGAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGCGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+
AA//A6/A////AA//A//6////E///////E/6/E<EE6/A//E////E///E/A///</6/A/A//<E/E/EEAEEE/E/AAE/<//A//66//6/////<//AE//E//E//EA///A////EE/<</</EEE///AE/<<E////<
--
@NB501727:39:HWKGCAFXX:1:11101:21440:1247 2:N:0:TTGGTATG+AAGGACAC
GGGGGGGGGGGGGGGGGGGGGGGGGGGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+
AAA6A6EE6A6A/66AA66////////EA//EE/EEEAE/EAA//EEEE/E/E//A////A///A//AEEE/EEAEEEEEEEEE/////AAE/EEAAEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEAEEEEEEEEEEAEE<A

[ksw9]

I've found that cutadapt works well in filtering poly-G strings, however, there are some ~200) remaining reads with poly-G strings longer than found in my reference genome (length = 10). I am wondering if I should remove any reads with these added G strings before mapping because of this known issue with NextSeq data?

Thank you!

[GenoMax]

Most aligners should soft clip data that does not match so you could try doing the alignments to see what you get.

[ksw9]

Good point, I will use cutadapt and then map, thank you!

[nucacidhunter]

Both R1s are adapter sequences (I can see the index as well) suggesting that these are from adapter-dimers. After reading through adapter, polyA spacer has been sequenced and then there is no base so lack of signal has been translated to Gs.

I am not sure how to explain R2 sequences.

[ksw9]

Thank you for checking. I've used trim_galore to remove adapter sequences and cutadapt to filter for poly-G strings. Even after these steps, the poly-G strings are included in about 0.1 % of my reads. I am planning to continue on to mapping unless there is a better way to deal with this issue that you'd recommend?

Thanks!