# Interpreting 0x200 flag in bwa-mem alignments

I am looking at the bwamem.h code in http://github.com/lh3/bwa and found that BWA-MEM will give flag 0x200 to what it calls MEM_F_SOFTCLIP:

#define MEM_F_PE        0x2
#define MEM_F_NOPAIRING 0x4
#define MEM_F_ALL       0x8
#define MEM_F_NO_MULTI  0x10
#define MEM_F_NO_RESCUE 0x20
#define MEM_F_REF_HDR   0x100
#define MEM_F_SOFTCLIP  0x200
#define MEM_F_SMARTPE   0x400
#define MEM_F_PRIMARY5  0x800
#define MEM_F_KEEP_SUPP_MAPQ 0x1000


But looking at the explanation in this website: https://broadinstitute.github.io/picard/explain-flags.html

It labels 0x200 as read fails platform/vendor quality checks.

If we have reason to believe that soft clipping can happen for some of the alignments, should we just ignore the fact that IGV calls this fail QC? Does the failQC tag come from the SAM/BAM specification or is this something IGV came up with?

The SAM/BAM specification labels 0x200 the same way as the Picard flag explaining website:

The question remains as to why BWA-MEM uses the 0x200 flag for softclipping notation rather than Fail QC.

bwa mem is using exactly the same meaning of the 0x200 flag as every other program, including picard. Don't blindly assume that that entry in the header file relates to the output flags in the SAM output. If you search the code, you'll see that bwa is using this internally as a flag for "this alignment is soft-clipped", which it handles differently for primary and secondary alignments (hard-clipping the latter).

For what it's worth, bwa mem (at least the version I just tried) doesn't set the QC failed flag. This behavour is actually pretty common among aligners, since Illumina has changed how they represent QC failure at least once.

• I don’t understand this answer, as I think you’re contradicting yourself: you say that BWA-mem handles 0x200 “as every other program, including picard”, implying that it uses it for failed platform/vendor QC. But then you go on to say that it uses it for soft-clipped alignments (exactly as implied by the name in the header!). Well, which is it? Dec 4 '17 at 15:22
• If it sets it then it has the same meaning. I just don't know off-hand if it sets it at all. Dec 4 '17 at 15:23

The connection between soft clipping and a read level flag is interesting. Soft clipping occurs at a per base level and is denoted in the CIGAR string. The failQC flag is applied to a read and usually comes directly from the sequencer. It is likely that BWA just named their internal var weird.

Does the failQC tag come from the SAM/BAM specification or is this something IGV came up with?

The failQC flag is part of the Sam Spec.

If we have reason to believe that soft clipping can happen for some of the alignments, should we just ignore the fact that IGV calls this fail QC?

If you expect soft clipping I would suggest trimming that sequence from the reads prior to alignment. Also you can look at read in the input reads and see if the failQC flag is set prior to alignment to understand where it is getting set. IGV is just displaying what is in the BAM file not making any decisions about those reads.

• I wouldn't so much say that the variables are oddly named so much as it shows from the bit usage for flags (be they internal or external) that the same author wrote both bwa and SAM. Dec 4 '17 at 15:25