rnaseq
rnaseq copied to clipboard
nf-core
NFCORE_RNASEQ:RNASEQ:ALIGN_STAR:STAR_ALIGN: failed with exit status 140 and 102
Hi, The nfcore/rnaseq pipeline (alignment with STAR-SALMON) runs for days and eventually fails with an exit status of 140. I checked the .out files, there was no explicit error.
Tracing the .out/ pipeline_info trace files and checking the work directory, I noticed the threads for mapping were created, but did not run till completion.
I noticed this step is running with 12 threads (--runThreadsN), and may not be enough. Thus I did a bash .command.run with --runThreadN set to 128 and the step completed successfully!
However, when I am using the --runThreadsN option as one of the parameters to --extra_star_align_args --runThreadsN 128 in the script, it takes the extra parameter but does not remove the old option from the command, while executing, giving me the following error of 102.
Is there a way to handle this?
Yes, you can increase the number of threads via a custom config. Please see the documentation on custom configs and Tuning workflow resources.
I have some doubts, though, if the number of threads were truly the root cause of your initial issue. Version 2.7.9a is a couple of years old and 2.7.10 fixed a number of issues that could cause STAR to hang in perpetuity I guess there are some default settings in the config, that my not be chosen wisely for plant genomes? Preferably, always try running the latest version of a pipeline and evaluate if any of the default settings can be improved for your reference genome.
Hi Matthias, Thank you for the response. I am assuming if I add more cpus, it will consider it as runThreadN value, right? and ofcourse I will assign more memory. I did try custom config with more memory, but did not work and maybe need more cpus, therefore more threads.
I am using a server to work with, I will check if star version can be updated to latest. Regarding default settings for plant genomes, they have worked in the past, and hence should not be an issue.
One thing to note, my input data is a special RNAseq output which may be the cause of the problem! Bowtie works fine with the data and so I thought with STAR it would work too!
Anyways, I will try to use custom configs and see if it gets resolved.
I am assuming if I add more cpus, it will consider it as runThreadN value, right?
Yes, because the module is written in that way. You can also change the number of CPUs utilized by a process via its config.
I am using a server to work with, I will check if star version can be updated to latest.
No need to do that. The version that is installed locally on the server does not matter, since the pipeline will run its own, (potentially different) version inside a Singularity (-profile singularity) or Docker (-profile docker) container (-profile conda is a third, but flaky and thus not really recommendable alternative). But that it is using that old STAR version tells me, that you are running an outdated pipeline version. Must be before 3.7 or so?
But yes, if it is some kind of special RNA-seq, you need to consider this in the tools' configs.
This thread has been quiet for a while, so @DollyCM I'm assuming that @MatthiasZepper 's assistance helped you out here. Please do reopen if you feel there's a pipeline bug that persists in the latest version.
Also note that the #rnaseq channel on the nf-core Slack is a good place to ask for help.