SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



Similar Threads
Thread Thread Starter Forum Replies Last Post
tophat 1.3.0 bug?? peromhc Bioinformatics 16 06-18-2011 04:12 AM
bug for the tophat 1.3 beta liuxq Bioinformatics 4 06-09-2011 11:25 AM
TopHat bug telos Bioinformatics 0 03-17-2010 08:50 AM
Tophat Bug? jling Bioinformatics 0 02-11-2010 04:14 PM
Bowie12Beta mapping direction restriction or bug? arthur.yxt Bioinformatics 0 12-27-2009 07:23 AM

Reply
 
Thread Tools
Old 11-11-2011, 03:12 AM   #1
cedance
Senior Member
 
Location: Germany

Join Date: Feb 2011
Posts: 108
Default tophat mapping bug?

Hi,
I work on alternative splicing with RNA-Seq data. Recently, while mapping reads using Tophat version 1.31 in order to characterize exon skipping events, I found a peculiar problem. I have tried to summarize the issue with this figure:

The problem is this: Most of the times, when the last segment is less than 10 bases (during segment match), tophat allows for a default of up to 2 mismatches for each segment and so this small segment also gets 2 mismatches. Consider the scenario where the last segment is 4 bases = GTTG, as shown in the figure. The read clearly matches the correct exon (with no skipping), but in both cases, tophat maps with 1 and 2 mismatches leading to an exon-skipping event. In this particular case, I had around 1000 such reads exon skipped out of about 10000+ reads that mapped normally across these exons (no skipping).

1) Is this a bug? Have you experienced this issue? If so, how did you get around this issue?

I have two things in mind to get around this issue:
1) I am planning to take all these "special" events or junctions that are not in the annotation and then look for the start and end junctions (as to which genes they map to) and then look if the "current" end matches any of the other exons in the current gene. The good thing is that this can help with any software. However, its laborious as you have to check fasta sequences for every such read.
2) Another way is to run tophat initially with 0 segment mismatches and then obtain the unmapped reads and convert them to FASTQ again and then map again with 1 mismatch and then do the same for 2 mismatches. I am not sure if this will help though.

I'd appreciate any thoughts on this. Thank you.
cedance is offline   Reply With Quote
Old 11-11-2011, 08:25 AM   #2
damiankao
Member
 
Location: UK

Join Date: Jan 2010
Posts: 49
Default

Tophat first maps reads to get coverage islands and produce a potential junction database. It then maps against these potential junctions. Then to find smaller exons, it does the segmentation mapping.

Perhaps the first potential junction finding found the skipped exon junction only. It then mapped the reads that should have mapped to the non-skipped exon to the skipped exon junction. Those reads are now mapped, so not used in the segmentation mapping. Maybe that's why you are finding these weird mappings.

*edit
I might be wrong. I just read from the manual that:
"TopHat solves this problem by splitting all input reads into smaller segments, and then mapping them independently"

I guess it does segmentation mapping with all reads, not just reads that were left over from initial mapping.
damiankao is offline   Reply With Quote
Old 11-11-2011, 08:56 AM   #3
cedance
Senior Member
 
Location: Germany

Join Date: Feb 2011
Posts: 108
Default

damiankao, thank you for your reply. Even then, as I mentioned, I have > 10000 reads for this particular position which are rightly placed and around 1000 reads where they are wrongly skipped. I guess by what you say, it should have mapped all to the exon-skipped portion, no?
cedance is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 08:17 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO