Dear all,
I would like to ask your help with a problem that I've encountered while running TopHat. I wanted to test if the results that I obtain with TopHat are reproducible (if I run the program several times with the same parameters, on the exact same data, do I get the same results ?). This is not the case, I find that sometimes TopHat crashes without warning, and gives only what I call truncated results - i.e. relatively few predicted junctions as compared to what is expected, or to what is found in other runs.
Here are some details about what I'm doing: I have 76bp-long, single-end reads. I'm using TopHat v1.0.13, with Bowtie 0.12.3, on a Linux computer with x86_64 architecture. I'm running TopHat with the following parameters:
-p 1 -a 8 -i 40 -m 1 -I 1000000 -F 0 --coverage-search --microexon-search
For one of the runs where I get truncated results, I have noticed this weird thing in the output:
[Thu May 27 17:25:49 2010] Mapping reads against segment_juncs with Bowtie
[Thu May 27 17:25:50 2010] Mapping reads against segment_juncs with Bowtie
[Thu May 27 17:25:51 2010] Mapping reads against segment_juncs with Bowtie
The weird thing is that mapping the reads against segment_juncs should take a lot more time, since I have about 20 million reads. So I thought that there might be an error in building the bowtie index for the splice junctions, but the bowtie_build.log shows no erorr. However, I find the following errors in some other log files from the run:
############################################
file18CIUx.log:
Could not locate a Bowtie index corresponding to basename "/scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs"
Command: bowtie -q -v 2 -p 1 -k 40 -m 40 /scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs /scratch/frt/yearly/necsulea/Orthos
plice/results/tophat/Orangutan/Liver_Gelar//tmp/left_kept_reads_seg3.fq
############################################
filebd4xji.log
Error reading ebwt array: returned 41750080, length was 168445184
Your index files may be corrupt; please try re-building or re-downloading.
A complete index consists of 6 files: XYZ.1.ebwt, XYZ.2.ebwt, XYZ.3.ebwt,
XYZ.4.ebwt, XYZ.rev.1.ebwt, and XYZ.rev.2.ebwt. The XYZ.1.ebwt and
XYZ.rev.1.ebwt files should have the same size, as should the XYZ.2.ebwt and
XYZ.rev.2.ebwt files.
Command: bowtie -q -v 2 -p 1 -k 40 -m 40 /scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs /scratch/frt/yearly/necsulea/Orthos
plice/results/tophat/Orangutan/Liver_Gelar//tmp/left_kept_reads_seg3.fq
############################################
So it does seem that TopHat cannot read the index files that were built with Bowtie. I do not understand why that would be - has anyone come across the same problem ?
What I also don't understand is how is it possible that TopHat can still output some junctions (the "truncated" junctions.bed file is not empty, just smaller than on a normal run) if it cannot read the bowtie index for the junction sequences.
I would be grateful if you can give me some comments or suggestions on how I could solve this problem. Thank you !
Best,
Anamaria
I would like to ask your help with a problem that I've encountered while running TopHat. I wanted to test if the results that I obtain with TopHat are reproducible (if I run the program several times with the same parameters, on the exact same data, do I get the same results ?). This is not the case, I find that sometimes TopHat crashes without warning, and gives only what I call truncated results - i.e. relatively few predicted junctions as compared to what is expected, or to what is found in other runs.
Here are some details about what I'm doing: I have 76bp-long, single-end reads. I'm using TopHat v1.0.13, with Bowtie 0.12.3, on a Linux computer with x86_64 architecture. I'm running TopHat with the following parameters:
-p 1 -a 8 -i 40 -m 1 -I 1000000 -F 0 --coverage-search --microexon-search
For one of the runs where I get truncated results, I have noticed this weird thing in the output:
[Thu May 27 17:25:49 2010] Mapping reads against segment_juncs with Bowtie
[Thu May 27 17:25:50 2010] Mapping reads against segment_juncs with Bowtie
[Thu May 27 17:25:51 2010] Mapping reads against segment_juncs with Bowtie
The weird thing is that mapping the reads against segment_juncs should take a lot more time, since I have about 20 million reads. So I thought that there might be an error in building the bowtie index for the splice junctions, but the bowtie_build.log shows no erorr. However, I find the following errors in some other log files from the run:
############################################
file18CIUx.log:
Could not locate a Bowtie index corresponding to basename "/scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs"
Command: bowtie -q -v 2 -p 1 -k 40 -m 40 /scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs /scratch/frt/yearly/necsulea/Orthos
plice/results/tophat/Orangutan/Liver_Gelar//tmp/left_kept_reads_seg3.fq
############################################
filebd4xji.log
Error reading ebwt array: returned 41750080, length was 168445184
Your index files may be corrupt; please try re-building or re-downloading.
A complete index consists of 6 files: XYZ.1.ebwt, XYZ.2.ebwt, XYZ.3.ebwt,
XYZ.4.ebwt, XYZ.rev.1.ebwt, and XYZ.rev.2.ebwt. The XYZ.1.ebwt and
XYZ.rev.1.ebwt files should have the same size, as should the XYZ.2.ebwt and
XYZ.rev.2.ebwt files.
Command: bowtie -q -v 2 -p 1 -k 40 -m 40 /scratch/frt/yearly/necsulea/Orthosplice/results/tophat/Orangutan/Liver_Gelar/tmp/segment_juncs /scratch/frt/yearly/necsulea/Orthos
plice/results/tophat/Orangutan/Liver_Gelar//tmp/left_kept_reads_seg3.fq
############################################
So it does seem that TopHat cannot read the index files that were built with Bowtie. I do not understand why that would be - has anyone come across the same problem ?
What I also don't understand is how is it possible that TopHat can still output some junctions (the "truncated" junctions.bed file is not empty, just smaller than on a normal run) if it cannot read the bowtie index for the junction sequences.
I would be grateful if you can give me some comments or suggestions on how I could solve this problem. Thank you !
Best,
Anamaria