-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output from truvari bench command #147
Comments
Details on the summmary.json can be found here. The '__filtered' counts are calls inside the vcf which weren't compared due to parameters like |
From the log file, I could see that I have used the default parameters.
So, using bcftools, I filtered the variants below 30 bp from comparison vcf dataset and there were 18677 variants
Similarly, I filtered the variants below 50 bp and ended with vcf dataset of 28838 variants in the benchmark dataset. When I exclude these variants from 51064-28838=22226 in base data and 50245-18677=31568 in comparison data. But, I see from the filter applied in the log file, these numbers are different. It is 22213 number of variants in the base vcf and 31471 in comparison vcf Thank you |
Without access to the files, I cannot say for certain what might be happening. Unfortunately, all I can do is explain what the code is doing: The 'chunker' is the first method to manipulate the data-flow. See here. On line 299, you can see the chunk will add monomorphic reference sites to the __filtered variants which wouldn't have been caught by the bcftools query. Monomorphic reference sites are loci without an ALT allele generally found in gVCFs. They give rise to |
Why there is a reduction in call count in the comp file as shown in above output. For example, in the above output, comp is 31471 and changes to call-count as 21347. But the base-count remains the same. Thank you |
This is due to the difference between |
I understand that these two parameters are applied and we have reduced number of variants to analyse, here it is 31471 variants compared to base variants, 22313. In the genotype concordance step, again --sizemin and --sizefilt is applied?. If so, why. The number of calls would be the same when comparing the number of variants to the truth set as well as when estimating the genotype concordance between truth set and comp set. Why there is reduction in the number of variants at these two steps?. |
The total number of genotypes compared is 20,064. Genotype concordance is its own measurement different from precison/recall/etc. Think of it as two thing being measured - how many variants are matching, how many variants have the same genotype. In the code we first count the base/comp calls and second, for the calls which have a match, we compare their genotypes. FN/FP variants don't have a counterpart genotype to which they can be compared. Their only option is to count every FN/FP as having an incorrect genotype, which would increase the genotype concordance denominator in the formula from (matching-genotypes / total-matches) to (matching-genotypes / (total-matches + FN_count + FP_count) and thus lower the genotype concordance. Since we want genotype concordance to be an estimate of how correct the caller's genotyping is, we don't want the assumption in the second calculation which is that every FN/FP variant has an incorrect genotype. For details on the output summary's calculations, see https://github.com/ACEnglish/truvari/blob/develop/truvari/bench.py#LL228C18-L228C18 and https://github.com/ACEnglish/truvari/blob/develop/truvari/utils.py#L380 |
Thank you for the vivid explanation and it is clear from the script. I just want to clarify one last thing. Initially there were 31471 variant calls and among these 20064 were true positives and 1283 were false positives. False positives are calls present in base (truth) data and not in comp data. Is it right? |
This is incorrect. Base or 'gold standard' or truth counts are TP-base, False Negative. Comparison or test counts are TP-comp, False Positive. So a 'known truth' call missing from 'test' calls is falsely negative. A 'test' call errantly present is falsely positive. See https://en.wikipedia.org/wiki/Sensitivity_and_specificity for even more details. |
Thank you, it makes sense to me. Initially there were 31471 test calls and among which 20064 are TP and 1283 are FP calls. So, what about the remaining calls, 31471-21347=10,034 calls. |
See #147 (comment) 😄 |
Okay. I understand after reading that calls get filtered based on size min and PASS parameters. Comp calls were 31471 and call-cnt is 21347. 31471 calls were from applying the filters to the initial 50245 calls (size-min and size-filt) . 21347 call cnt was true positives and false positives (not matched with base and calls matched with base). Remaining calls (10034) were not called as they did meet the parameters such as pctseq, pctsize. Hope I understood it right this time Thank you |
That sounds correct. The other, simpler answer, is to ignore the numbers printed separately on To summarize the
|
Hello
I used pbsv tool (https://github.com/PacificBiosciences/pbsv) to do structural variant calling for the HG002 dataset using GRCh38 reference genome build. I downloaded the benchmark HG002 vcf dataset from PacBio link to see if the variants called using the pbsv tool were also found in the downloaded benchmark HG002 vcf dataset. For this purpose, I used the truvari --bench command.
After running, I got this output:
What is the filtered number of variants?. In the above output, it is given as 47625.
What is call_cnt?
Can you explain the gt_matrix?
Thank you
The text was updated successfully, but these errors were encountered: