DOCSEARCHbyAlgolia
Submit Docs

GATK-SV Documentation

website·Indexed 30 days ago

https://broadinstitute.github.io/gatk-sv/

A comprehensive, cloud-based ensemble pipeline for discovering and annotating all classes of structural variants (SV). Implemented as a set of WDLs for Google Cloud Platform, Terra, and Cromwell, it includes SV-Shell for platform-agnostic single-sample pipeline execution via Docker.

Tokens
26.8K
Snippets
60
Records
189
Agent score
72%

What's inside GATK-SV

  1. Overview of SV-Shell for single-sample pipelines

    SV-Shell is a platform-agnostic implementation of the GATK-SV single-sample pipeline. It is packaged as a single Docker image, allowing it to run on any infrastructure capable of executing Docker containers, including AWS, Azure, GCP, and on-premises environments.

  2. Overview of the TrainGCNV module

    The TrainGCNV module trains a gCNV model used to detect rare germline copy number variants (CNVs) from short-read sequencing read-depth information. This model is a prerequisite for the GatherBatchEvidence workflow. For optimal results, training samples should be homogeneous regarding sequencing platform, coverage, and library preparation. While a single model suffices for small homogeneous cohorts, larger cohorts or those with multiple data sources should use separate models for each batch.

  3. Overview of StripyWorkflow for STR expansion genotyping

    StripyWorkflow is an optional standalone workflow that runs STRipy on a single sample to genotype a curated set of known pathogenic short tandem repeat (STR) expansions. It is designed for targeted follow-up rather than genome-wide discovery. In joint-calling pipelines, it is typically executed after EvidenceQC and sample QC. The resulting single-sample VCFs can be merged using ClusterBatch and appended to the final cohort VCF via AnnotateVcf.

  4. Overview of GATK-SV Structural Variant Discovery

    GATK-SV is a cloud-based ensemble pipeline designed to discover and annotate all classes of structural variants (SV) from short-read whole genome sequencing (WGS) data. It is intended for use on the Terra platform.

    Key capabilities include:

    • Detection of deletions, duplications, multi-allelic copy number variants, balanced inversions, insertions, translocations, and complex SVs.
    • High sensitivity achieved by harmonizing output from five tools: Manta, Wham, Scramble, cn.MOPS, and GATK-gCNV.
    • False positive reduction via adjudication and re-genotyping using paired-end (PE) reads, split reads (SR), read-depth (RD), and B-allele frequencies (BAF).
    • Resolution of 11 classes of complex SVs consisting of multiple breakpoints.

  5. Overview of GATK-SV usage and execution

    GATK-SV is designed for structural variant (SV) calling. For users new to SV calling, it is highly recommended to review the Best Practices Guide. The primary recommended environment for running GATK-SV is the Terra platform.

  6. Overview of SV-Shell single-sample pipeline

    SV-Shell is a platform-agnostic implementation of a single-sample pipeline for genotyping structural variants (SVs) in one case sample against a pre-built reference panel. It runs end-to-end within a single Docker image, making it compatible with Azure, AWS, GCP, and on-premises infrastructure. The pipeline collects per-sample evidence (read depth, PE/SR, and raw SV calls), merges it with a batch/panel, clusters and genotypes calls, resolves complex multi-breakpoint SVs, scores/filters genotypes using an ML-based recalibrator, and annotates the results. It produces a genotyped, filtered, and annotated per-sample VCF and QC metrics.

  7. Overview of GATK-SV Single Sample pipeline

    The GATK-SV Single Sample pipeline enables structural variation (SV) detection for small datasets or clinical contexts where large-scale batching is not feasible. It achieves this by integrating signals from a single input CRAM file with precomputed data, SV calls, and model parameters derived from a reference panel of similar samples, providing results comparable in quality to the cohort-mode pipeline.

  8. Overview of Cromwell for GATK-SV

    Cromwell is a workflow management system that executes workflows written in Workflow Description Language (WDL) on a specified platform. For GATK-SV, Cromwell must be run in Server mode (either managed by an institute or self-managed) rather than as a stand-alone Java application. Currently, GATK-SV only supports running the pipeline on Google Cloud Platform (GCP).

  9. Overview of GATK-SV Docker CI/CD Workflow

    GATK-SV uses a GitHub Actions pipeline to ensure Docker images are built and tested consistently in standardized Linux VMs. The workflow is defined in sv_pipeline.yml and utilizes the build_docker.py script. The pipeline consists of three primary jobs: determining build arguments, regression testing (on pull requests), and publishing images to Google Container Registry (GCR) and Azure Container Registry (ACR) upon merging to the main branch.

  10. Overview of MainVcfQC module

    The MainVcfQC module creates plots for call set analysis and quality control (QC). While it is run by default as part of the FilterGenotypes module, it is a stand-alone workflow that can be used with any batch- or cohort-level (multi-sample) SV VCF, including outputs from ClusterBatch and subsequent modules.

  11. Overview of the FilterBatch workflow

    The FilterBatch workflow filters poor quality variants and outlier samples. It can be executed as a single top-level WDL or split into two steps to allow for tuning of outlier filtration cutoffs:

    1. FilterBatchSites: Performs per-batch variant filtration. It is used to visualize filtered SV counts per sample and type to help determine an appropriate IQR cutoff for outlier sample filtering.
    2. FilterBatchSamples: Performs per-batch outlier sample filtration using a specified outlier_cutoff_nIQR. Failing to remove high outliers can increase compute costs and the false positive rate in subsequent steps.

  12. Prerequisites for building GATK-SV Docker images

    GATK-SV Docker images must be built on x86 Linux machines (dedicated or virtual). Images created on non-Intel processor architectures (such as Apple M1) may not function as intended, even if the build process completes successfully.