|
2 | 2 |
|
3 | 3 | nf-core pipelines have been successfully configured for use on the [Gadi HPC](https://opus.nci.org.au/display/Help/Gadi+User+Guide) at the National Computational Infrastructure (NCI), Canberra, Australia. |
4 | 4 |
|
5 | | -To run an nf-core pipeline at NCI Gadi, run the pipeline with `-profile singularity,nci_gadi`. This will download and launch the [`nci_gadi.config`](../conf/nci_gadi.config) which has been pre-configured with a setup suitable for the NCI Gadi HPC cluster. Using this profile, a docker image containing all of the required software will be downloaded, and converted to a Singularity image before execution of the pipeline. |
| 5 | +To run an nf-core pipeline at NCI Gadi, run the pipeline with `-profile singularity,nci_gadi`. This will download and launch the [`nci_gadi.config`](https://github.com/nf-core/configs/blob/master/conf/nci_gadi.config) which has been pre-configured with a setup suitable for the NCI Gadi HPC cluster. |
6 | 6 |
|
7 | 7 | ## Access to NCI Gadi |
8 | 8 |
|
9 | 9 | Please be aware that you will need to have a user account, be a member of an Gadi project, and have a service unit allocation to your project in order to use this infrastructure. See the [NCI user guide](https://opus.nci.org.au/display/Help/Getting+Started+at+NCI) for details on getting access to Gadi. |
10 | 10 |
|
11 | 11 | ## Launch an nf-core pipeline on Gadi |
12 | 12 |
|
13 | | -### Prerequisites |
14 | | - |
15 | | -Before running the pipeline you will need to load Nextflow and Singularity, both of which are globally installed modules on Gadi. You can do this by running the commands below: |
| 13 | +Before running the pipeline, you will need to load Nextflow and Singularity, both of which are globally installed modules on Gadi (under `/apps`). You can do this by running the commands below: |
16 | 14 |
|
17 | 15 | ```bash |
18 | 16 | module purge |
19 | | -module load nextflow singularity |
| 17 | +module load nextflow |
| 18 | +module load singularity |
20 | 19 | ``` |
21 | 20 |
|
22 | | -### Execution command |
| 21 | +:::warning |
| 22 | +The version of Nextflow installed on Gadi has been modified to make it easier to specify resource options for jobs submitted to the cluster through the Nextflow process block (see NCI's [Gadi user guide](https://opus.nci.org.au/display/DAE/Nextflow) for more details). |
| 23 | +::: |
23 | 24 |
|
24 | | -```bash |
25 | | -module load nextflow |
26 | | -module load singularity |
| 25 | +You can then run the pipeline using: |
27 | 26 |
|
| 27 | +```bash |
28 | 28 | nextflow run <nf-core_pipeline>/main.nf \ |
29 | 29 | -profile singularity,nci_gadi \ |
30 | 30 | <additional flags> |
31 | 31 | ``` |
32 | 32 |
|
33 | 33 | ### Cluster considerations |
34 | 34 |
|
35 | | -Please be aware that as of July 2023, NCI Gadi HPC queues **do not** have external network access. This means you will not be able to pull the workflow code base or containers if you submit your `nextflow run` command as a job on any of the standard job queues. NCI currently recommends you run your Nextflow head job either in a GNU screen or tmux session from the login node or submit it as a job to the [copyq](https://opus.nci.org.au/display/Help/Queue+Structure). See the [nf-core documentation](https://nf-co.re/docs/usage/offline) for instructions on running pipelines offline. |
| 35 | +#### External network access |
| 36 | + |
| 37 | +Please be aware that NCI Gadi HPC compute nodes **do not** have external network access. This means you will not be able to pull the workflow codebase or containers if you submit your `nextflow run` command as a job on any of the standard job queues (see the [nf-core documentation](https://nf-co.re/docs/usage/offline) for instructions on running pipelines offline). NCI currently recommends you run your Nextflow head job either in a GNU screen or tmux session within a [persistent session](https://opus.nci.org.au/spaces/Help/pages/241926895/Persistent+Sessions), or submit it as a job to the [copyq](https://opus.nci.org.au/display/Help/Queue+Structure). |
| 38 | + |
| 39 | +For example, to run Nextflow in a GNU screen session within a persistent session: |
| 40 | + |
| 41 | +```bash |
| 42 | +persistent-sessions start -p <project> <ps_name> |
| 43 | +ssh <ps_name>.<user>.<project>.ps.gadi.nci.org.au |
| 44 | +screen -S <screen_name> |
| 45 | +nextflow run ... |
| 46 | +``` |
| 47 | + |
| 48 | +You can detach from the screen session using Ctrl+A, then D, and log out of the persistent session while the pipeline continues to run. Later, you can reconnect to the persistent session using the same `ssh` command and reattach to the screen session with: `screen -r <screen_name>`. |
| 49 | + |
| 50 | +#### Downloading containers |
| 51 | + |
| 52 | +This config requires Nextflow to use [Singularity](https://www.nextflow.io/docs/latest/container.html#singularity) to execute processes. Before any process can be executed, the nf-core pipeline will first download the required container image to a local cache. This cache location can be specified using either `$NXF_SINGULARITY_CACHEDIR` environment variable or the `singularity.cacheDir` setting in the Nextflow config file. `nci_gadi.config` specifies the download and storage location with: |
| 53 | + |
| 54 | +``` |
| 55 | +singularity.cacheDir = "/scratch/${params.nci_gadi_project}/${System.getenv('USER')}/nxf_singularity_cache" |
| 56 | +``` |
| 57 | + |
| 58 | +See the [project accounting](#project-accounting) section below for details on `params.nci_gadi_project`. |
| 59 | + |
| 60 | +Furthermore, Singularity uses the `$SINGULARITY_CACHEDIR` directory to store intermediate image layers and files during pulls (note that this cache is only used when the required container is not already available in Nextflow's own Singularity cache, specified by `$NXF_SINGULARITY_CACHEDIR` or `singularity.cacheDir`). By default, `$SINGULARITY_CACHEDIR` is set to `$HOME/.singularity/cache`. For pipelines involving a large number and/or large size of first-time container downloads, we recommend setting this environment variable to a scratch location to avoid exceeding your home filesystem quota. For example, before running your nextflow run command, you can set the environment variable to a location in the scratch filesystem with: |
| 61 | + |
| 62 | +``` |
| 63 | +export SINGULARITY_CACHEDIR=/scratch/$PROJECT/$USER/singularity_cache |
| 64 | +``` |
| 65 | + |
| 66 | +#### Gadi queues and job submission |
36 | 67 |
|
37 | 68 | This config currently determines which Gadi queue to submit your task jobs to based on the amount of memory required. For the sake of resource and cost (service unit) efficiency, the following rules are applied by this config: |
38 | 69 |
|
39 | 70 | - Tasks requesting **less than 128 Gb** will be submitted to the normalbw queue |
40 | 71 | - Tasks requesting **more than 128 Gb and less than 190 Gb** will be submitted to the normal queue |
41 | 72 | - Tasks requesting **more than 190 Gb and less than 1020 Gb** will be submitted to the hugemembw queue |
42 | 73 |
|
43 | | -See the NCI Gadi [queue limit documentation](https://opus.nci.org.au/display/Help/Queue+Limits) for details on charge rates for each queue. |
| 74 | +Note that these are only baseline queue settings and may be adjusted depending on the goals of your pipeline run and the most efficient use of the HPC. You can make a local copy of the `nci_gadi.config` and modify the queue assignments as needed for specific processes or process groups. See the NCI Gadi [queue limit documentation](https://opus.nci.org.au/display/Help/Queue+Limits) for more information on the available queues and their associated charge rates. |
44 | 75 |
|
45 | 76 | ### Project accounting |
46 | 77 |
|
47 | | -This config uses the PBS environmental variable `$PROJECT` to assign a project code to all task job submissions for billing purposes. If you are a member of multiple Gadi projects, you should confirm which project will be charged for your pipeline execution. You can do this using: |
| 78 | +This config uses `params.nci_gadi_project` to assign a project code to all task job submissions for billing purposes. By default, this is set to the environment variable `$PROJECT`. If you are a member of multiple Gadi projects, you can choose which project will be charged for your pipeline execution by setting `params.nci_gadi_project` (`--nci_gadi_project` on the command line) to the desired project code. |
48 | 79 |
|
49 | | -```bash |
50 | | -echo $PROJECT |
51 | | -``` |
| 80 | +Similarly, `params.nci_gadi_storage` (`--nci_gadi_storage` on the command line) is used to specify the storage locations that the pipeline needs to access. By default, this is set to `gdata/${params.nci_gadi_project}+scratch/${params.nci_gadi_project}`. |
52 | 81 |
|
53 | | -The version of Nextflow installed on Gadi has been modified to make it easier to specify resource options for jobs submitted to the cluster. See NCI's [Gadi user guide](https://opus.nci.org.au/display/DAE/Nextflow) for more details. You can manually override the `$PROJECT` specification by editing your local copy of the `nci_gadi.config` and replacing `$PROJECT` with your project code. For example: |
54 | | - |
55 | | -```nextflow |
56 | | -process { |
57 | | - executor = 'pbspro' |
58 | | - project = 'aa00' |
59 | | - storage = 'scratch/aa00+gdata/aa00' |
60 | | - ... |
61 | | -} |
62 | | -``` |
| 82 | +Note: The version of Nextflow installed on Gadi has been modified to make it easier to specify resource options for jobs submitted to the cluster through the Nextflow process block (see NCI's [Gadi user guide](https://opus.nci.org.au/display/DAE/Nextflow) for more details). The values specified through the parameters above are passed into the process block in the `nci_gadi.config`. |
63 | 83 |
|
64 | 84 | ## Resource usage |
65 | 85 |
|
66 | | -The NCI Gadi config summarises resource usage in a custom trace file that will be saved to your execution directory. However, for accounting or resource benchmarking purposes you may need to collect per-task service unit (SU) charges. Upon workflow completion, you can run the Sydney Informatics Hub's [gadi_nfcore_report.sh](https://github.com/Sydney-Informatics-Hub/HPC_usage_reports/blob/master/Scripts/gadi_nfcore_report.sh) script in your workflow execution directory with: |
| 86 | +To help monitor the service unit (SU) cost of running workflows on Gadi, a plugin has been developed to generate a report in CSV or JSON format upon workflow completion. The `nf-gadi` plugin is available via the Nextflow plugin registry and can be enabled by adding `-plugins nf-gadi` to your Nextflow run command. See the [plugin project repository](https://github.com/AustralianBioCommons/nf-gadi) for more details. |
| 87 | + |
| 88 | +Additionally, Sydney Informatics Hub also provides a script to collect per-task SU costs. Upon workflow completion, you can run the [gadi_nfcore_report.sh](https://github.com/Sydney-Informatics-Hub/HPC_usage_reports/blob/master/Scripts/gadi_nfcore_report.sh) in your workflow execution directory to collect resources from the PBS log files printed to each task's `.command.log`. Resource requests and usage for each process are summarised in the output `gadi-nf-core-joblogs.tsv` file. To run it, execute the following in your workflow execution directory: |
67 | 89 |
|
68 | 90 | ```bash |
69 | 91 | bash gadi_nfcore_report.sh |
70 | 92 | ``` |
71 | | - |
72 | | -This script will collect resources from the PBS log files printed to each task's `.command.log`. Resource requests and usage for each process is summarised in the output `gadi-nf-core-joblogs.tsv` file. This is useful for resource benchmarking and SU accounting. |
|
0 commit comments