LauraEgolf
commented
2 months ago "Clean" test to check GitHub repo
I repeated the single sample test to ensure that all the necessary changes are synced with GitHub, since some local changes haven't been pushed yet. I used a new base directory: /data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling_OsteoWGS2023, and cloned the repo from GitHub. I created a new branch (osteo-testing) with a few changes.
The example inputs require the Broad resource files stored in /data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling/broad-data. Other than that, I think all the required files are synced with GitHub.
Set up new test run:
BASE_DIR=/data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling_OsteoWGS2023/gatk-sv
${BASE_DIR}/scripts/inputs/build_inputs.py \
${BASE_DIR}/inputs/values \
${BASE_DIR}/inputs/templates/test/GATKSVPipelineSingleSample \
${BASE_DIR}/inputs/build_20240514/CCSS_1000278_A_newtest \
-a '{ "single_sample" : "test_single_sample_CCSS_1000278_A", "ref_panel" : "ref_panel_1kg" }'
cd /data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling_OsteoWGS2023
swarm run_gatk-sv_single_sample_no_melt_20240514.swarmUPDATE: This test failed due to cromwell-related errors. I tested with a different config file (biowulf-swarm.conf instead of biowulf-core.conf), which resolved the problem.
The osteo-testing branch is up-to-date and succeeded for at least one test run - but other test runs failed, as described below.
Independent user test of GATK-SV single-sample pipeline on Biowulf
Ben previously configured the GATK-SV single-sample pipeline for Biowulf and tested using a COVNET WGS sample. I ran an independent test using one of the osteosarcoma WGS samples, CCSS_1000278_A.
The single-sample pipeline can process a single test sample jointly with a reference panel. It reduces computational time somewhat by using certain precomputed inputs, but this mode is still is much less computationally efficient than the cohort/batch mode (best used for 100+ samples). Here we used the reference panel of 156 samples from 1000 Genomes which is provided by GATK-SV (the same panel is used in the example Terra workspace).
Note that the single-sample pipeline generally will only work for PCR-free WGS samples, in my experience.
Working directory:
/data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling/run_gatksv_20240405/Build inputs
Help message for build_inputs.py:
Example from GATK-SV documentation:
Ben's example:
Setup for my test run:
Run pipeline and troubleshoot
First test run:
Got error with GATK jar. Added GATK to the modules list (in swarm command) and re-ran - still got the same error.
Commented this line out of all GATK-SV WDLs (here:
/data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling/gatk-sv):export GATK_LOCAL_JAR=~{default="/root/gatk.jar" gatk4_jar_override}. Solved the GATK jar error.Got error with Google container registry (ubuntu image); tested again after initializing gcloud:
Same error.
Update Docker inputs to avoid using GCR ubuntu container
Updated values file to avoid the problematic container:
/data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling/gatk-sv/inputs/values_20240405/dockers.jsonReplaced: "linux_docker": "marketplace.gcr.io/google/ubuntu1804", With: "linux_docker": "ubuntu:18.04",
Re-ran build_inputs.py, and submitted test run - latest run succeeded.
Results
Runtime
Runtime estimate from the example Terra workspace, I assume this is using GCP preemptible instances:
Note the 18 GB file size is based on a ~30x CRAM file, here we used a 36x BAM file (77 GB).
Runtime on Biowulf: 9 hours 13 minutes (based on the main swarm job runtime, and the timestamps on the output directory).
Output structure
An explanation of the output can be found on the Terra workspace for the GATK-SV single-sample pipeline:
Results from this run:
/data/DCEG_Pediatric_Sarcomas/StructuralVariantCalling/run_gatksv_20240405/gatk-sv-resultsQC checks
The GATK-SV single-sample pipeline has several built-in QC checks. This sample mostly passed the QC checks, which is a good sign (I've tried running this pipeline in the past, and my PCR+ samples failed the QC checks horribly). However, it was flagged for certain SV counts being outside the 'normal' ranges defined by the pipeline developers:
In particular, the count of deletions >100 kb is extremely high. I will investigate this further.