HI!
Since I have learned that the genotype quality -1 is a "bugg", can we replace it with VAF?

Best Regards, Hero
This happens when the VCF doesn't have the GQ Phred genotype quality field. Does it happen in all cancer cases?
@hassanfa ?
So far, Id say yes: we are not using GATK for variant calls, so the primary quality measure is no longer called GQ...
This is exactly the change we did on the general cancer report end of last year, so should be fine.
Though, actually here we already have AD next to it, so its more about just not showing GQ if == -1 perhaps, and possibly add a fraction to the AD counts as per the case and variantS pages.
@northwestwitch yes, all cancer cases have a GQ value of -1. But can we replace GQ quality with VAF? or maybe add a field for VAF (if GQ value can be incorporated )?
I'll remove GC and add VAF, and also include the AF fractions near the samples ADs
I'll remove GC and add VAF, and also include the AF fractions near the samples ADs
I've just realized that the 2 things are the same thing so I'll display it the same way as in the general report.
This happens when the VCF doesn't have the GQ Phred genotype quality field. Does it happen in all cancer cases?
True. There is no GQ in any of the BALSAMIC calls.
Do we want this change also in the case report right? Because I could include the fix there as well!
@northwestwitch Yes please :)
For the cancer cases we did that in the #2257? Or where did you mean? 馃槉
Right! I have the memory of a goldfish 馃槅
But doesn't look like it's working for all cancer variants, look for instance that TP53 variant we recently included in the demo:
http://localhost:5000/

Another thing, I've included the VAF on the variants page when the variant is a SNV, but I see that when you created #2257 you are also including the VAF for SVs, shouldn't we do the same in the normal SVs pages?
Ah, right, I might have done exactly the same with not repopulating the object? But, no, it is showing "N/A" instead of getting it wrong? I think that was rather because that line is from a different caller. In my db instance at least it didn't get a proper AD on the individuals either. I kind of guess the fix for that is rather on load - allowing different representations - or as with this PR, doing better examples in the first place. 馃槉 We could add depths to that variant in the VCF as well, and verify that it works, and even better make sure it actually works with a current Balsamic case?
@dnil @northwestwitch sorry, but now I am a bit lost.. Should I be attentive of the reports from now on and let you know if this doesnt work?
Always be attentive, and report everything that looks suspicious! 馃槈
But don't worry too much - the picture is from the development branch and with fake test data. Also we treat these threads much like if it was a common office with a closed door. In actual production code we typically end up with a more calm and sensible product. 馃槅
We will double check a few recent cases as well.
@heronikdin sorry I was a bit lost as well when I wrote that comment. But I think we're good, since the error I see is only present in a variant we are using to test stuff locally. The problem is that we kind of forced the variant in the configuration and some parameters are missing. But no worries you shouldn't see anything weird on the report of real cases!
Most helpful comment
@heronikdin sorry I was a bit lost as well when I wrote that comment. But I think we're good, since the error I see is only present in a variant we are using to test stuff locally. The problem is that we kind of forced the variant in the configuration and some parameters are missing. But no worries you shouldn't see anything weird on the report of real cases!