Open wlandau opened 3 years ago
Downgrading to future
version 1.21.0 appears to have fixed the issue on my end. So could this have to do with the recent release of version 1.22.1 on August 25? Apologies for posting the issue in the wrong place.
Thanks @wlandau - I can confirm the behavior and that downgrading to future
1.21.0 fixes this in our environment.
Hi, this actually never meant to work, because resources
is not an argument that is part of the Future API, and more specifically future()
. It was just a side effect of ...
arguments being passed down to the underlying future backend constructor (here batchtools_sge
). The reason it is not meant to work is that it breaks the core philosophy that future code should not make assumptions about what backend is being used.
You can argue that being able to specify "resources" should be part of the Future API. There is indeed a plan to work on this, cf. https://www.futureverse.org/roadmap.html. With such an API, it would make sense for a developer to specify certain "resources" that is requires in order to resolve a future.
A somewhat hacky workaround would be to do something like the following in targets;
the_plan <- plan("list")
strategy <- the_plan[[1]]
if (inherits(strategy, "batchtools_template")) {
strategy <- tweak(strategy, resources = resources)
the_plan[[1]] <- strategy
old_plan <- plan(the_plan)
on.exit(plan(old_plan), add = TRUE)
}
This also highlight my point above. Imagine there's another HPC backend that names the corresponding argument, say, needs
. Then you would have to add conditional code for that as well. More importantly, if the developer would use future(..., resources = ...)
their code would not run as expected with this new backend. So, resources
is not part of the Future API (yet).
PS. We have the related problem that batchtools don't have a strict definition of what resources
should hold. So, it is really up to the person writing the template file to define what it should contain. It could be different between different HPC templates, which would again cause the code to be hard-coded for a specific backend. The goal to add support for "resource specifications" to the Future API is to at least identify a core set of well-defined specs (and syntax for it).
Thanks for explaining, Henrik. targets
is already capable of temporary plans, and I have updated the docs to encourage that kind of usage.
From my perspective as a user, it seemed safer to supply resources to the future
instead of the plan because temporary plans seem difficult in the general case: for example, if temporarily switching to a different plan automatically shuts down the PSOCK cluster in the original plan. targets
currently relies on future::plan(.cleanup = FALSE)
, which as you explained earlier, is not really officially supported either.
But I do understand the need for a consistent interface with appropriate semantic guardrails.
Summary
When I supply a
resources
list to abatchtools
future, the resources seem to be ignored. I was alerted to this viatargets
, https://github.com/ropensci/targets/discussions/562#discussioncomment-1304379 and https://github.com/ropensci/targets/discussions/632 (cc @wresch, @sdechaumet)Reproducible example
Using an SGE cluster with this template:
R console:
When I run
debug(BatchtoolsFuture)
on this example, I see thatresources = list(slots = 2)
is not actually passed to theBatchtoolsFuture()
function.BatchtoolsFuture()
appears to receive the defaultresources = list()
.Expected behavior
An SGE job with 2 slots should be submitted.
Session information
I am using the following commits of
future
andfuture.batchtools
: