Hi everyone, im getting an issue from kaiju nr_euk (nf-core/taxprofiler). Im running this command:

nextflow run nf-core/taxprofiler -r 1.2.4 \
  -profile apptainer \
  -c nextflow.config \
  --input samples_input.csv \
  --databases databases_input.csv \
  --outdir "$OUTDIR" \
  --perform_longread_qc \
  --longread_qc_skipadaptertrim \
  --run_kaiju \
  --run_krona \
  --run_profile_standardisation \
  -resume

and it always gives this error:

Command error:
  .command.sh: line 10:    54 Segmentation fault      (core dumped) kaiju -z 36 -t $dbnodes -f $dbname -o RFormosa_211022_run1_kaiju_nr_euk.kaiju.tsv -i RFormosa_211022_run1_filtered.fastq.gz

Im running on my big mem node (HPC) with 1tb of RAM with 54 cpus, and allocating all of these resources in slurm. My question could be if there is any parameter inside of taxprofiler that could be limiting resources, and then gives this error ?

Yes, all nf-core pipeline come with 'sensisble' defaults not to risk burning money

You likely need to configure the pipeline to your available computational resources to you machine or infrastructure. Please see the following two(!) sections: - https://nf-co.re/docs/running/configuration/nextflow-for-your-system#workflow-resources - https://nf-co.re/docs/running/configuration/nextflow-for-your-system#set-max-resources of the documentation for more information.

For info on how to increase resources for a particular module

ohhh, i will have a look. Thank you!

If you want to try it would probably involve something like this in a config file (used with

-c

):

process {
    withName: 'MY_PROCESS' {
        memory = nnn.G
    }
}

That said, you are getting a segmentation fault, which is the program trying to access a memory location that either does not exist or does not "belong" to that program (i.e. an "illegal" operation). In all cases this is an error or oversight by the programmer. If the programmer was under the assumption that there is more memory available than there actually is (because the program failed to check that), giving it more memory can help avoid the crash of program. But if the segfault is based e.g. on a math error in a pointer calculation, this will not help. The only thing you can do (besides fixing the bug in the program) is try different parameter settings or possibly try to remove input data that caused the crash, in the hope that you find some combination that by-passes the problematic part of the code, but there is no guaranteed that it will work. Before you go there, check the integrity of your container (if that's what you using), to make sure the problem is not caused by some kind of corruption. (Either you have a checksum, or you can download it again and compare if it's identical.)

Yeah. Those are all valid points @Thomas Danhorn! That said OOM seg fault is very likely because this is a metagenomics tool (this is a common error with such tools) that normally does need a huge amount of memory, and NR is absolutely humongous 😬