These are chat archives for nextflow-io/nextflow

24th
Apr 2019
Thomas Zichner
@zichner
Apr 24 05:51
Thanks for the information!
Anna Syme
@AnnaSyme
Apr 24 10:23
Hi all; I have a question about the first line in a nextflow script (the very first line, not those in each code block) - my understanding is that this tells the script to run with nextflow :#!/usr/bin/env nextflow. Why does something like #!/usr/bin/bash also work?
Paolo Di Tommaso
@pditommaso
Apr 24 10:27
that's not NF specific
Anna Syme
@AnnaSyme
Apr 24 10:33
No, but why does it work if bash is in the shebang rather than nextflow ?
Paolo Di Tommaso
@pditommaso
Apr 24 10:36
not sure it works, how is you command line
Anna Syme
@AnnaSyme
Apr 24 10:43
hmmm actually I think it's because I run the scripts with nextflow run myscript.nf which overrides the shebang interpreter. Not super important, I was just curious.
Paolo Di Tommaso
@pditommaso
Apr 24 10:44
exactly
the shebanq applies only when you run the script as an executable
Anna Syme
@AnnaSyme
Apr 24 10:44
I see - thanks!
Paolo Di Tommaso
@pditommaso
Apr 24 10:44
welcome!
micans
@micans
Apr 24 10:44
aha. nextflow only allows # on first line I assume?
Paolo Di Tommaso
@pditommaso
Apr 24 10:45
I think it's how shebang is supposed to work
Anna Syme
@AnnaSyme
Apr 24 10:45
I think it allows it in some code blocks too as comments, but other comments need to be in groovy format // ?
micans
@micans
Apr 24 10:46
yes, I mean with nextflow run myscript.nf ... the kernel never sees the shebang line, but nextflow does.
Anna Syme
@AnnaSyme
Apr 24 10:47
I don't know if nextflow would see it either?
Paolo Di Tommaso
@pditommaso
Apr 24 10:47
fair enough, yes NF uses // as comment
therefore it must the first line
Anthony Ferrari
@af8
Apr 24 10:49
I am setting up an HPC cluster for a project. It is planned to test Nextflow in production associated to Singularity containers. I have two questions: 1) is there some recommended version of singularity for use with Nextflow or going for 3.1 is just fine ? 2) to your knowledge is there some version of singularity which is more stable and recommended for production use ? (I know this one is out of the scope of this chat)
Paolo Di Tommaso
@pditommaso
Apr 24 13:49
the latests should work fine, for stability likely @micans knows more
micans
@micans
Apr 24 14:03
@af8 We have mostly used an old singularity (2.5.2). There is an issue with singularity and not being able to bind/mount the same path twice: see e.g. (nextflow-io/nextflow#662). Apparently this was fixed in a recent version of singularity but I haven't been able to test this yet. This issue can be worked around, IIRC, by setting the work directory using -w (and using the runOptions = '-B /some/path' settings in the singularity config scope).
Paolo Di Tommaso
@pditommaso
Apr 24 14:06
Thanks Stijn
micans
@micans
Apr 24 14:07
:+1:
Anthony Ferrari
@af8
Apr 24 14:54
Thanks guys.
Pierre Lindenbaum
@lindenb
Apr 24 19:01
Hi all, I'm working on my custom Executor https://github.com/lindenb/nextflow/blob/pl_cng/modules/nextflow/src/main/groovy/nextflow/executor/CngExecutor.groovy ; There was something new today ( I may be wrong with the following statement but I'm looking for an idea to debug/explore the code) . Some of my jobs are submitted (state==SUBMITTED) but on my server side, for an unknown reason the job fails while the job directory is created and contains (and only contains) .command.sh and .command.run . At this point, as far as I understand (? not sure...) I'm in a no-man's-land: the job is always in state SUBMITTED and nextflow doesn'invoke queueStatusCommand that would show him that the job is in state FAILED. Could it be possible ? How/where could I ask nextflow to force to have a look at the job status ? Thanks.