<p>I suspect what's happening here is an unfortunate side-effect of making variant-finding algorithms memory-efficient, so that they can work on extremely large populations. By doing the processor-intensive variant calling separately on each individual, calculations can be easily parallelised to run quickly.</p>
<p>For the numbers you have (i.e. 300 children and their parents), there's an alternative approach for generating variant calling that uses all mapped files as input, rather than only one at a time, i.e. instead of running:</p>
<pre><code>bcftools mpileup [options] in1.bam
bcftools mpileup [options] in2.bam
bcftools mpileup [options] ...
</code></pre>
<p>The all-at-once approach has a single mpileup call:</p>
<pre><code>bcftools mpileup [options] in1.bam in2.bam ...
</code></pre>
<p>This will call multiple samples at the same time, so that the output will have identical variant lines for all individuals. It also has the added benefit of getting more information on variation, allowing more rare variants to be identified.</p>
<p>I'm not sure which approach is being used for DRAGEN vs GATK, but I do know that at some stage in the past the GATK standard practice was calling one sample at a time. Curiously, if this were still the case, I'd expect the results to be the other way round, as the one-at-a-time approach tends to be less sensitive.</p>
<p>I guess it's also possible that the pipelines have different sensitivity / specificity tweaks, that could also explain the differences in variant counts.</p>

CC BY-SA 4.0
2022-10-15T09:26:54.033Z
2022-10-15T09:26:54.033Z
gringer
<p>We have 2 vcf (Whole Exome Sequencing (<strong>WES</strong>) data; <strong>germline</strong> samples) files (e.g., <strong>vcf_1</strong> and <strong>vcf_2</strong>). <strong>vcf_1</strong> was generated (Ref. genome: hg38) using the <strong>GATK</strong> pipeline for 250 children and their parents and <strong>vcf_2</strong> was generated (Ref. genome: hg38) using the <strong>DRAGEN</strong> pipeline for another 50 children and their parents (Samples are different). These are raw vcf files and I have not applied any quality-related false positive filters to them.</p>
<p>Now, when we compare the sample-wise SNV counts from <strong>vcf_1</strong> and <strong>vcf_2</strong>, there is a huge difference. <strong>vcf_2</strong> contains on average 4-6 times lesser number of SNVs per sample than <strong>vcf_1</strong>.</p>
<p><strong>N.B:</strong>
I found this article (<a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4418901/" rel="nofollow noreferrer">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4418901/</a>), where it has been reported that the mean numbers of single-nucleotide variants (SNVs) and small insertions/deletions (indels) detected per sample was around 98k, respectively, for WES.  For our case, in the case of GATK-generated vcf samples, this varies from 130k to 188k, and for DRAGEN-generated vcf samples, this varies from 30k to 40k.</p>
<p>I understand both pipelines (GATK and DRAGEN) implement different methods to generate vcf files but is it common/normal to examine that much difference in SNV counts? I would appreciate it if someone can give some explanation (or provide some materials) about it.</p>

CC BY-SA 4.0
2022-10-13T15:59:10.170Z
We need a _lot_ more detail to be able to help. What algorithm was used? What version of the various tools? Are these germline samples or somatic? What species? What kind of sample (WGS, WES, panels)? What filtering options were applied? Please [edit] your question and add more detail.
terdon
CC BY-SA 4.0
2022-10-13T16:18:44.477Z
Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
Community
CC BY-SA 4.0
2022-10-14T08:41:15.590Z
I have updated the question with a few details (WES data, human sample, Ref. genome used: hg38, etc.) as you have mentioned. As soon as I will get some more info about the commands used to generate the vcf files or the version of GATK and DRAGEN, I will update the question further. Many thanks in advance.
App.vsh.io
<vcf><ngs><gatk><snv><wes>
Is it common to get different number of SNVs+Indels across samples from vcf files generated using GATK and DRAGEN (counts are higher for GATK)?
# Is it common to get different number of SNVs+Indels across samples from vcf files generated using GATK and DRAGEN (counts are higher for GATK)?

(Asked by: username_0 on 2022-10-13)

We have 2 vcf (Whole Exome Sequencing (**WES**) data; **germline** samples) files (e.g., **vcf\_1** and **vcf\_2**). **vcf\_1** was generated (Ref. genome: hg38) using the **GATK** pipeline for 250 children and their parents and **vcf\_2** was generated (Ref. genome: hg38) using the **DRAGEN** pipeline for another 50 children and their parents (Samples are different). These are raw vcf files and I have not applied any quality-related false positive filters to them.

Now, when we compare the sample-wise SNV counts from **vcf\_1** and **vcf\_2**, there is a huge difference. **vcf\_2** contains on average 4-6 times lesser number of SNVs per sample than **vcf\_1**.

**N.B:**
I found this article (<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4418901/>), where it has been reported that the mean numbers of single-nucleotide variants (SNVs) and small insertions/deletions (indels) detected per sample was around 98k, respectively, for WES. For our case, in the case of GATK-generated vcf samples, this varies from 130k to 188k, and for DRAGEN-generated vcf samples, this varies from 30k to 40k.

I understand both pipelines (GATK and DRAGEN) implement different methods to generate vcf files but is it common/normal to examine that much difference in SNV counts? I would appreciate it if someone can give some explanation (or provide some materials) about it.

**Tags:** vcf, ngs, gatk, snv, wes
> **Comments:**
> **username_1**: We need a _lot_ more detail to be able to help. What algorithm was used? What version of the various tools? Are these germline samples or somatic? What species? What kind of sample (WGS, WES, panels)? What filtering options were applied? Please [edit] your question and add more detail.  
> **username_2**: Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.  
> **username_0**: I have updated the question with a few details (WES data, human sample, Ref. genome used: hg38, etc.) as you have mentioned. As soon as I will get some more info about the commands used to generate the vcf files or the version of GATK and DRAGEN, I will update the question further. Many thanks in advance.  

---

## 1 answers

### Answer by username_3 on 2022-10-15. Score: 0

I suspect what's happening here is an unfortunate side-effect of making variant-finding algorithms memory-efficient, so that they can work on extremely large populations. By doing the processor-intensive variant calling separately on each individual, calculations can be easily parallelised to run quickly.
For the numbers you have (i.e. 300 children and their parents), there's an alternative approach for generating variant calling that uses all mapped files as input, rather than only one at a time, i.e. instead of running:
bcftools mpileup [options] in1.bam
bcftools mpileup [options] in2.bam
bcftools mpileup [options] ...

The all-at-once approach has a single mpileup call:
bcftools mpileup [options] in1.bam in2.bam ...

This will call multiple samples at the same time, so that the output will have identical variant lines for all individuals. It also has the added benefit of getting more information on variation, allowing more rare variants to be identified.
I'm not sure which approach is being used for DRAGEN vs GATK, but I do know that at some stage in the past the GATK standard practice was calling one sample at a time. Curiously, if this were still the case, I'd expect the results to be the other way round, as the one-at-a-time approach tends to be less sensitive.
I guess it's also possible that the pipelines have different sensitivity / specificity tweaks, that could also explain the differences in variant counts.


---

