Cast string "array.id" to integer, makeClusterFunctionTorque with SSH

[dagola]

asIntexpects a numeric input value. array.id as output from Sys.getenv is a string.

In a multi-node cluster site only one node may be able to accept Torque
commands. If this node is accessible via SSH, BatchJobs can run on any
other node tunnelling the Torque command to that node.

[mllg]

Do you login on the master via ssh to call qselect?

[dagola]

Yes, I do. Please see a17396e: in clusterFunctionsTorque all runOSCommandLinux calls are done with the ssh flag.

[mllg]

I'm amazed that this works! We've to check this on some more systems though.

[dagola]

Why should it not work? runOSCOmmandLinux supports running shell commands through ssh "natively".

[mllg]

Why should it not work? runOSCOmmandLinux supports running shell commands through ssh "natively".

I need to double check that exit codes are correctly forwarded and quoting is correct.

[mllg]

1. runOSCommandLinux seems to behave well in my interactive tests.
2. You must have a shared file system. I've tried sshfs and encountered several problems because my local $HOME differs from my remote $HOME. We currently do not have a mechanism to deal with this situation, and symlinking does not seem to help.

@berndbischl Your opinion?

[dagola]

That's true, a shared file system is still needed.
The main reason why I think this is useful, at least at our site, is due to only our master node accepts jobs. But the master node has much less resources than other nodes, so sometimes we need to send a job from a R script running on a other node trough ssh to the master node.
Btw, in our special environment it is even possible to send jobs from a local machine via ssh to the master node. The remote $HOME is not mounted directly at remote / only, but also at /some/path/home. So it is possible to mount it locally via sshfs exactly at the same path as remote. So the paths are equal and it is possible to work with R and BatchJobs in the sshfs mount.

[mllg]

If Bernd does not have any objections, I'm afraid the SSH stuff will not make it into the next release because I do not have enough time to test this. But I would pull your changes after October 20th and try to generalize it for other cluster functions as well.

[berndbischl]

@mllg
I trust you on this and I am also gone for the next few days without time. Lets talk about it in a few hours and decide. But I guess your plan is already best (the only reasonable solution).