You might want to create an issue for this that reference this pull request. At least I tend to miss or forget about PR-only issues over time, and I know other repos like an issue with details where discussions can take place.

Now, I had a look atrunOSCommand(), which is what captures the output per

That captures both stdout and stderr. It could be that it would be more sane if those two are captured separately, e.g. something likestdout = TRUE andstderr = "error.log", where the expected output should go to stdout and info messages to stderr. To test if that would have helped you, if you do

$ sbatch --time=00:01:00 --mem=128G --wrap="hostname"> stdout.log2> stderr.log

what does

$ cat stdout.log$ cat stderr.log

output? With Slurm, you should see "Submitted batch job ..." instdout.log. Now, my hope is that "sbatch: INFO: Note that 128 GB per node will require a node with more than 128 GB memory because of overhead. Checkhttps://docs.unity.rc.umass.edu/nodes for an appropriate limit." ends up instderr.log for you.

Nice!

bcompton_umass_edu@login1:~$ sbatch --time=00:01:00 --mem=128G --wrap="hostname" > stdout.log 2> stderr.logbcompton_umass_edu@login1:~$ cat stdout.logSubmitted batch job 42933105bcompton_umass_edu@login1:~$ cat stderr.logsbatch: INFO: Note that 128 GB per node will require a node with more than 128 GB memory because of overhead. Check https://docs.unity.rc.umass.edu/nodes for an appropriate limit.bcompton_umass_edu@login1:~$

It looks like you can do a cleaner fix than what I came up with.

I've been prototyping with a more flexiblerunOSCommand() in myfuture.batchtools package. It has new argumentsstdout andstderr with defaultstdout = TRUE andstderr = TRUE (backward compatible). The specialstderr = NA with capture stderr separately from stdout.

@bwcompton , although it'sfuture.batchtools and notbatchtools, could you please give it a spin? If it works, then I can propose this newerrunOSCommand() version tobatchtools, plus adjustments tomakeClusterFunctionSlurm(), which I also patch infuture.batchtools.

To try it out, install it as:

remotes::install_github("futureverse/future.batchtools",ref="develop")

and then try it as:

library(future)plan(future.batchtools::batchtools_slurm)f<- future({  Sys.info()[["nodename"]] })v<- value(f)print(v)

Seehttps://future.batchtools.futureverse.org/reference/batchtools_slurm.html for how to control sbatch resource specifications.

Rscript: command not found

R is not available by default in your jobs. Do you load an environment module to get access to R? If so, specify that I'm in theresources argument, e.g.

plan(future.batchtools::batchtools_slurm, resources = list(modules = "r"))

This is illustrated also inhttps://future.batchtools.futureverse.org/reference/batchtools_slurm.html

If you use other techniques to make R available in a job script, please let me know

That said, the job submission itself actually worked! It's just that R didn't start, which means the patch works

Great news that the patch works.

Here's what I've got in my template,slurm.tmpl. I'm not sure how to squeeze this into the resources option--this is something I got help with from a sysadmin. It works great with batchtools.

## Call batchtools inside containermodule load apptainer/latestexport APPTAINER_BINDPATH="/run/munge,/var/run/munge,/etc/slurm,/var/spool/slurm/slurmd/conf-cache/slurm.conf,$APPTAINER_BINDPATH"apptainer exec /modules/admin-resources/ood-dev/unity-r_4.4.0.sif Rscript --no-restore --quiet --no-save -e 'batchtools::doJobCollection("<%= uri %>")'

I'm not sure how to squeeze this into the resources option

Unfortunately not possible today; you'd have to create your own custom template file. But, I've createdfutureverse/future.batchtools#99 to add support for this too. Stay tuned.

Okay, I'll look forward to future.batchtools in the future.

Do you have what you need from me to address the original issue in this PR?

Do you have what you need from me to address the original issue in this PR?

Yes, I'd like to have a success story over atfuture.batchtools first, ideally some mileage from other users, and have my patch "ripe" enough, before I "bug" thebatchtools maintainers here. So, I'll ping you again over atfutureverse/future.batchtools#99 for you to test. Thanks.

Deal! Thanks so much for your help with this.