Hey all,
I've been working with an RNA paired-end dataset of around 60 milion reads, in which a big part of the reads map to the same gene. However, it seems that there is a hard limit of around 65536 (=2^16) mapped reads per base, since this gene displays a weird saw-like pileup (going up steadily until around 65536 and then dropping to around 1000 to keep going up steadily), in contrast to the normal appearance of other less expressed genes that don't reach that coverage level, or even the very same gene in an alignment with a less deep coverage dataset:
(click for zoom) Blue track is the less deep dataset, grey track is this problematic pileup. The maximum value shown here is not 65000 reads, since I normalized the tracks before uploading them, it is the raw coverage.wig file TopHat produces that actually hits that value in the grey track. The effect is best seen in the left part of the 2nd exon.
I'm using the latest Bowtie version, 0.12.3.0, and TopHat version v1.0.12; even though when I first spotted this behavior I was using a previous Bowtie version, 0.11.3.0. This was run on a x86-64 Karmik Ubuntu.
I don't think there is an easy way around this, using comand line options and such, but I'm very interested to know. I can write a script that will deal with this problem, but probably this issue can be solved for the future versions of Bowtie/TopHat. I'm no IT guy but it seems like a simple int overflowing problem to me.
I've been working with an RNA paired-end dataset of around 60 milion reads, in which a big part of the reads map to the same gene. However, it seems that there is a hard limit of around 65536 (=2^16) mapped reads per base, since this gene displays a weird saw-like pileup (going up steadily until around 65536 and then dropping to around 1000 to keep going up steadily), in contrast to the normal appearance of other less expressed genes that don't reach that coverage level, or even the very same gene in an alignment with a less deep coverage dataset:
(click for zoom) Blue track is the less deep dataset, grey track is this problematic pileup. The maximum value shown here is not 65000 reads, since I normalized the tracks before uploading them, it is the raw coverage.wig file TopHat produces that actually hits that value in the grey track. The effect is best seen in the left part of the 2nd exon.
I'm using the latest Bowtie version, 0.12.3.0, and TopHat version v1.0.12; even though when I first spotted this behavior I was using a previous Bowtie version, 0.11.3.0. This was run on a x86-64 Karmik Ubuntu.
I don't think there is an easy way around this, using comand line options and such, but I'm very interested to know. I can write a script that will deal with this problem, but probably this issue can be solved for the future versions of Bowtie/TopHat. I'm no IT guy but it seems like a simple int overflowing problem to me.