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.