You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using ssGSEA2 on a larger data set and therefore I am running it on a HPC-cluster with job scheduler (Slurm).
Issue
ssGSEA2 will crash with Error in socketAccept(socket = socket, blocking = TRUE, open = "a+b", : all connections are in use when the allocated number of cores with Slurm is smaller than the total available cores of the hardware.
This is because parallel::detectCores() does not respect the allocation of Slurm and returns the total number of cores available on the CPU.
In my opinion the expected functionality of using par=TRUE in ssGSEA2 would imply detecting the available number cores, as is the behavior of parallelly::availableCores()as opposed to parallel::detectCores().
Workaround
set spares to:
n_cores = 64 # number of cores, same as in --cpus-per-task
spares = 2 # number of spares
spares = (parallel::detectCores()-n_cores)+spares
The text was updated successfully, but these errors were encountered:
Hi,
I am using ssGSEA2 on a larger data set and therefore I am running it on a HPC-cluster with job scheduler (Slurm).
Issue
ssGSEA2 will crash with
Error in socketAccept(socket = socket, blocking = TRUE, open = "a+b", : all connections are in use
when the allocated number of cores with Slurm is smaller than the total available cores of the hardware.This is because
parallel::detectCores()
does not respect the allocation of Slurm and returns the total number of cores available on the CPU.In my opinion the expected functionality of using
par=TRUE
in ssGSEA2 would imply detecting the available number cores, as is the behavior ofparallelly::availableCores()
as opposed toparallel::detectCores()
.Workaround
set spares to:
The text was updated successfully, but these errors were encountered: