Launch pipeline » sanger-tol

Nextflow command-line flags

General Nextflow flags to control how the pipeline runs.

These are not specific to the pipeline and will not be saved in any parameter file. They are just used when building the `nextflow run` launch command.

-name

Must match pattern ^[a-zA-Z0-9-_]+$

Unique name for this nextflow run

-profile

Configuration profile

-work-dir

Work directory for intermediate files

-resume

True

False

Resume previous run, if found

Execute the script using the cached results, useful to continue executions that was stopped by an error

Input/output options

Define where the pipeline should find input data and save output data.

--input^*

Must match pattern ^\S+\.yaml$

Path to YAML file containing information about the samples in the experiment.

You will need to create a design file with information about the samples in your experiment before running the pipeline. Use this parameter to specify its location. It has to be a comma-separated file with 3 columns, and a header row. See usage docs.

--outdir^*

This parameter is required

The output directory where the results will be saved. You have to use absolute paths to storage on Cloud infrastructure.

--juicer

True

False

If false then turn off Juicer generation

--binfile

True

False

If false then turn off bin file generation

--steps

A csv list of steps to skip

--email

Must match pattern ^([a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$

Email address for completion summary.

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.

--trace_timestamp

Not to be used, this passes data from the config into the pipeline

Don't use this param, required for TreeValProjects Summary functions

Institutional config options

Parameters used to describe centralised config profiles. These should not be edited.

The centralised nf-core configuration profiles use a handful of pipeline parameters to describe themselves. This information is then printed to the Nextflow log when you run a pipeline. You should not need to change these values when you run a pipeline.

--custom_config_version

Git commit id for Institutional configs.

--custom_config_base

Base directory for Institutional configs.

If you're running offline, Nextflow will not be able to fetch the institutional config files from the internet. If you don't need them, then this is not a problem. If you do need them, you should download the files from the repo and tell Nextflow where to find them with this parameter.

--config_profile_name

Institutional config name.

--config_profile_description

Institutional config description.

--config_profile_contact

Institutional config contact information.

--config_profile_url

Institutional config URL link.

Max job request options

Set the top limit for requested resources for any single job.

If you are running on a smaller system, a pipeline step requesting more resources than are available may cause the Nextflow to stop the run with an error. These options allow you to cap the maximum resources requested by any single job so that the pipeline will run on your system. Note that you can not _increase_ the resources requested by any job using these options. For that you will need your own configuration file. See [the nf-core website](https://nf-co.re/usage/configuration) for details.

--max_cpus

Must be an integer

Maximum number of CPUs that can be requested for any single job.

Use to set an upper-limit for the CPU requirement for each process. Should be an integer e.g. --max_cpus 1

--max_memory

Must match pattern ^\d+(\.\d+)?\.?\s*(K|M|G|T)?B$

Maximum amount of memory that can be requested for any single job.

Use to set an upper-limit for the memory requirement for each process. Should be a string in the format integer-unit e.g. --max_memory '8.GB'

--max_time

Must match pattern ^(\d+\.?\s*(s|m|h|day)\s*)+$

Maximum amount of time that can be requested for any single job.

Use to set an upper-limit for the time requirement for each process. Should be a string in the format integer-unit e.g. --max_time '2.h'