![]() |
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
How to combine junctions.bed files produced by TopHat | HTS | Bioinformatics | 8 | 05-03-2015 03:33 AM |
Tophat junctions.bed | RockChalkJayhawk | RNA Sequencing | 7 | 12-12-2013 11:56 AM |
Empty junction.bed TopHat | vinay052003 | Bioinformatics | 0 | 11-24-2011 05:53 PM |
TopHat v1.1.4 - Empty *.bed files | lianzinho | Bioinformatics | 5 | 06-30-2011 01:55 AM |
tophat junctions.bed | MerFer | Bioinformatics | 0 | 06-16-2010 03:57 AM |
![]() |
|
Thread Tools |
![]() |
#1 | |||||
Member
Location: Finland Join Date: Jun 2011
Posts: 24
|
![]()
Hi all,
To prepare for analyzing some RNAseq data we are expecting to get soon, I'm trying to use TopHat to analyze a similar published dataset from the SRA (http://www.ncbi.nlm.nih.gov/geo/quer...i?acc=GSE21323). We are also using SOLiD and are expecting 36-bp reads, though our data will be paired-end. After downloading the .sra file and converting it (with fastq-dump and a perl script from another thread on the forum), I have a prmt5.csfasta file that looks like: Quote:
Quote:
Quote:
Quote:
Quote:
Can anyone provide some pointers about what's going wrong? Am I making a simple, silly mistake or is there something fundamental I'm misunderstanding? I thought it would be fine to do these test runs on my desktop (Core2 Duo 3GHz with 4GB RAM); could that be causing trouble (eg, not enough memory)? Thanks for any help, guidance or suggestions! |
|||||
![]() |
![]() |
![]() |
#2 |
Junior Member
Location: Stockholm Join Date: Jun 2011
Posts: 5
|
![]()
Hey,
I have the exact same problem and data type as thurisaz's, except I got no warnings or error messages whatsoever. According to 'bowtie.left_kept_reads.fixmap.log' only 10% of the reads were aligned!! I should note that when I ran Tophat 1.0.12 on a sample dataset I did get meaningful .bed files, but there I had another problem when I ran it on the full dataset, as the temporary file: 'left_kept_reads.fq.candidate_hits.sam' became huge (>360GB) and the program was terminated by the server before it finished running. The Bowtie version was the same for both runs ( 0.12.3). I couldn't find significant changes between v1.0.12 and v1.3.0 regarding short reads handling. Were ther any? Please help us solve this, it's quite depressing coming home to an empty .bed... |
![]() |
![]() |
![]() |
#3 |
Junior Member
Location: UK Join Date: Apr 2011
Posts: 1
|
![]()
Hi all,
I encounter a similar problem when running Tophat 1.3.0 on Illumina sequencing data (75nt PE). The dataset has ~30 mio reads and Tophat 1.1.4 (--num-threads 8 --mate-inner-dist 200 --solexa-quals --min-isoform-fraction 0 --coverage-search --segment-mismatches 1) predicts almost 9 mio junction-spanning reads among them. The same input file and the same Tophat parameters used with Tophat 1.3.0 finds only ~1000 junction-spanning reads, changing the parameters makes the number drop down to 0. Like reported by thurisaz, Tophat seems to run fine, but long_spanning_reads.log contains many many lines of Warning: malformed closure. I would be very happy for any explanations why the junction reads are lost or suggestions how to solve the problem. Thanks a lot, Kathi |
![]() |
![]() |
![]() |
#4 |
Member
Location: Finland Join Date: Jun 2011
Posts: 24
|
![]()
Following kathi's post, I decided to try running the analysis with an old version of tophat and found the same thing. I ran TopHat 1.3.1 and 1.1.4 on paired end SOLid (50+25bp, about 36m reads) with a GTF file and exactly the same options (--coverage-search -r 131 --library-type fr-secondstrand -F 0.01 -p 16 -i 5 -I 6000 --segment-length 17 --segment-mismatches 1 -m 1 -CQ -a 4).
TopHat 1.3.1: - empty junctions.bed - "Found 0 junctions from happy spliced reads" in reports.log - Reports 41% of F3 reads "with more than one alignment" in bowtie.left_kept_reads.fixmap.log and then 4%,4% & 19% in the _seg* logs - F5 reads are 40% aligned, followed by 7 & 1.6% for the segments TopHat 1.1.4: - junctions.bed is not empty - reports.log says "Found 26222 junctions from happy spliced reads" - F3 reads map 61% initially and F5 reads 40%. I'm not sure what's going on the with segments because the filenames look random and there seem to be two log files per segment with different percentages. My impression, though, is that the values look better (getting as high as 80-90%). These runs were done back-to-back on the same machine using the same data and GTF file; the only thing that changed is the version of Tophat. I'm a bit surprised to see such drastic differences, particularly since I thought v.1.3 is supposed to be better at handling SOLiD. Is there some good reason for this which I'm missing? Should I be doing something different with v. 1.3.1? I'm going to try 1.2.0 now and see how it behaves; hopefully I'll report back about that later today. In the meantime, any suggestions or insight would be greatly appreciated. |
![]() |
![]() |
![]() |
#5 |
Member
Location: Finland Join Date: Jun 2011
Posts: 24
|
![]()
1.2.0 also didn't work well for me; it only found 20 junctions when run with precisely the same options. Based on the .bam file, it also seems to have aligned far fewer reads overall (9m vs. 15m & 19m for 1.3.1 & 1.1.4, respectively), which I find a bit strange. I guess it's possible that something odd happened during the run, but I'm not planning to troubleshoot it; I think I'll just use 1.1.4 for now.
|
![]() |
![]() |
![]() |
#6 |
Member
Location: Finland Join Date: Jun 2011
Posts: 24
|
![]()
One more thing -- in order to get tophat 1.1.4 to run without errors on my colorspace data, I had to replace line 1511 of the tophat script:
Code:
decode_dic = { 'A0':'A', 'A1':'C', 'A2':'G', 'A3':'T', 'A4':'N', 'A.':'N', 'C0':'C', 'C1':'A', 'C2':'T', 'C3':'G', 'C4':'N', 'C.':'N', 'G0':'G', 'G1':'T', 'G2':'A', 'G3':'C', 'G4':'N', 'G.':'N', 'T0':'T', 'T1':'G', 'T2':'C', 'T3':'A', 'T4':'N', 'T.':'N', 'N0':'N', 'N1':'N', 'N2':'N', 'N3':'N', 'N4':'N', 'N.':'N' } Code:
decode_dic = { 'A0':'A', 'A1':'C', 'A2':'G', 'A3':'T', 'A4':'N', 'A.':'N', 'AN':'N', 'C0':'C', 'C1':'A', 'C2':'T', 'C3':'G', 'C4':'N', 'C.':'N', 'CN':'N', 'G0':'G', 'G1':'T', 'G2':'A', 'G3':'C', 'G4':'N', 'G.':'N', 'GN':'N', 'T0':'T', 'T1':'G', 'T2':'C', 'T3':'A', 'T4':'N', 'T.':'N', 'TN':'N', 'N0':'N', 'N1':'N', 'N2':'N', 'N3':'N', 'N4':'N', 'N.':'N', 'NN':'N', '.0':'N', '.1':'N', '.2':'N', '.3':'N', '.4':'N', '..':'N', '.N':'N' } |
![]() |
![]() |
![]() |
#7 |
Senior Member
Location: Canada Join Date: Nov 2010
Posts: 124
|
![]()
I am also getting lots of "Warning: malformed closure" warnings, does anyone know what this means?
|
![]() |
![]() |
![]() |
Thread Tools | |
|
|