giraffe (vg giraffe + GATK)

View as Markdown

Note that the Parabricks GPU-accelerated Giraffe tool is currently in beta.

Generate BAM output given one or a pair of FASTQ files using the pangenome aligner VG Giraffe [^note] [^note].

Refer to the giraffe Reference section for a detailed listing of all available options.

What is giraffe?

VG Giraffe is a short-read mapping tool developed by Dr. Benedict Paten’s lab at the University of California, Santa Cruz (UCSC). This innovative tool can align reads to a graph representation of multiple reference genomes, enhancing the quality of downstream analyses. By accurately mapping reads to thousands of genomes simultaneously, VG Giraffe offers a substantial improvement over traditional single-reference aligners.

Why giraffe?

By utilizing a graph-based approach, VG Giraffe can more effectively handle genetic diversity and structural variations across populations. Here are three key benefits of using VG Giraffe:

  1. Improved accuracy: VG Giraffe achieves higher precision and recall in read mapping compared to linear genome aligners, especially when dealing with complex genomic regions or populations with significant genetic diversity.
  2. Reduced reference bias (or mapping bias): By incorporating multiple haplotypes and known variants into its graph structure, VG Giraffe minimizes the reference bias inherent in traditional linear genome aligners. This leads to more comprehensive and unbiased characterization of genetic variation, especially for samples that diverge significantly from the standard reference genome.
  3. Faster performance: Despite working with more complex graph structures, VG Giraffe is significantly faster than its predecessor VG Map and comparable in speed to popular linear genome mappers. It can map sequencing reads to thousands of human genomes at a speed similar to methods that map to a single reference genome.

How Should I Use giraffe in Parabricks?

VG Giraffe can be used within Parabricks, a software suite designed for accelerated secondary analysis in genomics. Our wrapper (pbrun giraffe) will run our GPU-accelerated VG Giraffe and sort the output BAM by coordinate.

While users can build custom reference graphs for VG Giraffe using the VG Autoindex tool, pre-built pangenome graphs are also available. Dr. Paten’s lab and the Human Pangenome Consortium have made these resources publicly accessible, allowing researchers to leverage high-quality, ready-to-use pangenome graphs for their analyses (HPRC data).

Generating Required Index Files

The index files .gbz, .dist, .min, and .zipcodes are required to run Giraffe. A reference paths file is also needed to define the set of paths used for BAM output.

The index files can be generated from a GBZ graph using vg autoindex. The following example uses the HPRC v1.1 Minigraph-Cactus pangenome graph aligned to GRCh38:

1# Download GBZ
2# https://s3-us-west-2.amazonaws.com/human-pangenomics/pangenomes/freeze/freeze1/minigraph-cactus/hprc-v1.1-mc-grch38/hprc-v1.1-mc-grch38.d9.gbz
3aws s3 cp \
4 s3://human-pangenomics/pangenomes/freeze/freeze1/minigraph-cactus/hprc-v1.1-mc-grch38/hprc-v1.1-mc-grch38.d9.gbz \
5 . \
6 --no-sign-request
7
8# Extract index files from GBZ
9docker run --rm --volume $(pwd):/workdir \
10 --workdir /workdir \
11 --user $(id -u):$(id -g) \
12 quay.io/vgteam/vg:v1.70.0 \
13 vg autoindex \
14 -p hprc-v1.1-mc-grch38.d9.autoindex.1.70 \
15 -G hprc-v1.1-mc-grch38.d9.gbz \
16 -w giraffe
17
18# Extract paths from GBZ
19docker run --rm \
20 --user $(id -u):$(id -g) \
21 --volume $(pwd):/workdir \
22 --workdir /workdir \
23 quay.io/vgteam/vg:v1.70.0 \
24 vg paths -x hprc-v1.1-mc-grch38.d9.gbz \
25 -L --paths-by GRCh38 > hprc-v1.1-mc-grch38.d9.paths
26
27# As per best practices, remove decoys, unplaced/unlocalized contigs,
28# and other non-primary paths unnecessary for pangenome graph alignment.
29grep -v _decoy hprc-v1.1-mc-grch38.d9.paths \
30 | grep -v _random \
31 | grep -v chrUn_ \
32 | grep -v chrEBV \
33 | grep -v chrM \
34 | grep -v chain_ > hprc-v1.1-mc-grch38.d9.paths.sub

Quick Start

Before running giraffe, ensure you have generated the required index files. Refer to the index generation section above for instructions.

1# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
2docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
3 --workdir /workdir \
4 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
5 pbrun giraffe --read-group "sample_rg1" \
6 --sample "sample-name" --read-group-library "library" \
7 --read-group-platform "platform" --read-group-pu "pu" \
8 --gbz-name /workdir/hprc-v1.1-mc-grch38.d9.gbz \
9 --dist-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.dist \
10 --minimizer-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.withzip.min \
11 --zipcodes-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.zipcodes \
12 --ref-paths /workdir/hprc-v1.1-mc-grch38.d9.paths.sub \
13 --in-fq /workdir/${INPUT_FASTQ_1} /workdir/${INPUT_FASTQ_2} \
14 --out-bam /outputdir/${OUTPUT_BAM}

System Requirements and Useful Options for Performance

To ensure optimal performance with VG Giraffe, consider the following system requirements based on your GPU configuration:

  • A 2 GPU system should have at least 100GB CPU RAM and at least 32 CPU threads.

  • A 4 GPU system should have at least 200GB CPU RAM and at least 64 CPU threads.

  • For GPUs with less than 22 GB of device memory, use --low-memory.

Auto Mode

By default, --nstreams is set to auto, which enables auto mode. In this mode, Giraffe automatically configures the number of CUDA streams, batch size, and GPU acceleration options based on the available GPU device memory. Auto mode is designed to provide sensible defaults, but may still require further optimization for each specific system. The following table summarizes the auto mode configuration based on GPU device memory:

GPU MemoryStreamsBatch Sizeminimizers-gpu (SE only)
< 22 GB1 (low-memory)5000No
22-32 GB18000No
32-40 GB210000No
40-80 GB310000No
80-120 GB410000Yes
>= 120 GB510000Yes

Auto mode also takes host memory into account. If host memory is insufficient, --minimizers-gpu may be disabled, and batch size and work queue capacity may be reduced.

Note that --minimizers-gpu is only enabled for single-end (SE) reads. For paired-end (PE) reads, the number of streams and batch size are configured as shown above, but --minimizers-gpu is always disabled.

For best performance, auto mode can be overridden by explicitly setting --nstreams and other options. The following configurations are, for example, recommended for L4, H100 and RTX PRO 6000 Blackwell Server Edition GPUs:

  • L4 (16 GB): --batch-size 5000 --nstreams 2

  • H100 (80 GB): --nstreams 5 --num-cpu-threads-per-gpu 24 --minimizers-gpu

  • RTX PRO 6000 Blackwell Server Edition (96 GB): --nstreams 4 --num-cpu-threads-per-gpu 24 --minimizers-gpu

Note: While a fixed base memory allocation exists per device, the number of streams and batch size are the primary factors affecting total device memory consumption.

Using Giraffe in Variant Calling Workflows

To use Giraffe-aligned BAM files for variant calling, you need to extract the appropriate reference file from the Giraffe index files. Run the following commands from the directory containing the Giraffe index files:

1# Extract the sequences corresponding to the list of paths to a FASTA file
2docker run --rm \
3 --user $(id -u):$(id -g) \
4 --volume $(pwd):/workdir \
5 --workdir /workdir \
6 quay.io/vgteam/vg:v1.70.0 \
7 vg paths -x hprc-v1.1-mc-grch38.d9.gbz \
8 -p hprc-v1.1-mc-grch38.d9.paths.sub \
9 -F > hprc-v1.1-mc-grch38.d9.fa
10
11# Index the FASTA file
12docker run --rm \
13 --user $(id -u):$(id -g) \
14 --volume $(pwd):/workdir \
15 --workdir /workdir \
16 quay.io/biocontainers/samtools:1.17--hd87286a_2 \
17 samtools faidx hprc-v1.1-mc-grch38.d9.fa

These commands will generate a FASTA file (hprc-v1.1-mc-grch38.d9.fa), and the corresponding index (hprc-v1.1-mc-grch38.d9.fa.fai), that can be used as the reference for variant calling. Note that these files can be also used for BQSR (bqsr). We can now run Giraffe to obtain the aligned BAM as follows:

1# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
2docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
3 --workdir /workdir \
4 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
5 pbrun giraffe --read-group "sample_rg1" \
6 --sample "sample-name" --read-group-library "library" \
7 --read-group-platform "platform" --read-group-pu "pu" \
8 --gbz-name /workdir/hprc-v1.1-mc-grch38.d9.gbz \
9 --dist-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.dist \
10 --minimizer-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.withzip.min \
11 --zipcodes-name /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.zipcodes \
12 --ref-paths /workdir/hprc-v1.1-mc-grch38.d9.paths.sub \
13 --in-fq /workdir/${INPUT_FASTQ_1} /workdir/${INPUT_FASTQ_2} \
14 --out-bam /outputdir/${OUTPUT_BAM}

Once you have the Giraffe-aligned BAM file and the extracted reference FASTA, you can proceed with variant calling using HaplotypeCaller, Deepvariant, Pangenome_aware_deepvariant, or the end-to-end pangenome_germline pipeline.

1# Haplotype Caller
2# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
3docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
4 --workdir /workdir \
5 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
6 pbrun haplotypecaller \
7 --ref /workdir/hprc-v1.1-mc-grch38.d9.fa \
8 --in-bam /workdir/${INPUT_BAM} \
9 --in-recal-file /workdir/${INPUT_RECAL_FILE} \
10 --out-variants /outputdir/${OUTPUT_VCF}
11
12# Deepvariant
13# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
14docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
15 --workdir /workdir \
16 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
17 pbrun deepvariant \
18 --ref /workdir/hprc-v1.1-mc-grch38.d9.fa \
19 --in-bam /workdir/${INPUT_BAM} \
20 --out-variants /outputdir/${OUTPUT_VCF}
21
22# Pangenome_aware_deepvariant
23# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
24docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
25 --workdir /workdir \
26 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
27 pbrun pangenome_aware_deepvariant \
28 --ref /workdir/hprc-v1.1-mc-grch38.d9.fa \
29 --pangenome /workdir/hprc-v1.1-mc-grch38.d9.gbz \
30 --in-bam /workdir/${INPUT_BAM} \
31 --out-variants /outputdir/${OUTPUT_VCF}

For more detailed instructions on variant calling, refer to the tool-specific documentation (haplotypecaller, deepvariant, pangenome_aware_deepvariant, pangenome_germline).

Using Giraffe with Haplotype Sampling

Giraffe’s haplotype sampling functionality, activated using arguments --haplotype-name and --kff-name, was introduced to significantly enhance alignment accuracy by tailoring the reference graph to the specific genetic profile of a sample. This process begins by analyzing sequencing reads with a kmer counter to identify patterns of kmer presence and frequency. Using this information, Giraffe sub-samples the GBWT (using the original .hapl and .gbz files) to select haplotypes that best represent the sample, creating a customized graph. From this tailored graph, Giraffe also generates new index files (.dist, .min, and .zipcodes) that are optimized for the sample to be analyzed.

These steps can be performed using the baseline VG container for graph customization and index generation, followed by Parabricks’ accelerated Giraffe for high-performance alignment, as demonstrated below.

The required .hapl and .gbz files can be downloaded as follows:

1aws s3 cp \
2 s3://human-pangenomics/pangenomes/freeze/freeze1/minigraph-cactus/hprc-v1.1-mc-grch38/hprc-v1.1-mc-grch38.gbz \
3 . \
4 --no-sign-request
5
6aws s3 cp \
7 s3://human-pangenomics/pangenomes/freeze/freeze1/minigraph-cactus/hprc-v1.1-mc-grch38/hprc-v1.1-mc-grch38.hapl \
8 . \
9 --no-sign-request

You will also need to extract and filter reference paths for this graph:

1docker run --rm \
2 --user $(id -u):$(id -g) \
3 --volume $(pwd):/workdir \
4 --workdir /workdir \
5 quay.io/vgteam/vg:v1.70.0 \
6 vg paths -x hprc-v1.1-mc-grch38.gbz \
7 -L --paths-by GRCh38 > hprc-v1.1-mc-grch38.paths
8
9grep -v _decoy hprc-v1.1-mc-grch38.paths \
10 | grep -v _random \
11 | grep -v chrUn_ \
12 | grep -v chrEBV \
13 | grep -v chrM \
14 | grep -v chain_ > hprc-v1.1-mc-grch38.paths.sub
1# Run KMC on the input reads to obtain the .kff file
2mkdir kmc_tmp_dir
3cat > input.fq.paths <<- EOM
4${INPUT_FASTQ_1}
5${INPUT_FASTQ_2}
6EOM
7
8docker run --rm --volume $(pwd):/workdir \
9 --workdir /workdir \
10 quay.io/biocontainers/kmc:3.2.4--haf24da9_3 \
11 kmc \
12 -k29 \
13 -m128 \
14 -okff \
15 -t64 \
16 @input.fq.paths \
17 input.fq.distr kmc_tmp_dir
18
19# Compute the sampled .gbz file using the baseline container
20docker run --rm --volume $(pwd):/workdir \
21 --workdir /workdir \
22 quay.io/vgteam/vg:v1.70.0 \
23 vg haplotypes \
24 -v 2 -t 64 \
25 --include-reference \
26 --diploid-sampling \
27 -i hprc-v1.1-mc-grch38.hapl \
28 -k input.fq.distr.kff \
29 -g hprc-v1.1-mc-grch38.sampled.gbz \
30 hprc-v1.1-mc-grch38.gbz
31
32# Generate index files from the sampled graph using autoindex
33docker run --rm --volume $(pwd):/workdir \
34 --workdir /workdir \
35 --user $(id -u):$(id -g) \
36 quay.io/vgteam/vg:v1.70.0 \
37 vg autoindex \
38 -p hprc-v1.1-mc-grch38.sampled.autoindex.1.70 \
39 -G hprc-v1.1-mc-grch38.sampled.gbz \
40 -w giraffe
41
42# Align the reads to the sampled graph using Parabricks Giraffe
43# This command assumes all the inputs are in the current working directory and all the outputs go to the same place.
44docker run --rm --gpus all --volume $(pwd):/workdir --volume $(pwd):/outputdir \
45 --workdir /workdir \
46 nvcr.io/nvidia/clara/clara-parabricks:4.7.1-1 \
47 pbrun giraffe --read-group "sample_rg1" \
48 --sample "sample-name" --read-group-library "library" \
49 --read-group-platform "platform" --read-group-pu "pu" \
50 --gbz-name hprc-v1.1-mc-grch38.sampled.gbz \
51 --dist-name hprc-v1.1-mc-grch38.sampled.autoindex.1.70.dist \
52 --minimizer-name hprc-v1.1-mc-grch38.sampled.autoindex.1.70.shortread.withzip.min \
53 --zipcodes-name hprc-v1.1-mc-grch38.sampled.autoindex.1.70.shortread.zipcodes \
54 --ref-paths hprc-v1.1-mc-grch38.paths.sub \
55 --in-fq ${INPUT_FASTQ_1} ${INPUT_FASTQ_2} \
56 --out-bam /outputdir/${OUTPUT_BAM}

Compatible CPU-based vg giraffe and GATK4 Commands

The commands below are the vg-1.70.0 and GATK4 counterpart of the Parabricks command above. The output from these commands will be identical to the output from the above command. Refer to the Output Comparison page for comparing the results.

The index files used below are generated in the index generation section.

1# Run giraffe and pipe the output to create a sorted BAM.
2$ vg giraffe \
3 -t 16 \
4 -Z /workdir/hprc-v1.1-mc-grch38.d9.gbz \
5 -d /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.dist \
6 -m /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.withzip.min \
7 -z /workdir/hprc-v1.1-mc-grch38.d9.autoindex.1.70.shortread.zipcodes \
8 --ref-paths /workdir/hprc-v1.1-mc-grch38.d9.paths.sub \
9 -f /workdir/${INPUT_FASTQ_1} \
10 -f /workdir/${INPUT_FASTQ_2} \
11 --output-format bam | \
12 gatk SortSam \
13 --java-options -Xmx30g \
14 --MAX_RECORDS_IN_RAM 5000000 \
15 -I /dev/stdin \
16 -O cpu.bam \
17 --SORT_ORDER coordinate
18
19# Mark duplicates.
20$ gatk MarkDuplicates \
21 -I cpu.bam \
22 -O cpu.markdup.bam \
23 -M metrics.txt

Source of Mismatches

When comparing output with the CPU counterpart the following can be sources of small differences.

  • Baseline VG Container

    • Single-end (SE) reads: Parabricks matches the baseline quay.io/vgteam/vg:v1.70.0 container exactly. No modifications to the baseline container are needed.

    • Paired-end (PE) reads: A bug fix for fragment distance recording is required in the baseline container. You need to cherry-pick the fix and rebuild the container as follows:

1# Clone the repo (full history needed for cherry-pick)
2git clone https://github.com/vgteam/vg.git
3cd vg
4
5# Checkout v1.70.0 tag and create a patch branch
6git checkout v1.70.0
7git checkout -b v1.70.0-fragment-fix
8
9# Initialize submodules (required for build)
10git submodule update --init --recursive
11
12# Cherry-pick the bug fix
13git cherry-pick d99a2a4d4b16500ec8dd4bd9d9d93c7fbec26ed1
14
15# Build the Docker container
16make version
17docker build --build-arg THREADS=64 -t vg:v1.70.0-fragment-fix .
  • Unmapped reads

    • Parabricks giraffe sorts unmapped reads slightly differently than baseline GATK SortSam. Unmapped reads can be filtered with samtools by running samtools view -F 4.

Options

TypeNameRequired?Description
I/O--in-fq [IN_FQ ...]NoPath to the paired-end FASTQ files. The files must be in fastq or fastq.gz format. Example 1: --in-fq sampleX_1_1.fastq.gz sampleX_1_2.fastq.gz.
I/O--in-fq-list IN_FQ_LISTNoPath to a file that contains the locations of pair-ended FASTQ files. Each line must contain the location of the FASTQ files followed by a read group, each separated by a space. Each pair of files (and associated read group) must be on a separate line. Files must be in fastq/fastq.gz format. Line syntax: <fastq_1> <fastq_2> <read group>.
I/O--in-se-fq [IN_SE_FQ ...]NoPath to the single-end FASTQ file. The file must be in fastq or fastq.gz format.
I/O--in-se-fq-list IN_SE_FQ_LISTNoPath to a file that contains the locations of single-ended FASTQ files. Each line must contain the location of the FASTQ files followed by a read group, each separated by a space. Each file (and associated read group) must be on a separate line. Files must be in fastq/fastq.gz format. Line syntax: <fastq> <read group>.
I/O-d DIST_NAME, --dist-name DIST_NAMEYesCluster using this distance index.
I/O-m MINIMIZER_NAME, --minimizer-name MINIMIZER_NAMEYesUse this minimizer index.
I/O-Z GBZ_NAME, --gbz-name GBZ_NAMEYesMap to this GBZ graph.
I/O-z ZIPCODES_NAME, --zipcodes-name ZIPCODES_NAMEYesUse this zipcodes file for clustering.
I/O-x XG_NAME, --xg-name XG_NAMENoXG graph used for BAM output.
I/O-g GRAPH_NAME, --graph-name GRAPH_NAMENoGBWTGraph used for mapping.
I/O-H GBWT_NAME, --gbwt-name GBWT_NAMENoGBWT index for mapping.
I/O--out-bam OUT_BAMYesPath of a BAM file for output.
I/O--ref-paths REF_PATHSNoPath to file containing ordered list of paths in the graph, one per line or HTSlib .dict, for HTSLib @SQ headers.
I/O--out-duplicate-metrics OUT_DUPLICATE_METRICSNoPath of duplicate metrics file after marking duplicates.
Tool--read-group READ_GROUPNoRead group ID for this run.
Tool--sample SAMPLENoSample (SM) tag for read group in this run.
Tool--read-group-library READ_GROUP_LIBRARYNoLibrary (LB) tag for read group in this run.
Tool--read-group-platform READ_GROUP_PLATFORMNoPlatform (PL) tag for read group in this run; refers to platform/technology used to produce reads.
Tool--read-group-pu READ_GROUP_PUNoPlatform unit (PU) tag for read group in this run.
Tool--prune-low-cplxNoPrune short and low complexity anchors during linear format realignment.
Tool--max-fragment-length MAX_FRAGMENT_LENGTHNoAssume that fragment lengths should be smaller than MAX-FRAGMENT-LENGTH when estimating the fragment length distribution.
Tool--fragment-mean FRAGMENT_MEANNoForce the fragment length distribution to have this mean.
Tool--fragment-stdev FRAGMENT_STDEVNoForce the fragment length distribution to have this standard deviation.
Tool--align-onlyNoGenerate output BAM after vg-giraffe alignment. The output will not be co-ordinate sorted.
Tool--copy-commentNoAppend FASTQ comment to BAM output via auxiliary tag.
Tool--no-markdupsNoDo not perform the Mark Duplicates step. Return BAM after sorting.
Tool--markdups-single-ended-start-endNoMark duplicate on single-ended reads by 5' and 3' end.
Tool--ignore-rg-markdups-single-endedNoIgnore read group info in marking duplicates on single-ended reads. This option must be used with `--markdups-single-ended-start-end`.
Tool--markdups-assume-sortorder-querynameNoAssume the reads are sorted by queryname for marking duplicates. This will mark secondary, supplementary, and unmapped reads as duplicates as well. This flag will not impact variant calling while increasing processing times.
Tool--markdups-picard-version-2182NoAssume marking duplicates to be similar to Picard version 2.18.2.
Tool--optical-duplicate-pixel-distance OPTICAL_DUPLICATE_PIXEL_DISTANCENoThe maximum offset between two duplicate clusters in order to consider them optical duplicates. Ignored if --out-duplicate-metrics is not passed.
Tool--monitor-usageNoMonitor approximate CPU utilization and host memory usage during execution.
Tool--max-read-length MAX_READ_LENGTHNoMaximum read length/size (i.e., sequence length) used for giraffe and filtering FASTQ input. (default: 480)
Tool--min-read-length MIN_READ_LENGTHNoMinimum read length/size (i.e., sequence length) used for giraffe and filtering FASTQ input. (default: 1)
Performance--nstreams NSTREAMSNoNumber of streams per GPU to use; use 'auto' to set from GPU and host memory (may enable low-memory, dozeu/minimizers for SE). Integer overrides. More streams increases device and host memory usage. (default: auto)
Performance--num-cpu-threads-per-gpu NUM_CPU_THREADS_PER_GPUNoNumber of primary CPU threads to use per GPU. (default: 16)
Performance--batch-size BATCH_SIZENoBatch size used for processing alignments. (default: 10000)
Performance--write-threads WRITE_THREADSNoNumber of threads used for writing and pre-sorting output. (default: 4)
Performance--gpuwriteNoUse one GPU to accelerate writing final BAM/CRAM.
Performance--gpuwrite-deflate-algo GPUWRITE_DEFLATE_ALGONoChoose the nvCOMP DEFLATE algorithm to use with --gpuwrite. Note these options do not correspond to CPU DEFLATE options. Valid options are 1, 2, and 4. Option 1 is fastest, while options 2 and 4 have progressively lower throughput but higher compression ratios. The default value is 1 when the user does not provide an input (i.e., None).
Performance--gpusortNoUse GPUs to accelerate sorting and marking.
Performance--use-gdsNoUse GPUDirect Storage (GDS) to enable a direct data path for direct memory access (DMA) transfers between GPU memory and storage. Must be used concurrently with `--gpuwrite`. Please refer to Parabricks Documentation > Best Performance for information on how to set up and use GPUDirect Storage.
Performance--memory-limit MEMORY_LIMITNoSystem memory limit in GBs during sorting and postsorting. By default, the limit is half of the total system memory. (default: 62)
Performance--low-memoryNoUse low memory mode; will lower the number of streams per GPU and decrease the batch size.
Performance--minimizers-gpuNo(SE only) Use GPU for minimizers and seeds. (default: False)
Performance--work-queue-capacity WORK_QUEUE_CAPACITYNoSoft limit for the capacity of the work queues in between stages. (default: 40)
Runtime--verboseNoEnable verbose output.
Runtime--x3NoShow full command line arguments.
Runtime--logfile LOGFILENoPath to the log file. If not specified, messages will only be written to the standard error output.
Runtime--tmp-dir TMP_DIRNoFull path to the directory where temporary files will be stored. (default: .)
Runtime--with-petagene-dir WITH_PETAGENE_DIRNoFull path to the PetaGene installation directory. By default, this should have been installed at /opt/petagene. Use of this option also requires that the PetaLink library has been preloaded by setting the LD_PRELOAD environment variable. Optionally set the PETASUITE_REFPATH and PGCLOUD_CREDPATH environment variables that are used for data and credentials. Optionally set the PetaLinkMode environment variable that is used to further configure PetaLink, notably setting it to "+write" to enable outputting compressed BAM and .fastq files.
Runtime--keep-tmpNoDo not delete the directory storing temporary files after completion.
Runtime--no-seccomp-overrideNoDo not override seccomp options for docker.
Runtime--versionNoView compatible software versions.
Runtime--preserve-file-symlinksNoOverride default behavior to keep file symlinks intact and *not* resolve the symlink.
Runtime--num-gpus NUM_GPUSNoNumber of GPUs to use for a run. (default: 1)