Genome Analysis Toolkit

Variant Discovery in High-Throughput Sequencing Data

GATK process banner

Need Help?

Search our documentation

Community Forum

Hi, How can we help?

Developed in the Data Sciences Platform at the Broad Institute, the toolkit offers a wide variety of tools with a primary focus on variant discovery and genotyping. Its powerful processing engine and high-performance computing features make it capable of taking on projects of any size. Learn more

Mutect2 Stall on Chromosome 3

0

5 comments

  • Avatar
    Gökalp Çelik

    Hi Scott Davidson

    Can you provide details of the system you are running this on? Did you check that region visually to see if there is anything unusual such as too high depth or heavy masking? 

    0
    Comment actions Permalink
  • Avatar
    Scott Davidson

    Hi,

    I'm running on a Slurm scheduled high performance compute cluster.
    My runtime parameters for this job were: 8 cores on a single node, 48 GB RAM, and 1TB of scratch space.

    I checked the bam file and there was nothing out of the ordinary in the region where the stall was or around it, other than it being the centromere of chromosome 3.

    As mentioned all of the other chromosomes finished fine in a good time with the same runtime parameters.

    0
    Comment actions Permalink
  • Avatar
    Gökalp Çelik

    Is it possible for you to split chr3 into different intervals split by hard masked (N) regions to try if you see any improvement? That way we may be able to pinpoint which region is causing this issue much better.  

    Also the region that GATK seems to stall is within a long Alpha Satellite Repeat region of chr3 which really is a long repeat region. You may be able to skip these regions in all chromosomes unless you have special interest in them. 

    0
    Comment actions Permalink
  • Avatar
    Scott Davidson

    Hi,
    I made a change and used the --exclude-intervals option.
    I gave it a file of centromere positions of which the chromosome 3 intervals are these:
    chr3:91553419-93655574
    chr3:90772458-91233586
    chr3:91233686-91247622

    Rerunning the command with this added in has allowed it to get past the sticky position already.
    18:12:42.471 INFO  ProgressMeter -       chr3:132808803            154.0                566210           3677.4
    18:12:52.548 INFO  ProgressMeter -       chr3:132922881            154.1                566700           3676.6
    18:13:02.589 INFO  ProgressMeter -       chr3:133073861            154.3                567340           3676.7
    18:13:12.609 INFO  ProgressMeter -       chr3:133215288            154.5                567960           3676.8

    So it's something within one of those three regions.

    0
    Comment actions Permalink
  • Avatar
    Gökalp Çelik

    Great to hear that. It is possible that the repeat region could have accumulated too many reads therefore Mutect2 reassembly engine got stuck. 

    I hope it works this time. 

    Regards. 

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk