我最近查看了product.manufacturer.active if manufactuer与mpirun的{{3}}和mpiexec与srun的{{3}}，但是我想知道{ {1}}与口语和sbatch有关。
通常在示例中，发送到mpirun的文件中都包含srun来执行MPI程序，但是有时我看到使用sbatch或{{1}的文件}。但是，我不明白为什么要这么做。如this post所示，似乎使用srun <program>或mpirun可能会产生各种（与实现有关的错误）错误，并且没有理由不使用mpiexec。 / p>
这是准确的吗？还是有充分的理由为什么您要在Slurm管理的集群上执行程序时使用mpirun或mpiexec而不是srun？
答案 0 :(得分：2)
这个问题在很大程度上取决于您使用的MPI的风格以及它与SLURM的集成。
对于我自己，我完全赞赏这是个人喜好问题，我想说，由于不得不面对众多不同的集群和环境，我试图尽可能减少可变性的范围。因此，如果我运行的群集上有SLURM，我将尝试通过SLURM和sbatch对我的代码进行所有运行时调整，然后让MPI继承它们。
为此，我将定义我想要的以及我希望如何从#SBATCH提交参数提交MPI代码：节点数，每个进程的核心数，每个节点的进程数等。然后，希望通过MPI库提供的mpirun，mpiexec或类似命令使MPI启动尽可能简单。例如，大多数（如果不是全部）最近的MPI库可以直接检测到作业已在SLURM中提交，并继承了SLURM的流程位置，而无需付出任何额外的努力。通常，例如对于Intel MPI，我确实使用mpirun -bootstrap slurm <mycode>并且所有进程都按预期放置。确实，这个-bootstrap slurm选项甚至可能不是必需的，但我还是以防万一。
相反，如果在库的srun或mpirun上使用mpiexec，则要求MPI代码已与SLURM的过程管理库链接。可能会或可能不会，因此可能会或可能不会执行您想要的操作。但是更重要的是，即使它确实起作用，与仅使用MPI默认启动器相比，它也不会给您带来任何额外的优势，因为SLURM已经在通过sbatch提交作业时完成了流程管理。
因此，对我而言，除了极少数情况下进行快速而肮脏的测试外，无论何时将SLURM用于批处理调度，都不会使用srun，而是使用MPI的mpirun或mpiexec命令。