What causes tophat_reports error?
1
1
Entering edit mode
10.5 years ago

I had run tophat with following options:

tophat --bowtie1 -p 6 -o CT16 -r 150 --mate-std-dev 75 --no-discordant --no-mixed --transcriptome-index Transcriptome

and I get tophat_reports running error:

[2014-05-27 15:47:24] Reporting output tracks
    [FAILED]
Error running /usr/local/bin/tophat_reports

Another sample of the same study is not giving any problem. The difference between these two filesets is that the one that worked is relatively smaller ~6GB per pair compared to ~18GB per pair for the one that didn't work. Assuming that it could have been a runtime error I ran tophat resume (tophat -R CT16) but still it gave the same error. I have seen other people also reporting the same error but the precise reason is not mentioned anywhere. I checked if it is because of lack of space but I have ~500GB free!! There are no RAM issues either. I am using tophat v2.0.11. Is this a bug? How do I fix it?

RNA-Seq tophat • 4.7k views
ADD COMMENT
1
Entering edit mode

did you try with -p 1 ?

ADD REPLY
0
Entering edit mode

no I didnt.. It would be too slow then.. I tried it in a HPC and it still fails.. so I can confidently say that it is not a resource availability issue.

I tried with bowtie2 instead of bowtie1 and it still fails. Now it is seriously pissing me off. I didn't realize that tophat would be so damn irritating.

ADD REPLY
0
Entering edit mode

what is your RAM size? OS?

ADD REPLY
0
Entering edit mode

24GB RAM and 64bit Fedora 19 kernel 3.13.9-100

ADD REPLY
0
Entering edit mode

The normal cause of this is not enough RAM (this step can be a hog), however with 24 gigs that's somewhat unlikely. If you look in tophat's run log, you can see the exact command that it issued before crashing. As long as tophat kept all of the temp files then you should be able to directly run this yourself and then see what the actual underlying error is (yes, this is annoying). Depending on the organism you're using, you might consider switching to STAR, which is MUCH faster (24 gigs of memory might be enough, it'll depend on the genome size).

ADD REPLY
0
Entering edit mode

Could this be a solution?: split the file and run each splitfile on tophat and then stich the BAMs together

ADD REPLY
0
Entering edit mode

If you're not interested in finding novel junctions then yes, that'll work. If you do want to find novel junctions then the decrease in coverage will make that more difficult and the results wouldn't be as good if you split the input.

ADD REPLY
0
Entering edit mode

if tophat had an option to collapse the reads (while recording their counts) before aligning, this problem could have been partially avoided. Also, file size would be reduced.

ADD REPLY
0
Entering edit mode

Yeah, there are a number of annoyances with tophat's design. Give STAR a try. It'll make your life easier if you have enough RAM.

ADD REPLY
0
Entering edit mode

I was checking it but it doesn't predict novel junctions. I have to use the existing ones. I am hopeful that the 18GB file would let me find novel transcripts. Nonetheless, I'll run STAR in parallel.

ADD REPLY
1
Entering edit mode
10.5 years ago

Apparently, it is failing because of --no-discordant: I removed it and it worked. When I removed --no-mixed and kept --no-discordant it again failed. Perhaps I should write to tophat authors.

ADD COMMENT
0
Entering edit mode

I am also seeing the same error when I used --no-mixed --no-discordant? I removed both, it works fine. Now I am running by removing either one of them, and see if it works.

ADD REPLY

Login before adding your answer.

Traffic: 1846 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6