Per-sample processing

The initial phase prepares individual samples for joint genotyping by performing quality control, alignment, recalibration, and per-sample variant calling.

• Input Data: The workflow accepts paired-end FASTQ files as the primary input.
• Initial Quality Control: Raw reads are assessed using FastQC to detect potential issues such as adapter contamination, low-quality bases, or sequence composition biases.
• Adapter and Quality Trimming: fastp is used to remove adapter sequences and low-quality bases, improving alignment accuracy and reducing false positives.
• Read Alignment: The cleaned paired-end reads are aligned to the reference genome (GRCh38) using BWA-MEM2, producing SAM files, which are converted to BAM format for downstream processing.
• Sorting and Duplicate Marking: BAM files were first coordinate-sorted using samtools to enable efficient genomic data access. Subsequently, Polymerase Chain Reaction (PCR) duplicates, which may artificially inflate allele counts, are identified and marked using gatk MarkDuplicates.
• Base Quality Score Recalibration (BQSR): To correct systematic errors in base quality scores, we apply GATK’s BaseRecalibrator followed by ApplyBQSR, thereby improving the accuracy of downstream variant calling with the GATK HaplotypeCaller.
• Per-Sample Variant Calling: GermVarX employs a dual variant calling strategy for robustness:
  • GATK HaplotypeCaller: Generates GVCF files (.g.vcf) for each sample, capturing variant and non-variant sites for joint genotyping.
  • DeepVariant: Processes BAM files to produce GVCF files using a deep learning-based approach.

Cohort-level processing and annotation

The second phase of GermVarX aggregates per-sample variant data to perform joint genotyping, consensus building, variant filtering, and functional annotation for the entire cohort.

• Joint Genotyping: GermVarX supports two joint genotyping strategies based on the variant caller used:
  • For GATK-based calling:
    • CombineGVCFs/GenomicsDBImport: Supports merging per-sample GVCFs into a combined cohort GVCF. GermVarX uses CombineGVCFs as the default approach and provides optional support for GenomicsDBImport, which offers improved scalability and efficiency for large cohorts [19].
    • GenotypeGVCFs: Performs joint genotyping to generate a multi-sample VCF.
    • Variant filtering: GermVarX provides two user-selectable filtering methods: (1) GATK hard filtering, applying best-practice threshold-based filters for SNPs and indels; (2) Variant Quality Score Recalibration (VQSR), a machine learning–based approach that models variant quality and applies probabilistic filtering for SNPs and indels following GATK best practices.
  • For DeepVariant-based calling:
    • GLnexus: Performs optimized joint genotyping on DeepVariant GVCFs, as GATK CombineGVCFs/GenomicsDBImport is incompatible with DeepVariant outputs.
• Variant Annotation: Functional annotation is performed using VEP (Variant Effect Predictor) with multiple plugins, including dbNSFP, CLINVAR, and CADD, providing pathogenicity predictions and gene impact assessment.
• Consensus Building: To improve reliability, GermVarX supports consensus callset generation by intersecting variant calls from GATK and DeepVariant. Overlapping variants are retained when they share both genomic position and alleles, producing a high-confidence multi-sample VCF.
• Variant Quality Control: Variants from the consensus file are subjected to stringent quality control procedures prior to downstream analyses. Specifically: (i) Genotypes with sequencing depth (DP) < 10, genotype quality (GQ) < 20, or heterozygous calls with allele balance (AB) outside the range of 0.2–0.8 are marked as missing; (ii) Multiallelic sites are excluded; (iii) Variants with a quality score (QUAL) < 20 or a call rate < 90% across samples are removed. These values are used as defaults; however, all filtering thresholds can be easily modified by users (see Table 2 of S1 File).

At the sample level, summary statistics are computed to assess overall data quality. These include the transition/transversion (Ti/Tv) ratio, heterozygous/homozygous (Het/Hom) ratio, and insertion/deletion (Indel) ratio, all generated using bcftools stats. Additional checks for relatedness and sex concordance are performed using PLINK. All quality control results are consolidated into the file sample_qc.csv, enabling straightforward filtering and selection of high-quality samples for subsequent analyses.

• Reporting: Throughout the workflow, quality metrics are collected from all stages. At completion, MultiQC aggregates results from FastQC, BWA, GATK, VEP, and mosdepth into a single interactive report.

Portability and reproducibility

GermVarX is implemented in Nextflow DSL2, leveraging features such as process parallelization, container integration, checkpointing, and error handling to ensure efficiency, reproducibility, and fault tolerance. Each tool is encapsulated within a modular Nextflow process, enabling easy updates and configuration across computing environments. To guarantee reproducibility and minimize installation overhead, GermVarX is fully containerized with Docker, packaging all dependencies into pre-built images.

The workflow employs explicit version control for both pipeline code and software containers, enabling analyses to be reproduced consistently across runs and environments. In addition, GermVarX generates standardized outputs—including VCF, PLINK, and MultiQC reports—providing a stable and transparent basis for downstream analyses in WES cohort studies.

Setting up and running GermVarX pipeline

GermVarX is implemented as a Nextflow DSL2 workflow and can be executed on any POSIX-compliant computing system. All tools are fully containerized using Docker, thereby ensuring reproducibility, portability, and the elimination of software dependency conflicts. The pipeline requires only minimal setup, consisting of the installation of Nextflow (≥24) and Docker on the target environment.

The general procedure for setup and execution involves:

1. Install and configure Nextflow and Docker on the target system.
2. Clone the GermVarX source code from the GitHub repository.
3. Pull the required pre-built container images and build the custom GermVarX Docker image.
4. Configure input parameters and execution settings in the configuration files provided within the configuration/directory.
5. Run the pipeline using Nextflow with Docker support enabled. A typical command is:
   nextflow run src/main.nf -profile docker <INPUT> [OPTIONS]

By default, GermVarX executes the full pipeline, beginning with paired-end FASTQ files and proceeding through alignment, variant calling, filtering, annotation, and reporting. However, the workflow also supports alternative entry points, accepting BAM, GVCF, or VCF files as input. In such cases, execution commences automatically at the appropriate downstream stage, thereby bypassing earlier processes. Similarly, users can specify the desired final output format (e.g., BAM, GVCF), allowing the pipeline to terminate at a chosen stage.

The protocol described in this peer-reviewed article is published on protocols.io (dx.doi.org/10.17504/protocols.io.3byl48kr8vo5/v1) and is included for printing purposes as S1 File.

Data acquisition

To evaluate the performance and accuracy of the GermVarX protocol, we utilized two distinct datasets:

• Ashkenazim Trio (Benchmark Dataset): Three WES samples (SRA accession IDs: SRR2962669, SRR2962692, and SRR2962694) sequenced on the Illumina HiSeq 2500 platform with approximately 100× coverage using the Agilent SureSelect Human All Exon V5 capture kit were selected. Raw sequencing data are publicly available from the NCBI Sequencing Read Archive (https://www.ncbi.nlm.nih.gov/sra/). Corresponding Genome in a Bottle (GIAB) benchmark datasets (v4.2.1) were obtained from the GIAB FTP repository (https://ftp-trace.ncbi.nlm.nih.gov/giab/ftp/release/).
• 120 WES samples (Computational Performance Evaluation): To assess the workflow’s scalability and performance in a cohort setting, we used 120 WES samples provided by the Institute of Biology (formerly the Institute of Genome Research). The study involving these samples was conducted in accordance with the Declaration of Helsinki and approved by the Ethics Committee of the Institute of Genome Research (Approval No. 01–2021/NCHG-HDDD; 26 October 2021). These data were used exclusively to evaluate the workflow’s computational efficiency and resource management.

Variant calling accuracy

To assess the biological accuracy of GermVarX, we benchmarked its variant calling performance using three WES samples from the Ashkenazim Trio. We compared three variant calling strategies: (i) GATK join genotyping with hard filtering (GATK-Join), (ii) DeepVariant single-sample calling with GLnexus merging (DV-GLN), and (iii) Consensus, which retains only variants detected by both callers. Because GermVarX performs joint variant calling across samples, benchmarking was conducted against the Genome in a Bottle (GIAB) v4.2.1 truth sets, restricted to high-confidence regions intersecting with the capture targets and shared across all samples.

Variant evaluation was performed using the hap.py toolkit [20], which reports three standard performance metrics based on the Global Alliance for Genomics and Health (GA4GH) benchmarking guidelines for variant calling: precision, recall, and F1-score. These metrics compare the variant calls against a ground-truth benchmark set, where TP (true positives) denotes correctly identified variants, FP (false positives) denotes variants called by the caller but absent from the truth set, and FN (false negatives) denotes true variants that were missed by the caller.

Precision is defined as

recall as

and the F1-score as the harmonic mean of precision and recall:

These metrics were computed separately for single-nucleotide polymorphisms (SNPs) and insertions/deletions (INDELs). A summary of results is shown in Fig. 2, with per-sample details provided in S1 Table.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 2. GermVarX variant benchmarking.

Benchmarking of GATK-Join, DV-GLN, and Consensus strategies for SNPs and INDELs. DV-GLN and Consensus show highest SNP accuracy, while GATK-Join provides balanced INDEL performance.

https://doi.org/10.1371/journal.pone.0345561.g002

For SNPs, all strategies achieved high accuracy. DV-GLN achieved the highest F1-score (0.9649), balancing exceptional precision (0.9994) with strong recall (0.9327). GATK-Join performed similarly (F1 = 0.9639), with slightly reduced precision (0.9960) but comparable recall (0.9338). The Consensus call set yielded the highest precision (0.9995) and nearly identical recall (0.9326), resulting in an F1-score equal to DV-GLN (0.9649).

For INDELs, performance differences were more pronounced. DV-GLN outperformed other strategies in terms of F1-score (0.9372), driven by its very high precision (0.9927), although its recall (0.8876) was lower than GATK-Join (0.9121). GATK-Join provided balanced performance (precision = 0.9058, recall = 0.9121, F1 = 0.9090). The Consensus call set maintained the highest precision (0.9983) but at the cost of recall (0.8635), yielding an intermediate F1-score (0.9260).

Computational performance

To assess computational requirements, GermVarX was benchmarked on WES datasets ranging from dozens to hundreds of samples. As a representative test, we executed the full pipeline on 120 samples (403 GB of raw data, 50× coverage) using a system with 56 CPU cores, 128 GB of RAM, and Ubuntu 24.04 LTS. The run completed in 77.8 hours of wall-clock time and required approximately 3.5 TB of storage across input, work, and output directories. Most of the persistent storage was consumed by preprocessing (FASTQ trimming and BAM file generation). Upon completion, up to 2.5 TB of temporary files in the work directory can be safely removed, unless re-runs from intermediate states are needed.

The cumulative CPU and wall-clock hours, calculated as the sum of all task runtimes across the 120-sample dataset, are summarized in Table 2. It is important to note that these per-stage totals represent aggregate task time rather than actual elapsed time, which for the complete GermVarX execution was 77.8 hours. Among the stages, preprocessing of FASTQ and BAM files—including trimming, read alignment, and duplicate marking—was the most resource-intensive step (585.8 CPU hours, 226.3 wall-clock hours). This was followed by GATK-based variant calling (159.1 CPU hours, 93.1 wall-clock hours) and DeepVariant-based variant calling steps (186.1 CPU hours, 51.1 wall-clock hours). Other stages—including quality control, annotation, and consensus building—were comparatively lightweight. Peak memory usage remained modest, not exceeding 21 GB across all processes, demonstrating that GermVarX can be efficiently deployed on mid-range HPC clusters or cloud-based environments.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 2. Resource usage across GermVarX pipeline stages. The complete pipeline finished in 77.8 hours of wall-clock time. Reported CPU and wall-clock hours are cumulative task sums across all samples in each stage, not actual elapsed runtime.

https://doi.org/10.1371/journal.pone.0345561.t002