Weird TopHat - junction.bed output

[repinementer]

Does any one know about the (snapshot attched)

blue-refseq
green- cuff transcripts
red- junctions

1. exon junctions (junction.bed) overlapping none of the refseq exons or Cufflinks transcripts.

2. exon junctions overlapping introns but not any cuff transcripts ?

[repinementer]

another snapshot

another snapshot

[Dethecor]

better resolution plz . . . can't see a damn thing on those snapshots :/

[repinementer]

hey

I submitted a good resolution file but this website is showing them that. Anyways here are zipped pictures.

[ECO]

Sorry about that resizing. I've turned it off, and am testing it now.

[john_mu]

I may help to also display the SAM file in IGV so you can see where the reads are aligning.

[repinementer]

Thank you

IGV is freezing just after uploading sam file. It would be great if you suggest any other browser so that I can put them along. So far as per discussion in seq answers IGV has a reputation going on.

[john_mu]

You should convert the SAM file to a BAM file for input into IGV.

It does require a lot of memory if you have a large number of reads. That could be why it is freezing.

[repinementer]

still the same

I used coverage.wiggle files instaed of SAM/BAMfile to notify read density or coverage.

I came to a conlclusion TopHat producing many false positive because of the 32 bp read length?

I'm including other snapshots where junctions mapped to introns instead of exons and with out any read coverage.

[bgibb]

similar, even with --no-novel-juncs option

I've found a few unexpected junctions from TopHat, even when using the --no-novel-juncs option. Attached is an example. UCSC gene, mRNA and exon records were specified in a gff3 file (with the -G option). And I checked the gff3 file carefully to ensure there were no boundaries specified near the bottom two unexpected junctions.

blue -- RefSeq
red -- junctions reported by TopHat with --no-novel-junctions option

TopHat-1.0.14
Bowtie-0.12.5
76bp reads

[repinementer]

Yes same observed in my analysis.

After supplying known ensemblegenes.gtf and ensemble_junctions and --no-novel-juncs I observed few cases where I have seen exactly you mentioned.
Seems it is still giving false postives by taking the reads into consideration.

BTW how did you directly uploaded sam file into IGV?

[bgibb]

SAM files and IGV

I had some problems with the Linux version of IGV, but the Windows version seems to work OK. I'm using the binary distribution, version 1.5.18.

After filtering, my accepted_hits.sam file size is 2.7 GB. I leave the SAM file header in place.

[Jim Robinson]

Samfiles and IGV

Hi, I just found this thread while looking for something else. I can answer a few questions.

You can load a SAM file into IGV, but it needs to create an index first. It will do this automatically after a warning, or you can do it in advance with "igvtools". BAM is better, but SAM works.

I hate to hear about freezes. Recently I added a coverage depth limit, user settable, which has solved most freezing issues. Also, for large wig files please check out the "tdf" format, easily created from igvtools (command line or File > run igvtools...). Its basically a bigwig, developed before bigwig was available or I would have just used bigwig. Also, for bed files exceeding ~ 100,000 rows or so please consider indexing them, you will be happier. Again use igvtools for this (or tabix). If you use the binary and indexed formats you can load an really large dataset quickly, and without freezing.

Finally send bug reports and complaints to igv-help at broadinstitute.org. I'll answer them, but I don't always have time to monitor these forums unfortunately.

[repinementer]

I tried index format but ntworking

I converted file.bam to to file.bam.bai by using samtools.
And i tried to open file.bam.bi index file using IGV. It throwing by saying SAM/BAM index files are not supported ?

[Jim Robinson]

BAM files in IGV

Open the BAM file, not the index. Sorry if the message is confusing, I'll work on that.

To elaborate a little, samtools does not convert the bam file, it just creates an index in a separate file. The alignment data is still in the original file. IGV (and other tools like samtools tview) look for the index by naming convention, but you don't explicitly load it.