Ported from Classic-GATK: CombineGVCFs --convertToBasePairResolution issue

[vdauwera]

Original ticket by @jmthibault79

CombineGVCFs with --convertToBasePairResolution doesn't fully cover the intervals given

I'm trying to create very small files (for NAVS testing) from GVCFs.

An input file has these reference blocks. Let's call them Blocks 1,2,3:

1       10189399        .       A       <NON_REF>       .       .       END=10189558    GT:DP:GQ:MIN_DP:PL      0/0:94:99:46:0,96,1440
1       10190507        .       A       <NON_REF>       .       .       END=10190923    GT:DP:GQ:MIN_DP:PL      0/0:214:99:45:0,105,1575
1       10192376        .       C       <NON_REF>       .       .       END=10192406    GT:DP:GQ:MIN_DP:PL      0/0:14:42:8:0,21,297

This command line with an interval entirely contained in Block 2 produces nothing:

java -jar <GATK> \
-T CombineGVCFs \
-L 1:10,190,850-10,190,889 \
--convertToBasePairResolution \
-V <infile> -o <outfile>

Expanding the interval to overlap portions of Block 1 and Block 3 produces results for Block 2 and the portion of Block 3 which corresponds to my intervals.

It appears that only reference blocks which begin in the supplied intervals are processed.

---

@jmthibault79:
This may be a more general problem with processing GVCFs, and it may also relate to the CombineGVCFs bug @valentinruanorubio is working on.

@vruano:
I suspect that this is rather something to do with the VCF RodBinding processing code not using the END info field to determine whether a record overlaps a position. I guess it relies on the POS value and the length of the REF string to do that. That should be fixed in the (VCF) ROD traversal code. Perhaps we could have a GVCF specific code if it does help.
Also if it were possible to explicitly get the previous record that does not overlap the position programmatically, that would be enough to address this issue. However the other solution above would be cleaner.

@eitanbanks:
To fix this problem the getEnd() method of VariantContext would need to check for the presence of the "END" annotation in the INFO field. However, I'm not sure the INFO field is always decoded at this point (and doing so might be expensive). Could be a complicated fix.

@vruano:
I think this must be moved to hellbender... IMO RoD walkers on VCF files should consider the END info field.

[jmthibault79]

This question was raised in #4 - was it resolved in #164 ?

[akiezun]

@vruano is this a bug?

[akiezun]

assigning to @vruano to clarify is this a bug

[jmthibault79]

This can be described more simply as:

Ensure that intervals in GVCF traversals are END tag aware, so all reference blocks are included correctly. GATK3 considers start position only, so some reference blocks are missed.

[akiezun]

thanks @jmthibault79 so it's a bug.
@vdauwera why is this not scheduled for GATK3? Is it too hard to fix there?

[vdauwera]

@akiezun I don't know that it's necessarily hard; at the time I was migrating issues to github, I was told that these types of issues would be addressed in Hellbender, and that no effort would be put into fixing them in GATK3. I would love to see this fixed in GATK3 of course.

[akiezun]

marking as low prio unless i hear otherwise

[droazen]

Closing as obsolete