These are chat archives for nextflow-io/nextflow

19th
Jun 2018
LukeGoodsell
@LukeGoodsell
Jun 19 2018 15:34

Is there a good way to avoid the output file "is out of the scope of process working dir” exception? I have a tool that has to write a file to a specific path outside of the working directory, and I need to use this file downstream in the Nextflow script.

My current solution is to create a hard link to this external location within the working directory and then use that version of the file, but this is extra boiler plate code that I’d rather avoid.

Nextflow seems like it should be able to handle it, except for these assertions https://github.com/nextflow-io/nextflow/blob/master/src/main/groovy/nextflow/script/ParamsOut.groovy#L469

Paolo Di Tommaso
@pditommaso
Jun 19 2018 15:35
maybe storeDir ?
LukeGoodsell
@LukeGoodsell
Jun 19 2018 15:38
Not sure I understand. storeDir will allow me to move an output file from the working directory to another directory, but my problem is I’m using a tool that writes to a specific external path directly, and I want to capture it as an output for use in a subsequent channel.
Paolo Di Tommaso
@pditommaso
Jun 19 2018 15:38
I see, if so I fear no
you can always add a mv /your/tool/abs/path $PWD
tho it's quite ugly
LukeGoodsell
@LukeGoodsell
Jun 19 2018 15:45
Yeah, I’m basically doing that with ln instead, but it’d be easier to maintain if I didn’t have to, as I have to leave a comment every time explaining why it’s done that way for other team members.
Thanks, though.
Paolo Di Tommaso
@pditommaso
Jun 19 2018 15:45
welcome
Ryo Kita
@rkita
Jun 19 2018 16:10
Hi everyone, I am running a job with a SLURM executor and default errorstrategy. As expected, if an error occurs, all pending jobs are killed except the jobs that are already running. If I were to restart the nextflow pipeline while those previously running jobs are still going, does nextflow know to skip those previously running jobs, or does it try to resubmit another job on top of it? I'm having difficulty reproducing the error to test this out with my current pipeline...
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:13
all pending jobs are killed except the jobs that are already running
it should kill also the the running ones
Ryo Kita
@rkita
Jun 19 2018 16:14
? Are you saying that it should kill the running ones when I restart the nextflow?
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:15
No, I'm saying by default as soon there's an error NF should kill all pending and running jobs
Ryo Kita
@rkita
Jun 19 2018 16:17
Hmm, ok, that's not happening for me. I'll look into this some more.
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:19
NF uses scancel <job id> to kill a running job, can you confirm that's working in your cluster ?
Ryo Kita
@rkita
Jun 19 2018 16:20
Yes it's working
However, even though it's working now, I'm worried that it might have been working when the pipeline failed. My error for the pipeline was:
"sbatch: error: Batch job submission failed: Socket timed out on send/recv operation"
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:23
ah
Ryo Kita
@rkita
Jun 19 2018 16:24
I'm thinking changing the errorStrategy to "retry" would be best. any other ideas?
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:24
basically it failed to submit one or more jobs, therefore the execution stops
Ryo Kita
@rkita
Jun 19 2018 16:24
right, and since it fails to submit the job due to the socket time-out, it probably can't scancel the job either
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:24
mm, it looks your cluster cannot cope with the jobs submission rate
you may try to use executor. submitRateLimit = '<rate>' to reduce it
Ryo Kita
@rkita
Jun 19 2018 16:27
excellent. i'll give that a try. thank you!
Paolo Di Tommaso
@pditommaso
Jun 19 2018 16:28
:+1: