Why is pileups.table empty when running GetPileupSummaries?
REQUIRED for all errors and issues:
a) GATK version used:gatk4-4.4.0.0-0
b) Exact command used:gatk GetPileupSummaries -I xx.bam -V somatic_hg38_af-only-gnomad.hg38.vcf.gz -L somatic_hg38_af-only-gnomad.hg38.vcf.gz -O pileups.table
c) Entire program log:Entire program log: Runs with no errors, but gets an empty result. And I did it in tumor-only mode. Only five lines of content are shown, which are contig，position，ref_count ，alt_count，other_alt_count ，allele_frequency. The reference genome was downloaded from the URL(https://console.cloud.google.com/storage/browser/genomics-public-data/resources/broad/hg38/v0) and the somatic_hg38_af-only-gnomad.hg38.vcf.gz file was downloaded from the URL(https://console.cloud.google.com/storage/browser/gatk-best-practices/somatic-hg38) . Is it an input error in my vcf.gz file? I would also like to ask if I need to mark duplicates when calling from the compared bam file, or do I just use the compared bam file? Can you tell me how to deal with it ? Thank you very much!
-
Hi 昨日旧梦
Can you check if your bam file is actually intact and has reads where you need them to be? The af-only-gnomad.hg38.vcf.gz file contains common germline variant sites for checking pileup information. Can you check if your bam file has reads covering those variant sites as well?
Regards.
-
How would one go about this? I am having the same issue. I have both called .vcf files and .bam files generated using references downloaded by references from the Broad Institutes cloud storage. For PON I used af-only-gnomad.hg38.vcf downloaded from the same website the OP used (Broad managed server). My setup sounds like the above, with the code below:
gatk GetPileupSummaries -I Test.bam -V af-only-gnomad.hg38.vcf -L af-only-gnomad.hg38.vcf -O Test.pileups.table
But my output is identical to what the OP has.
-
We recommend using a smaller VCF, the file small_exac_common_3.hg38.vcf.gz in the same google bucket as our AF-only gnomAD resource.
It's possible that the sheer size of the gnomAD file being used as intervals caused a memory error, but I don't think this is the case. Still, it's worth trying again with the correct file. Other than that the command is fine and it would be worth looking at the BAM in IGV to see if it has coverage at the given sites.
Please sign in to leave a comment.
3 comments