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.

--assembly_accession

Must match pattern ^GCA_[0-9]{9}\.[0-9]+$

Accession number of the assembly to download. Typically of the form GCA_*.*

--assembly_name

Must match pattern ^\S+$

Name of the assembly, as on the NCBI website, e.g. gfLaeSulp1.1.

--outdir^*

This parameter is required

The output directory where the results will be saved. Not considered for sample-sheet entries that have an absolute path.

--input

Must match pattern ^\S+\.csv$

Path to comma-separated file containing information about the assemblies to download. Used for bulk download of many assemblies.

The file has to be a comma-separated file with three columns, and a header row. The columns names must be outdir, assembly_accession, and assembly_name.

--ftp_root^*

This parameter is required

Root location of the NCBI FTP, in which all assemblies can be found. Access protocol is actually not limited to FTP, and we use HTTPS by default.

--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.

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'