Tagged with #bug-fixed
0 documentation articles | 4 announcements | 1 forum discussion


No posts found with the requested search criteria.
Comments (0)

This is not exactly new (it was fixed in GATK 3.0) but it's come to our attention that many people are unaware of this bug, so we want to spread the word since it might have some important impacts on people's results.

Affected versions: 2.x versions up to 2.8 (not sure when it started)

Affected tool: SelectVariants

Trigger conditions: Extracting a subset of samples with SelectVariants while using multi-threading (-nt)

Effects: Genotype-level fields (such as AD) swapped among samples

This bug no longer affects any tools in versions 3.0 and above, but callsets generated with earlier versions may need to be checked for consistency of genotype-level annotations. Our sincere apologies if you have been affected by this bug, and our thanks to the users who reported experiencing this issue.

Comments (0)

As reported here, a bug was found in VariantsToBinaryPED. Briefly, VariantsToBinaryPed expected the fam file to describe the samples in the same order as the input VCF file: if they were not in the same order, it did not correctly map sample IDs with the genotypes in the output binary PED.

We expect that in most use cases, the order would be the same (because PLINK uses lexicographic order, as does the GATK), so the bug would not impact results. However, as the user report demonstrates, in cases where order was different, the bug would seriously impact results.

We therefore recommend that anyone who has used VariantsToBinaryPED check their results for any inconsistencies in the kinship coefficients. Our apologies for the inconvenience to anyone who is affected by this bug, and big thanks again to user TimHughes for reporting the bug.

Finally, we have fixed the bug in GATK and released the fixed version under version number 2.7-4.

Comments (6)

As reported here:
http://gatkforums.broadinstitute.org/discussion/comment/4114#Comment_4114

If you encounter this bug too, please don't post a new question about it. Feel free to comment in this thread to let us know you have also had the same problem.

Thank you for your patience while we work to fix this issue.

Update: the "Bad likelihoods detected error" is fixed in the latest version.

Comments (0)

We have received reports of a bug occurring with HaplotypeCaller in v2.4, with the error message "Reads are too small for use in assembly." We are working to fix it.

In the meantime, if you encounter it too, please don't post a new discussion about it, but do post a comment on this announcement so that we can count how many people are affected.

Thank you for your patience and our apologies for the inconvenience!

UPDATE: This is fixed as of version 2.4-7.

Comments (3)

Hi,

I used the UnifiedGenotyper (GATK 1.6) on a multi-sample set to call variants, and for some of the positions I get multiple mutated alleles. The genotype entries in the combined VCF file look like (GT:AD:DP:GQ:PL):

0/1:94,11,0:124:22.18:22,0,2485,209,2500,2709

0/2:27,0,54:81:99:1651,1726,2695,0,968,836

so it's three AD values per entry. Running SelectVariants yields the following line for the second example from above:

GT:AD:DP:GQ 0/1:27,0,54:81:99

Although it changed the genotype from 0/2 to 0/1, it did not update the AD field. I checked the forums, but I could not really find anything discussing specifically the update of AD, except for the GATK 2.2 release notes where it says SelectVariants: "Fixed bug where the AD field was not handled properly. We now strip the AD field out whenever the alleles change in the combined file."

I was wondering whether you could confirm if cases like the one above would benefit from the bugfix, or if the bug description applies to something else.

Thanks a lot for all your hard work, Markus