SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



Similar Threads
Thread Thread Starter Forum Replies Last Post
htseq-count error RNAME == '*' although flag bit &0x0004 cleared" super0925 Bioinformatics 7 04-30-2016 10:16 AM
16 bit image cmccabe Bioinformatics 3 11-07-2014 06:26 AM
Unable to find flag in SAM with bowtie2 - but can with BWA yekwah Bioinformatics 3 10-18-2013 08:20 AM
Tophat2 in strand-specific mode: discrepancy between 0x10 bit and XS flag Amelie RNA Sequencing 0 01-05-2013 05:57 AM
Bowtie2 chokes on -a flag? kgulukota Bioinformatics 3 02-09-2012 09:20 AM

Reply
 
Thread Tools
Old 07-18-2016, 08:55 AM   #1
KamilSJaron
Junior Member
 
Location: Switzerland

Join Date: Apr 2016
Posts: 7
Lightbulb bowtie2 bit 2 of the flag

Hello,

I am wondering what does mean "The second bit (2 in decimal, 0x2 in hexadecimal) is set if the read is part of a pair that aligned in a paired-end fashion."

I have mate pair reads mapped with following entries in sam:

Code:
H8:C19M1ACXX:5:1101:6777:2322   97      Sc_hox  1694486 42      101M    =       1691781 -2806   AGCCGGGCTGGAGCTTACCTGGCTGACAGGAACTTCTCTGGCTAGCATATACGATTTTCGGTGCACCGTGTAGATCTGCTTGGAGATTACTAGTAAGTGTC   CCCFFFFFHHHHHJJJJJJHGHJJJIIIIJIIJIIJJJJIIJJJIJJJJJIIJGIIIJGHHHFFFEE>;A?CCDDDDCCDDDB:CCDCCACCCCBCB?ACD   AS:i:-10        XN:i:0  XM:i:2  XO:i:0  XG:i:0  NM:i:2  MD:Z:93G0G6     YS:i:0  YT:Z:DP
H8:C19M1ACXX:5:1101:6777:2322   145     Sc_hox  1691781 42      101M    =       1694486 2806    TACTGCTGAAGGCAATATTAGTTCCCCTCACAATGCGAAACTAATGTTATAGATTATATTGAAAACTCATTGGTACTGTAAACTATATCATAAACATAGTA   CDDDDCDEEEEEEEFFFFFFHHHIIIJJJIHJJIJIIJJHJJIJJIIJIHHIJJJIJIIJJJIGHFJIIJJJJJGJJJJJJJJJJJJJHHHHHFFFFFCCC   AS:i:0  XN:i:0  XM:i:0  XO:i:0  XG:i:0  NM:i:0  MD:Z:101        YS:i:-10        YT:Z:DP
Bitflags of those reads in binary formats are (from left to right 1 2 4 8 16 32 64 128)

1 0 0 0 0 1 1 0
1 0 0 0 1 0 0 1

It seems that both reads are well aligned (full length), they are bout 3k from each other, they are on other strains...

The only thing I can not understand is, why it has not bit 2 activated, because everything else looks fine to me...

Cheers
KamilSJaron is offline   Reply With Quote
Old 07-18-2016, 10:52 AM   #2
dpryan
Devon Ryan
 
Location: Freiburg, Germany

Join Date: Jul 2011
Posts: 3,480
Default

Bit 2 denotes aligning as a "proper pair according to the aligner". Firstly, the alignments point away from each other. Secondly a 3kb fragment size is about 6-10x wider than expected. Are these mate-pair alignments? If so, you'll need to tell the aligner that.
dpryan is offline   Reply With Quote
Old 07-18-2016, 11:06 AM   #3
KamilSJaron
Junior Member
 
Location: Switzerland

Join Date: Apr 2016
Posts: 7
Default

Quote:
Originally Posted by dpryan View Post
Bit 2 denotes aligning as a "proper pair according to the aligner". Firstly, the alignments point away from each other. Secondly a 3kb fragment size is about 6-10x wider than expected. Are these mate-pair alignments? If so, you'll need to tell the aligner that.
Cheers Ryan!

Yes, these are mate-pairs (That is why I expected this insert size). Is it really important for mapper to know that the library is mate-pair library? It is already post-processed - therefore only difference to pair-end library is the insert size...

I have not realized before, that they do not point to each other. If this is the reason, what is the interpretation of this observation? Because there are about half of pairs without flag 2 (I have to check if all of them are pointing away from each other)
KamilSJaron is offline   Reply With Quote
Old 07-18-2016, 11:11 AM   #4
dpryan
Devon Ryan
 
Location: Freiburg, Germany

Join Date: Jul 2011
Posts: 3,480
Default

For mate-pairs it's expected that alignments point away from each other and have long insert sizes. Just make sure not to filter these out during a down-stream analysis step.
dpryan is offline   Reply With Quote
Old 07-18-2016, 03:52 PM   #5
KamilSJaron
Junior Member
 
Location: Switzerland

Join Date: Apr 2016
Posts: 7
Default

You are right. Twice.

Mate-pair indeed should, be pointing out from each other, but this is not the problem. And here comes, why you were right twice - bowtie thought that I have pair-end reads, therefore he considered correct the fraction of reads close to each other pointing out to each other.

So when I have plotted histogram of insert sizes, I found that all correct reads (with flag 2) have very small insert size and those, which have small insert size and still do not have flag 2, they are pointing out from each other (mate-pair orientation) https://plus.google.com/u/0/10778698...81109861311357

So my ultimate explanation is, that I just have poorly prepossessed mate-pairs, because about half of them are in fact just pare-end reads (i.e. they probably just had trimmed adapter from one of the outer sides).
KamilSJaron is offline   Reply With Quote
Old 07-18-2016, 05:57 PM   #6
Brian Bushnell
Super Moderator
 
Location: Walnut Creek, CA

Join Date: Jan 2014
Posts: 2,707
Default

What kind of reads are these? Nextera LMP libraries, for example, are expected to produce a substantial fraction of short inserts, and those reads need to be specially processed first. If processed correctly, the long- and short-inserts will not end up in the same file.
Brian Bushnell is offline   Reply With Quote
Old 07-19-2016, 12:44 AM   #7
KamilSJaron
Junior Member
 
Location: Switzerland

Join Date: Apr 2016
Posts: 7
Default

Brian, yes, I guess so, given the fraction of short insert sizes with convergent orientation. There reads were trimmed (and qc looked good), therefore I expected that the facrtion of short inserts is filtered already - apparently it is not.

Mystery is solved, Thanks again Ryan.
KamilSJaron is offline   Reply With Quote
Reply

Tags
bowtie, flag, mapping, sam

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 04:08 AM.


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