reads diffreence in fastqc and Tophat input
I am doing paired-end RNA-seq analysis, and I noticed that there are 2 files have different # of reads showing in fastqc and tophat summary. There two files also had problems running htseq-count. Does anyone know what is wrong?
Here is align_summary from tophat:
Left reads:
Input : 6833369
Mapped : 6205653 (90.8% of input)
of these: 373370 ( 6.0%) have multiple alignments (2442 have >20)
Right reads:
Input : 6833369
Mapped : 6199565 (90.7% of input)
of these: 373213 ( 6.0%) have multiple alignments (2441 have >20)
and the summary from fastqc:
##FastQC 0.10.1
>>Basic Statistics pass
#Measure Value
Filename SRR1559100_1.fastq.gz
File type Conventional base calls
Encoding Sanger / Illumina 1.9
Total Sequences 88383287
Filtered Sequences 0
Sequence length 60-101
%GC 48
0 answers
No answers yet.
Log in to answer this question.
More posts like this
-
TopHat alignment on Trinity Transcripts giving a lot of unmapped results.
written by kanika.151
-
concordant pair alignment rate is too low
written by zizigolu
-
The left reads map 95% while the right reads map only 0.7% using tophat
written by s_halawa •
-
Difference between pair alignment rate and properly paired reads
written by monteiro.s.rita •
-
Chip-Seq's mapping rate problem.(too low)
written by leenaehyeon •
-
Very low concordant rate using TopHat2
written by AT •
-
Discrepency between number of reads tophat
written by mbio.kyle
-
What does it mean that: 100% of my alignment are discordant?
written by tiago211287
-
99.9% are discordant alignments, please help
written by dixit.anirudha •
-
tophat output files containing the reads which mapped uniquely as a pair
written by trakhtenberg
Were the reads trimmed at some point? Tophat filters out reads that it considers to be too short, so they won't end up in its final output.
They were trimmed using trimmomatics before running both fastqc and tophat, and reads were dropped if their length were shorter than 60% of the read length
Also, if the reads contain Ns, they might not be counted (not sure, but is a suggestion).
I counted by grep -c 'N' file and the number does not seem to be close to the difference, but thanks for the suggesiton
Not sure this is the right way to do it. You might grep read names or quality lines as well this way. You should use for example
bioawkto print only $seq lines and thengrep -c 'N'from that output.