Hi All,
My samples were run on Illumina HiSeq2000 using paired-ended stranded RNA-Seq protocol and the output reads are 100bp. The quality of my data are not bad in general. But I got some weird peaks at 3' end in FastQC kmer content graphics (plz see the attached graphs) and most of peaks are "GAAGA". Since this is part of the Illumina adapter (GATCGGAAGAGCTCGTATG), I tried Cutadapt (Cutadapt -a GATCGGA inputfile outputfile) to trim all the adapters at 3' end. This did get rid of the peaks in some of my samples, but the peaks still retain in a few samples, and another kmer "GAGGA" poped up. So I'm sure whether the 3' bias were caused by adapter remnant.
I also has a question about the 5' end bias. I was told they were caused by random hexmars. But shouldn't the hexmars only appear at 5' end of Read1? Why Read2 has the same bias at 5' end?
I will use trimmomatic to trim and filter the data next. But I'm not sure whether I should trim off the 3' end of Read2 or not, as the average overlapping between Read1 and Read2 is only 21bp (the average size of the library was 300bp, but all the fragments larger than 200bp were selected, which means the average inserts were of 179bp).
I would appreciate it very much if anyone has a better clue of what happened at both ends of the reads in my data set. Many thanks!
Attached graphs:
1: kmer content graph of Read1 (raw data)
2: kmer content graph of Read2 (raw data)
3: kmer content graph of Read1 (after Cutadapt)
4: kmer content graph of Read2 (after Cutadapt)
5: quality graph of Read2 (raw data)
The Cutadapt reports of Read1 and Read2:
52F-R1: Adapter 'GATCGGA', length 7, was trimmed 713126 times.
Processed reads: 5456168
Processed bases: 545616800 bp (545.6 Mbp)
Trimmed reads: 713126 (13.1%)
Trimmed bases: 9418910 bp (9.4 Mbp) (1.73% of total)
52F-R2: Adapter 'GATCGGA', length 7, was trimmed 544449 times.
Processed reads: 5456168
Processed bases: 545616800 bp (545.6 Mbp)
Trimmed reads: 544449 (10.0%)
Trimmed bases: 7082484 bp (7.1 Mbp) (1.30% of total)
My samples were run on Illumina HiSeq2000 using paired-ended stranded RNA-Seq protocol and the output reads are 100bp. The quality of my data are not bad in general. But I got some weird peaks at 3' end in FastQC kmer content graphics (plz see the attached graphs) and most of peaks are "GAAGA". Since this is part of the Illumina adapter (GATCGGAAGAGCTCGTATG), I tried Cutadapt (Cutadapt -a GATCGGA inputfile outputfile) to trim all the adapters at 3' end. This did get rid of the peaks in some of my samples, but the peaks still retain in a few samples, and another kmer "GAGGA" poped up. So I'm sure whether the 3' bias were caused by adapter remnant.
I also has a question about the 5' end bias. I was told they were caused by random hexmars. But shouldn't the hexmars only appear at 5' end of Read1? Why Read2 has the same bias at 5' end?
I will use trimmomatic to trim and filter the data next. But I'm not sure whether I should trim off the 3' end of Read2 or not, as the average overlapping between Read1 and Read2 is only 21bp (the average size of the library was 300bp, but all the fragments larger than 200bp were selected, which means the average inserts were of 179bp).
I would appreciate it very much if anyone has a better clue of what happened at both ends of the reads in my data set. Many thanks!
Attached graphs:
1: kmer content graph of Read1 (raw data)
2: kmer content graph of Read2 (raw data)
3: kmer content graph of Read1 (after Cutadapt)
4: kmer content graph of Read2 (after Cutadapt)
5: quality graph of Read2 (raw data)
The Cutadapt reports of Read1 and Read2:
52F-R1: Adapter 'GATCGGA', length 7, was trimmed 713126 times.
Processed reads: 5456168
Processed bases: 545616800 bp (545.6 Mbp)
Trimmed reads: 713126 (13.1%)
Trimmed bases: 9418910 bp (9.4 Mbp) (1.73% of total)
52F-R2: Adapter 'GATCGGA', length 7, was trimmed 544449 times.
Processed reads: 5456168
Processed bases: 545616800 bp (545.6 Mbp)
Trimmed reads: 544449 (10.0%)
Trimmed bases: 7082484 bp (7.1 Mbp) (1.30% of total)
Comment