I am retrieving fastqs by running fetchngs on an HPC which uses SGE. Noting the recommendation about accessions with more than 2 fastq files (https://nf-co.re/fetchngs/1.12.0/docs/usage/) I am specifying sratools as the download method. My command is:

nextflow run nf-core/fetchngs -profile dice,singularity -c sratools.config --download_method sratools --input ids.csv --outdir inputFastq

nextflow.config is:

profiles {
  dice {
    process {
      executor = 'sge'
      penv = 'smp'
      clusterOptions = '-S /bin/bash'
        }
    }
}

ids.csv is:

SRR10985015

sratools.config is:

process {
    withName: SRATOOLS_PREFETCH {
        ext.args = '--max-size 60g'
    }
}

This runs successfully (hooray); however along the way the SRATOOLS_FASTERQDUMP step accumulates some large temporary files - at one stage the work directory in which fasterq-dump runs get to be over 317G in size (in comparison the final fastq files are only 49G in total) I would much prefer to have temporary files saved in scratch space on the execution node rather than under nextflow’s work directory. I notice fasterq-dump has this option:

-t|--temp                        where to put temp. files dflt=curr dir

How would I configure the workflow so that this option is used to specify the execution node’s local scratch disk?

I think you should be able to use a custom config with a

ext.args

for

SRATOOLS_FASTERQDUMP

as you did with

SRATOOLS_PREFETCH

and specify

-t /path/to/scratch

Thanks Maxime. The scratch directive is easy and works for me.

process {

withName: SRATOOLS_FASTERQDUMP {

clusterOptions = '-S /bin/bash -l tmp_requested=400G'

scratch = true

}

wonderful