I have tried to use v1.1.1 qunex container script, but it sitll failed to process with the same error. Then, I updated my container to 1.1.1 but it showed error below:
bash: /hdd1/qunex/cimt/processing/logs/batchlogs/qunex_container_command_2025-03-27_19.12.10.278669.sh: No such file or directory
I thought it may have something wrong while updating my container. My steps to update container is:
docker pull gitlab.qunex.yale.edu:5002/qunex/qunexcontainer:1.1.1
PATH=/hdd1/qunex:${PATH}
chmod a+x /hdd1/qunex/qunex_container
To validate the container version, I printed it out:
ehui@ehuicompute:/hdd1/qunex$ export QUNEX_CONTAINER="gitlab.qunex.yale.edu:5002/qunex/qunexcontainer:1.1.1"
ehui@ehuicompute:/hdd1/qunex$ qunex_container
qunex_container is a self-standing command that can run QuNex commands
against a Singularity/Apptainer or a Docker QuNex container. To run an QuNex
command against a container the basic call is::
qunex_container <qunex command> [parameters] --container="<a path to the Singularity/Apptainer image or a Docker container name>" [additional options]
`qunex command` is any command supported by QuNex. `parameters` are any
parameters that should be passed to the qunex command. This part is the same
as running::
qunex <qunex command> [parameters]
from within a container or on a self-standing QuNex installation. For list
of commands and their parameters consult QuNex online or in-line
documentation.
Additionally qunex_container accepts the following parameters:
INPUTS
======
--container specifies either the path to the Singularity/Apptainer
container image or the full specification of the Docker
container to be used (e.g. qunex/qunex_suite:0_45_07).
--bash_pre If any additional commands have to be run in bash before the
execution of qunex_container command itself. Use a semicolon
separated list to chain multiple commands. ['']
--bash_post Used if any additional commands have to be run inside the
QuNex container before executing the desired QuNex command.
Use a semicolon separated list to chain multiple commands.
['']
--bind Used for binding external folders in order for the system in
the container to have access to relvant data. Maps to -B
parameter of Singularity/Apptainer and -v parmaeter of
Docker.
--nocleanenv By default QuNex will use the --cleanenv flag of
Singularity/Apptainer so your local environment setup will
not be propagated into the container. If you want to disable
this functionality use this flag. The flag is not set by
default.
--cuda Use in order to prepare the container for CUDA usage. This
flag is not set by default.
--cuda_path Can be used to bind a local CUDA version over the one in the
system.
--nv An old way of using using CUDA inside Singularity/Apptainer.
If provided then --nv option will be used when executing.
--script If a script is to be run against the Singularity/Apptainer
container rather than a single command, the path to the
script to be run is specified here. ['']
--containeropt A string that lists the additional options to be used when
running the container. The parameters are to be specified in
a string exactly as they would be on a command line, e.g.
to run Docker in detached mode and mount a specific folder
use::
"-d -v /host/directory:/container/directory"
--scheduler A string that specifies the details to use to submit the
container job to a scheduling system.
--console_out A string specifying where to redirect the standard output
and error when using the scheduler. See "Redirecting
output" for details!
--parjobs Specify the maximum amount of jobs that will be created
and run in parallel. By default this equals the number
of sessions your provided.
--parsessions Specify the amount of sessions that will be run in parallel
inside each created job. [1]
--parelements Specify the amount of elements that will be run in parallel
inside each session (for example BOLDs in hcp_fmri_volume).
[1]
--parinfo If this flag is set then qunex_container will not execute
the command, it will only printout the parallelism
information, e.g. how many jobs will be spawned, how many
sessions will be run in parallel, etc.
RESULTS
=======
`qunex_container` will compile a temporary file with the relevant commands to
submit to the container. The file will be created in the users home folder
and will be deleted as the last action completed by the container. In case
of a Docker container, to give access to the compiled script, the user's
home folder will be mounted as `/root` in the container, which is the home
folder within the container.
If a script parameter is specified, in case of a Singularity/Apptainer
container, the script will be executed using the `bash <script>` command.
In case of a Docker container, the content of the script will be appended
to the temporary script generated by the `qunex_container`. Do note that in
the case of the Singularity/Apptainer container the script can reference
paths on the host computer, whereas in the case of the Docker container,
the script has to reference the paths and mounts as they are visible within
the Docker container.
Scheduling jobs
---------------
Container commands can be submitted to a scheduling system by specifying
the `--scheduler` parameter with a settings string. The settings string
should be a comma separated list of parameters. The first parameter has to
be the scheduler name (PBS, SLURM or GridEngine), the rest of the parameters
are key-value pairs that are to be passed as settings to the scheduler.
Example settings strings::
"SLURM,jobname=hcp_freesurfer,time=03-24:00:00,cpus-per-task=2,mem-per-cpu=2500,partition=week"
Scheduling multiple jobs in parallel
------------------------------------
If the parameters provided include --parjobs, --parsessions, --scheduler
and --sessions or --batchfile, then qunex_container will spread the execution
of the command by scheduling multiple jobs to run on separate nodes. Specifically,
if --parjobs is not provided then QuNex will schedule a job for each of the
sessions. If --parjobs is provided then QuNex will schedule at most the
requested amount of jobs, inside each job QuNex will run at most
--parsessions in parallel. E.g. if 10 sessions are specified, parjobs
is set to 3 and parsessions is set to 4, QuNex will schedule 3 jobs. The first
job will run 4 sessions in parallel and the other 2 jobs will run 3 sessions
in parallel.
Redirecting output
------------------
By default, QuNex will try to put scheduler logs into the
<study>/processing/logs/batchlogs folder. If not possible QuNex will put them
in your home folder. You can also put them in a custom location by specifying
the `console_out` parameter. The parameter supports three different directives
provided by "<key>:<value>" pairs in a pipe separated string:
stdout
specifies a path to a log file that should store standard output of the
submitted job
stderr
specified a path to a log file that should store error output of the
submitted job
both
specifies a path to a log file that should store joint standard and
error outputs of the submitted job
Examples:
- "stdout:processing.log"
- "stdout:processing.output.log|stderr:processing.error.log"
- "both:processing.log"
Do not specify error and standard outputs both using --console_out parameter
and scheduler specific options within settings string. It is best to provide
full absolute paths to the desired log.
EXAMPLE USE
===========
::
qunex_container hcp_freesurfer \
--sessionsfolder=/data/study/sessions \
--batchfile=/data/study/processing/batch.txt \
--parsessions=4 \
--container=/apptainer/qunex_suite-0_38_10.sif \
--scheduler="SLURM,time=2-00:00:00,cpus-per-task=2,mem-per-cpu=15000,partition=week"
I still can’t run my code in the new container, what is the reason for this?
Best
Acacius
.