Real-world usage of 0x200 failedVendorQualityChecks flag

[jmarshall]

The SAM specification describes the 0x200 flag bit as not passing quality controls (and the pre-LaTeX version of the spec described it as the read fails platform/vendor quality checks).

It also describes it as the filtered bit in §2 (Recommended Practices) when introducing annotation dummy reads:

Annotation dummy reads: These have SEQ set to *, FLAG bits 0x100 and 0x200 set (secondary and filtered), and a CT tag.

In the real world today, do we actually see bad-quality reads in BAM files with their not passing quality controls flags set?

@lh3 recently commented elsewhere that "almost no one uses failedVendorQualityChecks nowadays". Probably the usual practice is for such quality-failed reads to be just omitted from BAM files rather than kept and marked with this flag, and probably this has been the case for quite some time.

Would it be worth repurposing this flag as a general this-read-is-filtered-out flag? This would be as simple as changing the description in the flag bit table, e.g.:

not passing filters, such as platform/vendor quality controls

[lh3]

I support this.

[yfarjoun]

With hiseqX this is true since there are so many failed reads, but with the
non-patterned flowcell machines we keep the failing reads around. I
remember that David Jaffee said that his group looks at all reads,
including the PF failed reads for assembly....

On Fri, May 8, 2015 at 9:39 AM, Heng Li notifications@github.com wrote:

I support this.

—
Reply to this email directly or view it on GitHub
#85 (comment).

[lh3]

John just changed this flag to something more general. It would not cause any compatible issues as far as I see. Broad can still use this flag to mark PF'ed reads.

[nh13]

I support this as well.

[yfarjoun]

Hi, I might be missing something but I couldn't find 0x800 bit definition from the BAM spec in the v3 spec document for CRAM. The flag is included in the code (htsjdk/samtools/cram/structure/CramCompressionRecord.java:41), but not in the document. I presume that this is a typo, but I just wanted to make sure before changing the document. Yossi.

[jmarshall]

@yfarjoun: This is #61, and I'm a bit surprised they still haven't made this seemingly obvious editorial fix…

[yfarjoun]

sorry, I should have checked the issues.

Y.

On Tue, Oct 20, 2015 at 10:37 AM, John Marshall notifications@github.com
wrote:

@yfarjoun https://github.com/yfarjoun: This is #61
#61, and I'm a bit
surprised they still haven't made this seemingly obvious editorial fix…

—
Reply to this email directly or view it on GitHub
#85 (comment).