htslib internals: question about storage of GLs in bcf_fmt_t records

Open

#302 opened on Nov 18, 2015 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 3/5
Estimated time: 1-2 days
Newbie friendliness: 25/100

Issue type: Bug
Clarity: Needs clarification
Activity status: Stale
Tech stack: c
Domain: bioinformatics

Research direction

Start with htslib/vcf.h:143 and the bcf_fmt_t definition, then trace how PL values are represented through myFMT->p. Verify whether type==2 and the observed zero interleaving are expected, and identify any documented field or invariant that explains the layout. Done means providing a verified interpretation of the storage and whether callers must skip values.

Written by the indexing model from the issue text.

Description

question

I have some phred scaled GLs stored in a BCF with format header:

##FORMAT=<ID=PL,Number=G,Type=Integer,Description="List of Phred-scaled genotype likelihoods">

I have managed to get a pointer to a bcf_fmt_t struct for these GLs as described in the header file htslib/vcf.h:143. Let's call the pointer myFMT. myFMT->type == 2 tells me that the GLs are stored as INT16's. So I have cast myFMT->p to an INT16, found the start of my GLs, and proceeded to read the GLs in increments of two bytes. What I find is that only even numbered INT16's contain my data, and that odd numbered INT16`s are zero. That is,

p + offset // first data point
p + offset + 1 == 0
p + offset + 2 // second data point
p + offset + 3 == 0
// etc

Is this a bug, or expected behavior? If expected behavior, is there an attribute in bcf_fmt_t that hints at the fact that every second piece of data should be ignored?

Thanks.

Dominant language: C
Stars: 950
Forks: 475
Avg merge: 3d 13h
Merged PRs (30d): 11

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.