The current GATK version is 3.7-0
Examples: Monday, today, last week, Mar 26, 3/26/04

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Get notifications!

You can opt in to receive email notifications, for example when your questions get answered or when there are new announcements, by following the instructions given here.

Formatting tip!

Wrap blocks of code, error messages and BAM/VCF snippets--especially content with hashes (#)--with lines with three backticks ( ``` ) each to make a code block as demonstrated here.

Jump to another community
Picard 2.9.0 is now available. Download and read release notes here.
GATK 3.7 is here! Be sure to read the Version Highlights and optionally the full Release Notes.

Can I use GATK on non-diploid organisms?

delangeldelangel Broad InstituteMember Posts: 71
edited October 2014 in FAQs


In general most GATK tools don't care about ploidy. The major exception is, of course, at the variant calling step: the variant callers need to know what ploidy is assumed for a given sample in order to perform the appropriate calculations.

Ploidy-related functionalities

As of version 3.3, the HaplotypeCaller and GenotypeGVCFs are able to deal with non-diploid organisms (whether haploid or exotically polyploid). In the case of HaplotypeCaller, you need to specify the ploidy of your non-diploid sample with the -ploidy argument. HC can only deal with one ploidy at a time, so if you want to process different chromosomes with different ploidies (e.g. to call X and Y in males) you need to run them separately. On the bright side, you can combine the resulting files afterward. In particular, if you’re running the -ERC GVCF workflow, you’ll find that both CombineGVCFs and GenotypeGVCFs are able to handle mixed ploidies (between locations and between samples). Both tools are able to correctly work out the ploidy of any given sample at a given site based on the composition of the GT field, so they don’t require you to specify the -ploidy argument.

For earlier versions (all the way to 2.0) the fallback option is UnifiedGenotyper, which also accepts the -ploidy argument.

Cases where ploidy needs to be specified

  1. Native variant calling in haploid or polyploid organisms.
  2. Pooled calling where many pooled organisms share a single barcode and hence are treated as a single "sample".
  3. Pooled validation/genotyping at known sites.

For normal organism ploidy, you just set the -ploidy argument to the desired number of chromosomes per organism. In the case of pooled sequencing experiments, this argument should be set to the number of chromosomes per barcoded sample, i.e. (Ploidy per individual) * (Individuals in pool).

Important limitations

Several variant annotations are not appropriate for use with non-diploid cases. In particular, InbreedingCoeff will not be annotated on non-diploid calls. Annotations that do work and are supported in non-diploid use cases are the following: QUAL, QD, SB, FS, AC, AF, and Genotype annotations such as PL, AD, GT, etc.

You should also be aware of the fundamental accuracy limitations of high ploidy calling. Calling low-frequency variants in a pool or in an organism with high ploidy is hard because these rare variants become almost indistinguishable from sequencing errors.

206 x 180 - 21K
Post edited by Geraldine_VdAuwera on


  • marcustukemarcustuke Member Posts: 1

    As GATK2 can handle Mitochondrial DNA, is there a recommended ploidy setting for human Mitochondria? I understand that mtDNA can vary dramatically in how many copies are present in a cell, but is there some sort of consensus value? (e.g. some sort of function of mean coverage)

    Thank-you very much!

  • delangeldelangel Broad InstituteMember Posts: 71

    We've experimented with 50 to 100 but we make no optimality claims on that - probably a better number would be the ratio of (mean coverage in the MT contig) / (mean coverage in somatic chromosomes)

  • mike_lyonsmike_lyons Member Posts: 3

    @delangel are there any other recommended settings for MT with GATK?

  • sahiilsethsahiilseth Member Posts: 3
    edited September 2012

    How does UG use this ploidy information for calling variants in MT? For SNPs at any position we dont expect more than 4 alleles (ATGC).
    In our low-pass data we have 5-7X coverage overall, and ~700X in case of mitochondria.

  • delangeldelangel Broad InstituteMember Posts: 71

    It's internal machinery needs to know the organism ploidy (i.e. number of chromosomes inside) to work well (btw number of possible different alleles is different than ploidy). Given your coverage I'd start with -ploidy 100 or so

  • kjclowerskjclowers UW MadisonMember Posts: 14

    What if I want to do multi-sample SNP calling using the unified genotyper on a mixture of haploid and diploid organisms? I have many yeast genomes where most are haploid, but a few are diploid. Will I have to call variants on the two groups separately?

  • SheilaSheila Broad InstituteMember, Broadie, Moderator Posts: 4,723 admin



    You will need to run the UnifiedGenotyper separately for the haploid and diploid genomes. You have to specify which ploidy the UG should expect for each group in your command line, so unfortunately you cannot run a mixture of ploidies.


  • tommycarstensentommycarstensen United KingdomMember Posts: 404 ✭✭✭

    @delangel Do you throw your MT (and Y and non-PAR X) variants into VQSR along with your autosomal variants? I'm worried this will bias depth dependent annotations. I'm more keen on doing separate filtering for these variants (at least MT and Y), but I would probably have to do hard filtering, since the number of variants is probably insufficient for VQSR and because not all SNP truth/training sets contain all chromosomes:

    hapmap_3.3.b37.vcf.gz 1-22,X,Y,MT
    1000G_omni2.5.b37.vcf.gz 1-22,X,Y
    1000G_phase1.snps.high_confidence.b37.vcf.gz 1-22,X
    dbsnp_138.b37.vcf.gz 1-22,X,Y

    I would be very happy to get your insight on this, because the supplementary material to projects such as 1000G phase1 and GoNL is a bit scattered in terms of variant calling and filtering of mtDNA.

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie Posts: 11,669 admin

    Hi Tommy @tommycarstensen‌

    I'm not aware that we do any special handling of the non-autosomal components in the production pipeline -- I think the assumption is that there are few enough of them to not affect the rest. But it would be interesting to see a formal comparison. I sure can't imagine that you could get VQSR to run on them alone.

    PS: FYI Guillermo (@delangel) has moved on to another job so I don't know if he still gets GATK forum emails -- best not count on it.

    Geraldine Van der Auwera, PhD

  • tommycarstensentommycarstensen United KingdomMember Posts: 404 ✭✭✭

    @Geraldine_VdAuwera thanks for this. If I do any comparisons, then you will be the second to know. I'm still making changes to my analysis plan. I'm worried that Y and non-PAR X will have true positives filtered out by VQSR, because they are haploid in males and VQSR uses a few depth related annotations. I'll update this thread in time.

  • tommycarstensentommycarstensen United KingdomMember Posts: 404 ✭✭✭

    @Geraldine_VdAuwera‌ Just as an aside. The memory use of UG3.3 seems to explode and it seems to stall or only walk slowly, when I run it with -ploidy 1 on chromY and the non-PARs of chromX for male samples. I'm switching to diploidy for the whole genome for samples of both sexes. I am however happy to provide command line etc., if you are eager to troubleshoot. Apologies for the many posts over the past few weeks and months. I've been testing out a lot of things.

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie Posts: 11,669 admin

    @tommycarstensen To be honest we have zero resources available for UG troubleshooting/improvements -- I'm afraid you're on your own on this one.

    No worries, your questions have helped us nail down a few issues.

    Geraldine Van der Auwera, PhD

  • eflanneryeflannery San DiegoMember Posts: 9

    Hi Geraldine,

    I have a question about using UG or haplotype caller with a haploid organism, but which I have more than one clone in a sample. We generally use UG with ploidy set to two (default) and assume het variants are mixed reads from different clones. My worry is UG expects a certain number of hets to be called. Is this true? I've thought about setting ploidy to e.g. 4 and then saying we can only detect clones present at at least 25% of the sample. What are your thoughts. If you run UG with ploidy=1, will it allow for het calling? Should I try Mutec instead? Thanks!

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie Posts: 11,669 admin

    Hi @eflannery,

    There is no expectation of numbers of hets to be called; UG calls each site independently of any others. But there is an expectation of allelic ratios that depends directly on the ploidy setting. If you use ploidy = 1, the caller will make haploid calls only (no hets possible) so in effect it will pick the major allele present at highest frequency in your population. So unless that's what you want, you should use ploidy > 1. The higher the ploidy, the more likely you are to pick up additional alleles -- but it wll also increase your false positives. So it's up to you to choose where to set the cutoff.

    MuTect has very different internal logic since it does not try to pick alleles based on ploidy and/or allele ratio expectations. It is a lot more permissive re: allele ratios. But it is designed to work with paired tumor/normal samples, and while it can be run on non-paired samples, that's not the supported usage. You can certainly try it, but there is no guarantee that it will do the right thing for your use case.

    Geraldine Van der Auwera, PhD

  • u0597274u0597274 Salt Lake CityMember Posts: 4

    Is there any way to force HaplotypeCaller to do "naive" variant calling? i.e. call every possible variant. It seems excessive memory usage is inevitable when using high ploidy parameters - Freebayes, for example, just has an option to call everything.

    Also, does MuTect not lack support for non-diploid genomes?

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie Posts: 11,669 admin

    @u0597274 What does it mean to "call everything"? The performance cost of using high ploidies is due to the need to calculate genotype likelihoods for a large number of possible combinations. If you're calling every possible variant, you still need to calculate all the possible genotypes -- or am I misunderstanding what you're saying?

    Note that in the upcoming 3.7 version we've put in some logic to cull potential alleles that are actually very unlikely to be real, in order to reduce the amount of genotype combinations we have to calculate, which buys us some performance improvements.

    Geraldine Van der Auwera, PhD

  • u0597274u0597274 Salt Lake CityMember Posts: 4

    @Geraldine_VdAuwera - my apologies, I just saw your reply! It seems I had not configured my forum notification settings properly.

    Forgive me, I'm not much of a bioinformatics expert, so my phrasing isn't perfect, but I was basically asking if there is any way to force HaplotypeCaller to essentially behave like Mutect. My goal is to perform somatic variant calling on the mouse mitochondrial genome with RNA-Seq data. I'd be happy to turn off calculating genotype likelihoods - I just want to take advantage of the HaploTypeCaller's realignment capabilities for detecting somatic indels.

    On a side note, it seems GATK4 has gotten rid of IndelRealignment...

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie Posts: 11,669 admin

    @u0597274 I see, thanks for clarifying. I can't recommend using HaplotypeCaller for that purpose, the likelihood model is just not appropriate. You're better off using MuTect2 in artifact detection mode.

    You're correct that Indel Realignment tools are not available at all in GATK4. This is because the GATK4 variant callers do their own realignment internally, so prior realignment is no longer necessary.

    Geraldine Van der Auwera, PhD

Sign In or Register to comment.