BUG: AllelesLikelihoods.addEvidence(X, 0.0) can result in new evidence X be given arbitrary likelihoods.

[vruano]

Instructions

Bug Report

Affected tool(s) or class(es)

• tools: HaplotypeCaller perhaps Mutec.
• classes: AlleleLikelihoods

Affected version(s)

• [ X] Latest public release version [version?]
• [ X] Latest master branch as of [date of test?]

Description

Right before calling annotators HC engine adds filtered reads as additional evidence in the AlleleLikelihoods instance that is passed down to the annotators. The code requests the new evidence to have 0.0 likelihoods so label them as uninformative. However due to an error in how the lk arrays are "extended" inside the AlleleLikelihoods these reads inherit past reads (removed) zombie likelihoods instead.

Fix is easy. as simple as remove this enclosing if in AlleleLikelihoods, and simply executed its body
always:

line 793:
if (initialLikelihood != 0.0) // the default array new value.
        {
            for (int a = 0; a < alleleCount; a++) {
                Arrays.fill(sampleValues[a], sampleEvidenceCount, newSampleEvidenceCount, initialLikelihood);
            }
        }

Steps to reproduce

Debug and active region with filtered reads.

Expected behavior

Those reads won't contribute to AD or DP.

Actual behavior

They do contribute, at random, to those count annotations.

[vruano]

@ldgauthier should be aware of this. This bug may not only affect AD or DP all this time but also other annotation that make their decision on whether to consider a read or not based on the informativeness. e.g
SB test does.

[vruano]

Have a PR to fix it #7154

[vruano]

Fix has been merged.