Description:
wb_command
uses all available threads when OMP_NUM_THREADS
had not been set or is set to ''
, which is default in qunex
.
When running multiple qunex docker containers at the same time, this behavior makes CPU stuck.
Specifically, when running wb_command -cifti-resample
in SubcorticalProcessing.sh
, which is included in hcp_fmri_surface
pipeline, my local workstation got stuck for more than 24 hours.
This behavior can be avoided by setting explicitly export OMP_THREADS=1
or some other numbers.
However, I naively thought that either using --bash_pre
argument or --envars
to set such environment variable would work, but it did not.
Workaround Call:
By inspecting the raw source code for qunex_container, I was able to successfully set OMP_NUM_THREADS
with --dockeropt
option:
export QUNEX_CONTAINER="gitlab.qunex.yale.edu:5002/qunex/qunexcontainer:0.94.4"
qunex_container hcp_fmri_surface \
# after multiple options
--dockeropt="-v \"$(pwd)\":/data -e OMP_NUM_THREADS=1" \
--container="${QUNEX_CONTAINER}"
Feature Request:
The workaround call above works only for docker and I have no knowledge about how to deal with this for a singularity container.
Therefore, for robustness, I hope qunex
to support a separate argument for openmp thread number, like how --parelements
or --parsessions
is implemented now.
For example, --ompthreads
argument that sets OMP_NUM_THREADS
inside the qunex container would be very helpful.
Many thanks,
Minho