These are chat archives for nextflow-io/nextflow

30th
Apr 2016
Jason Byars
@jbyars
Apr 30 2016 03:35
It's a good idea. Unfortunately, when I run with bash -x .command.run the script runs just fine on the worker node. Looks like I'm going to be scratching my head a bit on this one. Thanks for the suggestion.
Evan Floden
@evanfloden
Apr 30 2016 03:58
I’ve previously had similar problems. Are you calling R with /usr/bin/env R by any chance?
Jason Byars
@jbyars
Apr 30 2016 03:58
/usr/bin/env Rscript
what did you run into?
Evan Floden
@evanfloden
Apr 30 2016 04:02

yeah, exactly! This can invoke different versions of R/Rscript between say a login node and a working node. In my case, we recently upgraded our worker nodes to el7. You may need to use something like:

module load R/3.0.1-goolf-1.4.10-no-OFED-bare

I don’t know anything about module to be honest but Paolo suggested it. I would guess you are calling a different R installation on the worker node.

you could quickly debug it by changing /usr/bin/env Rscriptto /<your local R>/bin/Rscript
Jason Byars
@jbyars
Apr 30 2016 04:05
module is a tool that makes manipulating your environment convenient. I will try that again.
the head scratcher for me at the moment is the .libPaths() results are the same in both situations, but the installed.packages() differs depending which way I run.
Jason Byars
@jbyars
Apr 30 2016 04:26
sure enough, the jobs were running on the wrong nodes. Thanks!
Evan Floden
@evanfloden
Apr 30 2016 04:26
Great, glad you figured it out!