nf-core/rnadnavar

A design file with information about the samples in your experiment. Use this parameter to specify the location of the input files. It has to be a comma-separated file with a header row. See usage docs.

If no input file is specified, sarek will attempt to locate one in the {outdir} directory. If no input should be supplied, i.e. when --step is supplied or --build_from_index, then set --input false

Use the the tool FastP to split FASTQ file by number of reads. This parallelizes across fastq file shards speeding up mapping. Note although the minimum value is 250 reads, if you have fewer than 250 reads a single FASTQ shard will still be created.

The pipeline starts from this step and then runs through the possible subsequent steps.

If the parameter --split-fastq is used, the sharded bam files are merged and converted to CRAM before saving them.

If the parameter --split-fastq is used, the sharded bam files are merged before saving them.

Avoids STAR indexing otherwise

Avoids BWA indexing otherwise

If using a reference genome configured in the pipeline using iGenomes, use this parameter to give the ID for the reference. This is then used to build the full paths for all required reference genome files e.g. --genome GRCh38.

See the nf-core website docs for more details.

This parameter can be used if there is an pre-defined STAR index available. You can either give the full path to the index directory or a compressed file in tar.gz format.

This parameter can be used if there is an pre-defined STAR index available. You can either give the full path to the index directory or a compressed file in tar.gz format.

This parameter enables STAR to perform 2-pass mapping. Default true.

Do not use parameter --sjdbGTFfile <GTF file> during the STAR genomeGenerate process.

This parameter specifies the maximum available RAM (bytes) for sorting BAM during STAR alignment.

This parameter specifies the number of bins to be used for coordinate sorting during STAR alignment step.

Specify the read length for the STAR aligner.

Intervals are parts of the chopped up genome used to speed up preprocessing and variant calling. See --intervals for more info.

Changing this parameter, changes the number of intervals that are grouped and processed together. Bed files from target sequencing can contain thousands or small intervals. Spinning up a new process for each can be quite resource intensive. Instead it can be desired to process small intervals together on larger nodes.
In order to make use of this parameter, no runtime estimate can be present in the bed file (column 5).

If you use AWS iGenomes, this has already been set for you appropriately.

This parameter is mandatory if --genome is not specified.

If you use AWS iGenomes, this has already been set for you appropriately.

NB If none provided, will be generated automatically from the FASTA reference. Combine with --save_reference to save for future runs.

If you use AWS iGenomes, this has already been set for you appropriately.

NB If none provided, will be generated automatically from the known index file, if provided. Combine with --save_reference to save for future runs.

Set this parameter, if you wish to save all computed reference files. This is useful to avoid re-computation on future runs.

Set this parameter, if you wish to compute and save all computed reference files. No alignment or any other downstream steps will be performed.

Set this parameter, if you wish to download annotation cache.

HiSAT2 requires a huge amount of RAM to build a genome index for larger genomes, if including splice sites and exons e.g. the human genome might typically require 200GB. If you specify less than this threshold for the HISAT2_BUILD process then the splice sites and exons will be ignored, meaning that the process will require a lot less memory. If you are working with a small genome, set this parameter to a lower value to reduce the threshold for skipping this check. If using a larger genome, consider supplying more memory to the HISAT2_BUILD process.

This parameter is mandatory if --genome is not specified.

This parameter must be specified if --genome or --gtf are not specified.

Use this to perform adapter trimming. Adapter are detected automatically by using the FastP flag --detect_adapter_for_pe. For more info see FastP.

Multiple tools separated with commas.

Variant Calling:

Somatic variant calling can currently only be performed with the following variant callers:

• SNPs/Indels: Mutect2, Strelka2, SAGE

NB Mutect2 for somatic variant calling cannot be combined with --no_intervals

Annotation:

• VEP (only).

NB As RNADNAVAR will use bgzip and tabix to compress and index VCF files annotated, it expects VCF files to be sorted when starting from --step annotate.

This parameter must be a combination of the following values: manta, sage, mutect2, strelka, vep, consensus, filtering, norm, rna_filtering, vcf2maf, preprocessing, realignment, rescue

Multiple tools can be specified, separated by commas.

NB --skip_tools baserecalibrator_report is actually just not saving the reports.
NB --skip_tools markduplicates_report does not skip MarkDuplicates but prevent the collection of duplicate metrics that slows down performance.

This parameter must be a combination of the following values: contamination, learnreadorientation, baserecalibrator, baserecalibrator_report, bcftools, documentation, fastqc, markduplicates, markduplicates_report, mosdepth, multiqc, samtools, vcftools, versions, splitncigar, realignment, filtering, variant_calling, rescue

With this parameter flags in various tools are set for targeted sequencing data. It is recommended to enable for whole-exome and panel data analysis.

Sarek will build missing indices automatically if not provided. Set --bwa false if indices should be (re-)built.
If DragMap is selected as aligner, it is recommended to skip baserecalibration with --skip_tools baserecalibrator. For more info see here.

This may either be in the form of FastQ or BAM files depending on the options available for that particular tool.

By default, intermediate BAM files will not be saved. The final BAM files created after the appropriate filtering step are always saved to limit storage usage. Set this parameter to also save other intermediate BAM files.

Name of variant calling tools separated by commans used to generate VCF/MAF input files.

Specify true for removing duplicates from BAM file during Picard MarkDuplicates step.

Intervals are parts of the chopped up genome used to speed up preprocessing and variant calling. See --intervals for more info.

If --no_intervals is set no intervals will be taken into account for speed up or data processing.

To speed up preprocessing and variant calling processes, the execution is parallelized across a reference chopped into smaller pieces.

Parts of preprocessing and variant calling are done by these intervals, the different resulting files are then merged.
This can parallelize processes, and push down wall clock time significantly.

We are aligning to the whole genome, and then run Base Quality Score Recalibration and Variant Calling on the supplied regions.

Whole Genome Sequencing:

The (provided) intervals are chromosomes cut at their centromeres (so each chromosome arm processed separately) also additional unassigned contigs.

We are ignoring the hs37d5 contig that contains concatenated decoy sequences.

The calling intervals can be defined using a .list or a BED file.
A .list file contains one interval per line in the format chromosome:start-end (1-based coordinates).
A BED file must be a tab-separated text file with one interval per line.
There must be at least three columns: chromosome, start, and end (0-based coordinates).
Additionally, the score column of the BED file can be used to provide an estimate of how many seconds it will take to call variants on that interval.
The fourth column remains unused.

|chr1|10000|207666|NA|47.3|  

This indicates that variant calling on the interval chr1:10001-207666 takes approximately 47.3 seconds.

The runtime estimate is used in two different ways.
First, when there are multiple consecutive intervals in the file that take little time to compute, they are processed as a single job, thus reducing the number of processes that needs to be spawned.
Second, the jobs with largest processing time are started first, which reduces wall-clock time.
If no runtime is given, a time of 1000 nucleotides per second is assumed. See -nucleotides_per_second on how to customize this.
Actual figures vary from 2 nucleotides/second to 30000 nucleotides/second.
If you prefer, you can specify the full path to your reference genome when you run the pipeline:

NB If none provided, will be generated automatically from the FASTA reference
NB Use --no_intervals to disable automatic generation.

Targeted Sequencing:

The recommended flow for targeted sequencing data is to use the workflow as it is, but also provide a BED file containing targets for all steps using the --intervals option. In addition, the parameter --wes should be set.
It is advised to pad the variant calling regions (exons or target) to some extent before submitting to the workflow.

The procedure is similar to whole genome sequencing, except that only BED file are accepted. See above for formatting description.
Adding every exon as an interval in case of WES can generate >200K processes or jobs, much more forks, and similar number of directories in the Nextflow work directory. These are appropriately grouped together to reduce number of processes run in parallel (see above and --nucleotides_per_second for details).
Furthermore, primers and/or baits are not 100% specific, (certainly not for MHC and KIR, etc.), quite likely there going to be reads mapping to multiple locations.
If you are certain that the target is unique for your genome (all the reads will certainly map to only one location), and aligning to the whole genome is an overkill, it is actually better to change the reference itself.

Set this parameter to decide the number of splits for the gene interval list file.

For details, see here.

Set this parameter to your e-mail address to get a summary e-mail with details of the run sent to you when the workflow exits. If set in your user config file (~/.nextflow/config) then you don't need to specify this on the command line for every run.