并行作业的 Orca 和 OpenMPI 问题
Problems with Orca and OpenMPI for parallel jobs
大家好：
我最近开始使用 ORCA 软件进行一些量子计算，但在我大学的集群中进行并行计算时遇到了很多问题。
为了安装 Orca，我使用了静态版本：
orca_4_2_1_linux_x86-64_openmpi314.tar.xz。
在集群的共享方向 (/data/shared/opt/ORCA/)。
并放入我的 ~/.bash_profile:
export PATH="/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314:$PATH"
export LD_LIBRARY_PATH="/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314:$LD_LIBRARY_PATH"
用于安装对应的OpenMPI版本(3.1.4)
tar -xvf openmpi-3.1.4.tar.gz
cd openmpi-3.1.4
./configure --prefix="/data/shared/opt/ORCA/openmpi314/"
make -j 10
make install
当我使用前端服务器时一切都很好：
使用这样的 .sh：
#! /bin/bash
export PATH="/data/shared/opt/ORCA/openmpi314/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/data/shared/opt/ORCA/openmpi314/lib"
$(which orca) test.inp > test.out
和这样的输入：
# Computation of myjob at b3lyp/6-31+G(d,p)
%pal nprocs 10 end
%maxcore 8192
! RKS B3LYP 6-31+G(d,p)
! TightSCF Grid5 NoFinalGrid
! Opt
! Freq
%cpcm
smd true
SMDsolvent "water"
end
* xyz 0 1
C 0 0 0
O 0 0 1.5
*
使用节点时出现的问题：
.inp 文件:
#! Computation at RKS B3LYP/6-31+G(d,p) for cis1_bh267_m_Cell_152
%pal nprocs 12 end
%maxcore 8192
! RKS B3LYP 6-31+G(d,p)
! TightSCF Grid5 NoFinalGrid
! Opt
! Freq
%cpcm
smd true
SMDsolvent "water"
end
* xyz 0 1
C -4.38728130 0.21799058 0.17853303
C -3.02072869 0.82609890 -0.29733316
F -2.96869122 2.10937041 0.07179384
F -3.01136328 0.87651596 -1.63230798
C -1.82118365 0.05327804 0.23420220
O -2.26240947 -0.92805650 1.01540713
C -0.53557484 0.33394113 -0.05236121
C 0.54692198 -0.46942807 0.50027196
O 0.31128292 -1.43114232 1.22440290
C 1.93990391 -0.12927675 0.16510948
C 2.87355011 -1.15536140 -0.00858832
C 4.18738231 -0.82592189 -0.32880964
C 4.53045856 0.52514329 -0.45102225
N 3.63662927 1.52101319 -0.26705841
C 2.36381718 1.20228695 0.03146190
F -4.51788749 0.24084604 1.49796862
F -4.53935644 -1.04617745 -0.19111502
F -5.43718443 0.87033190 -0.30564680
H -1.46980819 -1.48461498 1.39034280
H -0.26291843 1.15748249 -0.71875720
H 2.57132559 -2.20300864 0.10283592
H 4.93858460 -1.60267627 -0.48060140
H 5.55483009 0.83859415 -0.70271364
H 1.67507560 2.05019549 0.17738396
*
.sh 文件（Slurm 作业）：
#!/bin/bash
#SBATCH -p deflt #which partition I want
#SBATCH -o cis1_bh267_m_Cell_152_myjob.out #path for the slurm output
#SBATCH -e cis1_bh267_m_Cell_152_myjob.err #path for the slurm error output
#SBATCH -c 12 #number of cpu(logical cores)/task (task is normally an MPI process, default is one and the option to change it is -n)
#SBATCH -t 2-00:00 #how many time I want the resources (this impacts the job priority as well)
#SBATCH --job-name=cis1_bh267_m_Cell_152 #(to recognize your jobs when checking them with "squeue -u USERID")
#SBATCH -N 1 #number of node, usually 1 when no parallelization over nodes
#SBATCH --nice=0 #lowering your priority if >0
#SBATCH --gpus=0 #number of gpu you want
# This block is echoing some SLURM variables
echo "Jobid = $SLURM_JOBID"
echo "Host = $SLURM_JOB_NODELIST"
echo "Jobname = $SLURM_JOB_NAME"
echo "Subcwd = $SLURM_SUBMIT_DIR"
echo "SLURM_CPUS_PER_TASK = $SLURM_CPUS_PER_TASK"
# This block is for the execution of the program
export PATH="/data/shared/opt/ORCA/openmpi314/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/data/shared/opt/ORCA/openmpi314/lib"
$(which orca) ${SLURM_JOB_NAME}.inp > ${SLURM_JOB_NAME}.log --use-hwthread-cpus
我使用了 --use-hwthread-cpus 标志作为推荐，但是使用和不使用这个标志都会出现同样的问题。
全部错误为：
系统中没有足够的可用插槽来满足应用程序请求的 12 个插槽：/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314/orca_gtoint_mpi
要么为您的应用程序请求更少的插槽，要么提供更多的插槽可供使用。 “槽”是 Open MPI 术语，指的是我们可以在其中启动进程的可分配单元。可用插槽数由 Open MPI 进程所在的环境定义 运行:
1.主机文件，通过“slots=N”子句（如果未提供，N 默认为处理器核心数）
2。 --host 命令行参数，通过主机名上的“:N”后缀（如果未提供，N 默认为 1）
3。资源管理器（例如，SLURM、PBS/Torque、LSF 等）
4.如果主机文件的 none、--host 命令行参数或 RM 存在，则 Open MPI 默认为处理器内核数 在上述所有情况下，如果您希望 Open MPI 默认为处理器内核数
硬件线程数而不是处理器内核数，使用 --use-hwthread-cpus 选项。
或者，您可以使用 --oversubscribe 选项在决定要启动的进程数时忽略可用插槽数。
*[文件 orca_tools/qcmsg.cpp，第 458 行]：
.. 中止 运行*
当我转到计算的 输出 时，它看起来像开始 运行 但是当启动并行作业失败并给出：
ORCA 因 GTOInt 中的错误终止而完成
调用命令：mpi运行 -np 12 --use-hwthread-cpus /data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314/orca_gtoint_mpi cis1_bh267_m_Cell_448.int.tmp cis1_bh267_m_Cell_448
[文件 orca_tools/qcmsg.cpp，第 458 行]：
.... 中止 运行
我们在集群上有两种节点：
其中一拳是：
Xeon 6 核 E-2136 @ 3.30GHz（12 个逻辑内核）和 Nvidia GTX 1070Ti
还有其他的：
AMD Epyc 24 核（24 个逻辑核心）和 4x Nvidia RTX 2080Ti
使用命令scontrol show node每组一个节点的详细信息为：
第一组：
NodeName=fang1 Arch=x86_64 CoresPerSocket=6
CPUAlloc=12 CPUTot=12 CPULoad=12.00
AvailableFeatures=(null)
ActiveFeatures=(null)
Gres=gpu:gtx1070ti:1
NodeAddr=fang1 NodeHostName=fang1 Version=19.05.5
OS=Linux 5.7.12-arch1-1 #1 SMP PREEMPT Fri, 31 Jul 2020 17:38:22 +0000
RealMemory=15923 AllocMem=0 FreeMem=171 Sockets=1 Boards=1
State=ALLOCATED ThreadsPerCore=2 TmpDisk=7961 Weight=1 Owner=N/A MCS_label=N/A
Partitions=deflt,debug,long
BootTime=2020-10-27T09:56:18 SlurmdStartTime=2020-10-27T15:33:51
CfgTRES=cpu=12,mem=15923M,billing=12,gres/gpu=1,gres/gpu:gtx1070ti=1
AllocTRES=cpu=12,gres/gpu=1,gres/gpu:gtx1070ti=1
CapWatts=n/a
CurrentWatts=0 AveWatts=0
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
第二组
NodeName=fang50 Arch=x86_64 CoresPerSocket=24
CPUAlloc=48 CPUTot=48 CPULoad=48.00
AvailableFeatures=(null)
ActiveFeatures=(null)
Gres=gpu:rtx2080ti:4
NodeAddr=fang50 NodeHostName=fang50 Version=19.05.5
OS=Linux 5.7.12-arch1-1 #1 SMP PREEMPT Fri, 31 Jul 2020 17:38:22 +0000
RealMemory=64245 AllocMem=0 FreeMem=807 Sockets=1 Boards=1
State=ALLOCATED ThreadsPerCore=2 TmpDisk=32122 Weight=1 Owner=N/A MCS_label=N/A
Partitions=deflt,long
BootTime=2020-12-15T10:09:43 SlurmdStartTime=2020-12-15T10:14:17
CfgTRES=cpu=48,mem=64245M,billing=48,gres/gpu=4,gres/gpu:rtx2080ti=4
AllocTRES=cpu=48,gres/gpu=4,gres/gpu:rtx2080ti=4
CapWatts=n/a
CurrentWatts=0 AveWatts=0
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
我在 Slurm 的脚本中使用了标志 -c, --cpus-per-task = integer；在 Orca 的输入中，命令 %pal nprocs integer end。我测试了这两个参数的不同组合，以查看我使用的 CPU 是否多于可用的：
-c, --cpus-per-task = integer
%pal nprocs integer end
None
6
None
3
None
2
1
2
1
12
2
6
3
4
12
12
内存量不同：8000 MBi 和 2000 MBi（我的总内存大约是 15 GBi）。在所有情况下 都会出现相同的错误 。我不是 ORCA 的专家用户，也不是信息学的专家用户（但也许你猜这个是为了扩展问题），所以也许解决方案很简单，但我真的没有，我不知道发生了什么！
非常感谢，
亚历杭德罗。
遇到了同样的问题。
显式声明 --前缀 ${OMPI_HOME} 直接作为 ORCA 参数并使用静态链接的 ORCA 版本帮助我：
export RSH_COMMAND="/usr/bin/ssh"
export PARAMS="--mca routed direct --oversubscribe -machinefile ${HOSTS_FILE} --prefix ${OMPI_HOME}"
$ORCA_DIR/orca $WORKDIR/$JOBFILE.inp "$PARAMS" > $WORKDIR/$JOBFILE.out
此外，最好使用 --disable-builtin-atomics 标志构建 OpenMPI 3.1.x。
谢谢@Alexey 的回答。很抱歉打错了标签，就像我说的，我在这方面还很菜鸟。
问题不在 Orca 或 OpenMPI 配置中，而是在用于计划 Slurm 作业的 bash 脚本中。
我认为整个 Orca 作业本身就是 Slurm 所说的“任务”。出于这个原因，我声明标志 --cpus-per-task 等于我想用 Orca 做的并行作业的数量。但问题是每个并行的 Orca 作业（使用 OpenMPI 启动）都是 Slurm 的任务。因此，在我的 Slurm 脚本中，我保留了一个至少有 12 CPU 的节点，但是当 Orca 启动它们的并行作业时，每个节点都要求 12 CPU，所以：“没有足够的插槽可用.. ." 因为我需要 144 CPU.
我的问题 table 中的其余案例因其他原因而失败。我同时启动了 5 种不同的 Orca 计算。现在，因为 --cpus-per-task 可能是 None、1、2 或 3；这五个计算可能会进入同一个节点或另一个具有此空闲 CPU 数量的节点，但是当 Orca 请求并行作业时，再次失败，因为该节点上没有此数量的 CPU .
我找到的解决方案非常简单。在 Slurm 的 .sh 脚本中，我输入了这个：
#SBATCH --mincpus=n*m
#SBATCH --ntasks=n
#SBATCH --cpus-per-task m
而不只是：
#SBATCH --cpus-per-task m
其中 n 将等于 Orca 输入 (%pal nprocs n end) 和 m 上指定的并行作业数您希望用于每个并行 Orca 作业的 CPU 数量。
在我的例子中，我使用了 n = 12，m = 1。使用标志 --mincpus 我确保使用至少 12 CPU 的节点并分配它们。使用 --cpus-per-task 非常明显这个标志的作用（即使对我来说 :-) ），顺便说一下，它的默认值为 1 我不知道是否超过 1 CPU对于每个 OpenMPI Orca 作业，提高计算速度。 --ntasks 向 Slurm 提供有关您将执行多少任务的信息。
当然，如果你知道任务的数量和每个任务的 CPU 就很容易知道你需要保留多少 CPU，但我不知道这是否也很容易 Slurm :-) .所以，为了确保我分配了正确数量的 CPU 我使用了 --mincpus 标志，但也许不需要。问题是它现在可以工作了^_^。
同样重要的是要考虑您在 Orca 的输入中声明的内存量，以免超过可用内存。例如，如果您有 12 个任务和 15000 MBi 的 RAM，则要声明的正确内存量不应超过 15000/12 = 1250 MBi
我之前遇到过并行作业的类似问题。 slurm 也输出 not enough slots 错误。
我的解决办法是把并行线程改成并行进程。对于我的系统是改变
#SBATCH -c 24
进入
#SBATCH -n 24
一切正常。
大家好：
我最近开始使用 ORCA 软件进行一些量子计算，但在我大学的集群中进行并行计算时遇到了很多问题。
为了安装 Orca，我使用了静态版本： orca_4_2_1_linux_x86-64_openmpi314.tar.xz。 在集群的共享方向 (/data/shared/opt/ORCA/)。 并放入我的 ~/.bash_profile:
export PATH="/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314:$PATH"
export LD_LIBRARY_PATH="/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314:$LD_LIBRARY_PATH"
用于安装对应的OpenMPI版本(3.1.4)
tar -xvf openmpi-3.1.4.tar.gz
cd openmpi-3.1.4
./configure --prefix="/data/shared/opt/ORCA/openmpi314/"
make -j 10
make install
当我使用前端服务器时一切都很好： 使用这样的 .sh：
#! /bin/bash
export PATH="/data/shared/opt/ORCA/openmpi314/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/data/shared/opt/ORCA/openmpi314/lib"
$(which orca) test.inp > test.out
和这样的输入：
# Computation of myjob at b3lyp/6-31+G(d,p)
%pal nprocs 10 end
%maxcore 8192
! RKS B3LYP 6-31+G(d,p)
! TightSCF Grid5 NoFinalGrid
! Opt
! Freq
%cpcm
smd true
SMDsolvent "water"
end
* xyz 0 1
C 0 0 0
O 0 0 1.5
*
使用节点时出现的问题：
.inp 文件:
#! Computation at RKS B3LYP/6-31+G(d,p) for cis1_bh267_m_Cell_152
%pal nprocs 12 end
%maxcore 8192
! RKS B3LYP 6-31+G(d,p)
! TightSCF Grid5 NoFinalGrid
! Opt
! Freq
%cpcm
smd true
SMDsolvent "water"
end
* xyz 0 1
C -4.38728130 0.21799058 0.17853303
C -3.02072869 0.82609890 -0.29733316
F -2.96869122 2.10937041 0.07179384
F -3.01136328 0.87651596 -1.63230798
C -1.82118365 0.05327804 0.23420220
O -2.26240947 -0.92805650 1.01540713
C -0.53557484 0.33394113 -0.05236121
C 0.54692198 -0.46942807 0.50027196
O 0.31128292 -1.43114232 1.22440290
C 1.93990391 -0.12927675 0.16510948
C 2.87355011 -1.15536140 -0.00858832
C 4.18738231 -0.82592189 -0.32880964
C 4.53045856 0.52514329 -0.45102225
N 3.63662927 1.52101319 -0.26705841
C 2.36381718 1.20228695 0.03146190
F -4.51788749 0.24084604 1.49796862
F -4.53935644 -1.04617745 -0.19111502
F -5.43718443 0.87033190 -0.30564680
H -1.46980819 -1.48461498 1.39034280
H -0.26291843 1.15748249 -0.71875720
H 2.57132559 -2.20300864 0.10283592
H 4.93858460 -1.60267627 -0.48060140
H 5.55483009 0.83859415 -0.70271364
H 1.67507560 2.05019549 0.17738396
*
.sh 文件（Slurm 作业）：
#!/bin/bash
#SBATCH -p deflt #which partition I want
#SBATCH -o cis1_bh267_m_Cell_152_myjob.out #path for the slurm output
#SBATCH -e cis1_bh267_m_Cell_152_myjob.err #path for the slurm error output
#SBATCH -c 12 #number of cpu(logical cores)/task (task is normally an MPI process, default is one and the option to change it is -n)
#SBATCH -t 2-00:00 #how many time I want the resources (this impacts the job priority as well)
#SBATCH --job-name=cis1_bh267_m_Cell_152 #(to recognize your jobs when checking them with "squeue -u USERID")
#SBATCH -N 1 #number of node, usually 1 when no parallelization over nodes
#SBATCH --nice=0 #lowering your priority if >0
#SBATCH --gpus=0 #number of gpu you want
# This block is echoing some SLURM variables
echo "Jobid = $SLURM_JOBID"
echo "Host = $SLURM_JOB_NODELIST"
echo "Jobname = $SLURM_JOB_NAME"
echo "Subcwd = $SLURM_SUBMIT_DIR"
echo "SLURM_CPUS_PER_TASK = $SLURM_CPUS_PER_TASK"
# This block is for the execution of the program
export PATH="/data/shared/opt/ORCA/openmpi314/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/data/shared/opt/ORCA/openmpi314/lib"
$(which orca) ${SLURM_JOB_NAME}.inp > ${SLURM_JOB_NAME}.log --use-hwthread-cpus
我使用了 --use-hwthread-cpus 标志作为推荐，但是使用和不使用这个标志都会出现同样的问题。
全部错误为：
系统中没有足够的可用插槽来满足应用程序请求的 12 个插槽：/data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314/orca_gtoint_mpi
要么为您的应用程序请求更少的插槽，要么提供更多的插槽可供使用。 “槽”是 Open MPI 术语，指的是我们可以在其中启动进程的可分配单元。可用插槽数由 Open MPI 进程所在的环境定义 运行:
1.主机文件，通过“slots=N”子句（如果未提供，N 默认为处理器核心数）
2。 --host 命令行参数，通过主机名上的“:N”后缀（如果未提供，N 默认为 1）
3。资源管理器（例如，SLURM、PBS/Torque、LSF 等）
4.如果主机文件的 none、--host 命令行参数或 RM 存在，则 Open MPI 默认为处理器内核数 在上述所有情况下，如果您希望 Open MPI 默认为处理器内核数 硬件线程数而不是处理器内核数，使用 --use-hwthread-cpus 选项。
或者，您可以使用 --oversubscribe 选项在决定要启动的进程数时忽略可用插槽数。
*[文件 orca_tools/qcmsg.cpp，第 458 行]：
.. 中止 运行*
当我转到计算的 输出 时，它看起来像开始 运行 但是当启动并行作业失败并给出：
ORCA 因 GTOInt 中的错误终止而完成 调用命令：mpi运行 -np 12 --use-hwthread-cpus /data/shared/opt/ORCA/orca_4_2_1_linux_x86-64_openmpi314/orca_gtoint_mpi cis1_bh267_m_Cell_448.int.tmp cis1_bh267_m_Cell_448 [文件 orca_tools/qcmsg.cpp，第 458 行]： .... 中止 运行
我们在集群上有两种节点： 其中一拳是：
Xeon 6 核 E-2136 @ 3.30GHz（12 个逻辑内核）和 Nvidia GTX 1070Ti
还有其他的：
AMD Epyc 24 核（24 个逻辑核心）和 4x Nvidia RTX 2080Ti
使用命令scontrol show node每组一个节点的详细信息为：
第一组：
NodeName=fang1 Arch=x86_64 CoresPerSocket=6
CPUAlloc=12 CPUTot=12 CPULoad=12.00
AvailableFeatures=(null)
ActiveFeatures=(null)
Gres=gpu:gtx1070ti:1
NodeAddr=fang1 NodeHostName=fang1 Version=19.05.5
OS=Linux 5.7.12-arch1-1 #1 SMP PREEMPT Fri, 31 Jul 2020 17:38:22 +0000
RealMemory=15923 AllocMem=0 FreeMem=171 Sockets=1 Boards=1
State=ALLOCATED ThreadsPerCore=2 TmpDisk=7961 Weight=1 Owner=N/A MCS_label=N/A
Partitions=deflt,debug,long
BootTime=2020-10-27T09:56:18 SlurmdStartTime=2020-10-27T15:33:51
CfgTRES=cpu=12,mem=15923M,billing=12,gres/gpu=1,gres/gpu:gtx1070ti=1
AllocTRES=cpu=12,gres/gpu=1,gres/gpu:gtx1070ti=1
CapWatts=n/a
CurrentWatts=0 AveWatts=0
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
第二组
NodeName=fang50 Arch=x86_64 CoresPerSocket=24
CPUAlloc=48 CPUTot=48 CPULoad=48.00
AvailableFeatures=(null)
ActiveFeatures=(null)
Gres=gpu:rtx2080ti:4
NodeAddr=fang50 NodeHostName=fang50 Version=19.05.5
OS=Linux 5.7.12-arch1-1 #1 SMP PREEMPT Fri, 31 Jul 2020 17:38:22 +0000
RealMemory=64245 AllocMem=0 FreeMem=807 Sockets=1 Boards=1
State=ALLOCATED ThreadsPerCore=2 TmpDisk=32122 Weight=1 Owner=N/A MCS_label=N/A
Partitions=deflt,long
BootTime=2020-12-15T10:09:43 SlurmdStartTime=2020-12-15T10:14:17
CfgTRES=cpu=48,mem=64245M,billing=48,gres/gpu=4,gres/gpu:rtx2080ti=4
AllocTRES=cpu=48,gres/gpu=4,gres/gpu:rtx2080ti=4
CapWatts=n/a
CurrentWatts=0 AveWatts=0
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
我在 Slurm 的脚本中使用了标志 -c, --cpus-per-task = integer；在 Orca 的输入中，命令 %pal nprocs integer end。我测试了这两个参数的不同组合，以查看我使用的 CPU 是否多于可用的：
| -c, --cpus-per-task = integer | %pal nprocs integer end |
|---|---|
| None | 6 |
| None | 3 |
| None | 2 |
| 1 | 2 |
| 1 | 12 |
| 2 | 6 |
| 3 | 4 |
| 12 | 12 |
内存量不同：8000 MBi 和 2000 MBi（我的总内存大约是 15 GBi）。在所有情况下 都会出现相同的错误 。我不是 ORCA 的专家用户，也不是信息学的专家用户（但也许你猜这个是为了扩展问题），所以也许解决方案很简单，但我真的没有，我不知道发生了什么！
非常感谢，
亚历杭德罗。
遇到了同样的问题。 显式声明 --前缀 ${OMPI_HOME} 直接作为 ORCA 参数并使用静态链接的 ORCA 版本帮助我：
export RSH_COMMAND="/usr/bin/ssh"
export PARAMS="--mca routed direct --oversubscribe -machinefile ${HOSTS_FILE} --prefix ${OMPI_HOME}"
$ORCA_DIR/orca $WORKDIR/$JOBFILE.inp "$PARAMS" > $WORKDIR/$JOBFILE.out
此外，最好使用 --disable-builtin-atomics 标志构建 OpenMPI 3.1.x。
谢谢@Alexey 的回答。很抱歉打错了标签，就像我说的，我在这方面还很菜鸟。
问题不在 Orca 或 OpenMPI 配置中，而是在用于计划 Slurm 作业的 bash 脚本中。
我认为整个 Orca 作业本身就是 Slurm 所说的“任务”。出于这个原因，我声明标志 --cpus-per-task 等于我想用 Orca 做的并行作业的数量。但问题是每个并行的 Orca 作业（使用 OpenMPI 启动）都是 Slurm 的任务。因此，在我的 Slurm 脚本中，我保留了一个至少有 12 CPU 的节点，但是当 Orca 启动它们的并行作业时，每个节点都要求 12 CPU，所以：“没有足够的插槽可用.. ." 因为我需要 144 CPU.
我的问题 table 中的其余案例因其他原因而失败。我同时启动了 5 种不同的 Orca 计算。现在，因为 --cpus-per-task 可能是 None、1、2 或 3；这五个计算可能会进入同一个节点或另一个具有此空闲 CPU 数量的节点，但是当 Orca 请求并行作业时，再次失败，因为该节点上没有此数量的 CPU .
我找到的解决方案非常简单。在 Slurm 的 .sh 脚本中，我输入了这个：
#SBATCH --mincpus=n*m
#SBATCH --ntasks=n
#SBATCH --cpus-per-task m
而不只是：
#SBATCH --cpus-per-task m
其中 n 将等于 Orca 输入 (%pal nprocs n end) 和 m 上指定的并行作业数您希望用于每个并行 Orca 作业的 CPU 数量。
在我的例子中，我使用了 n = 12，m = 1。使用标志 --mincpus 我确保使用至少 12 CPU 的节点并分配它们。使用 --cpus-per-task 非常明显这个标志的作用（即使对我来说 :-) ），顺便说一下，它的默认值为 1 我不知道是否超过 1 CPU对于每个 OpenMPI Orca 作业，提高计算速度。 --ntasks 向 Slurm 提供有关您将执行多少任务的信息。
当然，如果你知道任务的数量和每个任务的 CPU 就很容易知道你需要保留多少 CPU，但我不知道这是否也很容易 Slurm :-) .所以，为了确保我分配了正确数量的 CPU 我使用了 --mincpus 标志，但也许不需要。问题是它现在可以工作了^_^。
同样重要的是要考虑您在 Orca 的输入中声明的内存量，以免超过可用内存。例如，如果您有 12 个任务和 15000 MBi 的 RAM，则要声明的正确内存量不应超过 15000/12 = 1250 MBi
我之前遇到过并行作业的类似问题。 slurm 也输出 not enough slots 错误。
我的解决办法是把并行线程改成并行进程。对于我的系统是改变
#SBATCH -c 24
进入
#SBATCH -n 24
一切正常。