Heterogeneous Job Support

• Overview
• Submitting Jobs
• Burst Buffers
• Managing Jobs
• Launching Applications (Job Steps)
• Environment Variables
• Examples
• Limitations
• System Administrator Information

Overview

Slurm version 17.11 and later supports the ability to submit and manage heterogeneous jobs, in which each component has virtually all job options available including partition, account and QOS (Quality Of Service).
Slurmバージョン17.11以降は、異種ジョブを送信および管理する機能をサポートしています。各コンポーネントには、パーティション、アカウント、QOS（Quality Of Service）など、実質的にすべてのジョブオプションがあります。
For example, part of a job might require four cores and 4 GB for each of 128 tasks while another part of the job would require 16 GB of memory and one CPU.
たとえば、ジョブの一部では128個のタスクごとに4つのコアと4 GBが必要であり、ジョブの別の部分では16GBのメモリと1つのCPUが必要です。

Submitting Jobs

The salloc, sbatch and srun commands can all be used to submit heterogeneous jobs.
salloc、sbatch、およびsrunコマンドはすべて、異種ジョブを送信するために使用できます。
Resource specifications for each component of the heterogeneous job should be separated with ":" character.
異種ジョブの各コンポーネントのリソース仕様は、「：」文字で区切る必要があります。
For example:
例えば：

$ sbatch --cpus-per-task=4 --mem-per-cpu=1  --ntasks=128 : \
         --cpus-per-task=1 --mem-per-cpu=16 --ntasks=1 my.bash

Options specified for one component of a heterogeneous job (or job step) will be used for subsequent components to the extent which is expected to be helpful.
異種ジョブ（またはジョブステップ）の1つのコンポーネントに指定されたオプションは、役立つと予想される範囲で、後続のコンポーネントに使用されます。
Propagated options can be reset as desired for each component (e.g. a different account name could be specified for each hetjob component.
伝播されたオプションは、コンポーネントごとに必要に応じてリセットできます（たとえば、hetjobコンポーネントごとに異なるアカウント名を指定できます。
For example, --immediate and --job-name are propagated, while --ntasks and --mem-per-cpu are reset to default values for each component.
たとえば、-immediateと--job-nameは伝播されますが、-ntasksと--mem-per-cpuは各コンポーネントのデフォルト値にリセットされます。
A list of propagated options follows.
伝播されたオプションのリストは次のとおりです。

• --account
• --acctg-freq
• --begin
• --cluster-constraint
• --clusters
• --comment
• --deadline
• --delay-boot
• --dependency
• --distribution
• --epilog (option available only in srun)
• --error
• --export
• --export-file
• --exclude
• --get-user-env
• --gid
• --hold
• --ignore-pbs
• --immediate
• --input
• --job-name
• --kill-on-bad-exit (option available only in srun)
• --label (option available only in srun)
• --mcs-label
• --msg-timeout (option available only in srun)
• --no-allocate (option available only in srun)
• --no-requeue
• --nice
• --no-kill
• --open-mode (option available only in srun)
• --output
• --parsable
• --priority
• --profile
• --propagate
• --prolog (option available only in srun)
• --pty (option available only in srun)
• --qos
• --quiet
• --quit-on-interrupt (option available only in srun)
• --reboot
• --reservation
• --requeue
• --signal
• --slurmd-debug (option available only in srun)
• --task-epilog (option available only in srun)
• --task-prolog (option available only in srun)
• --time
• --test-only
• --time-min
• --uid
• --unbuffered (option available only in srun)
• --verbose
• --wait
• --wait-all-nodes
• --wckey
• --workdir

The task distribution specification applies separately within each job component.
タスク分散仕様は、各ジョブコンポーネント内で個別に適用されます。
Consider for example a heterogeneous job with each component being allocated 4 CPUs on 2 nodes.
たとえば、各コンポーネントに2つのノードで4つのCPUが割り当てられている異種ジョブについて考えてみます。
In our example, job component zero is allocated 2 CPUs on node "nid00001" and 2 CPUs on node "nid00002".
この例では、ジョブコンポーネント0には、ノード「nid00001」に2つのCPUが割り当てられ、ノード「nid00002」に2つのCPUが割り当てられています。
Job component one is allocated 2 CPUs on node "nid00003" and 2 CPUs on node "nid00004".
ジョブコンポーネント1には、ノード「nid00003」に2つのCPUが割り当てられ、ノード「nid00004」に2つのCPUが割り当てられます。
A task distribution of "cyclic" will distribute the first 4 tasks in a cyclic fashion on nodes "nid00001" and "nid00002", then distribute the next 4 tasks in a cyclic fashion on nodes "nid00003" and "nid00004" as shown below.
「循環」のタスク分散は、最初の4つのタスクをノード「nid00001」と「nid00002」に循環的に分散し、次の4つのタスクをノード「nid00003」と「nid00004」に循環的に分散します。

Node nid00001	Node nid00002	Node nid00003	Node nid00004
Rank 0	Rank 1	Rank 4	Rank 5
Rank 2	Rank 3	Rank 6	Rank 7

Some options should be specified only in the first hetjob component.
一部のオプションは、最初のhetjobコンポーネントでのみ指定する必要があります。
For example, specifying a batch job output file in the second hetjob component's options will result in the first hetjob component (where the batch script executes) using the default output file name.
たとえば、2番目のhetjobコンポーネントのオプションでバッチジョブ出力ファイルを指定すると、デフォルトの出力ファイル名を使用する最初のhetjobコンポーネント（バッチスクリプトが実行される場所）になります。

Environment variables used to specify default options for the job submit command will be applied to every component of the heterogeneous job (e.g. SBATCH_ACCOUNT).
ジョブ送信コマンドのデフォルトオプションを指定するために使用される環境変数は、異種ジョブのすべてのコンポーネント（SBATCH_ACCOUNTなど）に適用されます。

Batch job options can be included in the submitted script for multiple heterogeneous job components.
バッチジョブオプションは、複数の異種ジョブコンポーネントの送信されたスクリプトに含めることができます。
Each component should be separated by a line containing the line "#SBATCH hetjob" as shown below.
各コンポーネントは、以下に示すように、「＃SBATCHhetjob」という行を含む行で区切る必要があります。

$ cat new.bash
#!/bin/bash
#SBATCH --cpus-per-task=4 --mem-per-cpu=16g --ntasks=1
#SBATCH hetjob
#SBATCH --cpus-per-task=2 --mem-per-cpu=1g  --ntasks=8

srun run.app

$ sbatch new.bash

Is equivalent to the following:
以下と同等です。

$ cat my.bash
#!/bin/bash
srun run.app

$ sbatch --cpus-per-task=4 --mem-per-cpu=16g --ntasks=1 : \
         --cpus-per-task=2 --mem-per-cpu=1g  --ntasks=8 my.bash

The batch script will be executed in the first node in the first component of the heterogeneous job.
バッチスクリプトは、異種ジョブの最初のコンポーネントの最初のノードで実行されます。
For the above example, that will be the job component with 1 task, 4 CPUs and 64 GB of memory (16 GB for each of the 4 CPUs).
上記の例では、これは1つのタスク、4つのCPU、および64 GBのメモリ（4つのCPUのそれぞれに16 GB）を備えたジョブコンポーネントになります。

If a heterogeneous job is submitted to run in multiple clusters not part of a federation (e.g. "sbatch --cluster=alpha,beta ...") then the entire job will be sent to the cluster expected to be able to start all components at the earliest time.
フェデレーションの一部ではない複数のクラスターで実行するために異種ジョブが送信された場合（「sbatch--cluster = alpha、beta ...」など）、ジョブ全体がクラスターに送信され、すべてのコンポーネントを開始できることが期待されます。早い時期に。

A resource limit test is performed when a heterogeneous job is submitted in order to immediately reject jobs that will not be able to start with current limits.
リソース制限テストは、現在の制限で開始できないジョブをすぐに拒否するために、異種ジョブが送信されたときに実行されます。
The individual components of the heterogeneous job are validated, like all regular jobs.
異種ジョブの個々のコンポーネントは、すべての通常のジョブと同様に検証されます。
The heterogeneous job as a whole is also tested, but in a more limited fashion with respect to quality of service (QOS) limits.
全体としての異種ジョブもテストされますが、サービス品質（QOS）の制限に関してより限定された方法でテストされます。
Each component of a heterogeneous job counts as a "job" with respect to resource limits.
異種ジョブの各コンポーネントは、リソース制限に関して「ジョブ」としてカウントされます。

Burst Buffers

A burst buffer can either be persistent or linked to a specific job ID (at least the Cray implementation).
バーストバッファは、永続的であるか、特定のジョブID（少なくともCray実装）にリンクされている可能性があります。
Since a heterogeneous job consists of multiple job IDs, a job-specific burst buffer will be associated with only one heterogeneous job component.
異種ジョブは複数のジョブIDで構成されているため、ジョブ固有のバーストバッファーは1つの異種ジョブコンポーネントにのみ関連付けられます。
Only a persistent burst buffer can be accessed by all components of a heterogeneous job.
異種ジョブのすべてのコンポーネントからアクセスできるのは、永続バーストバッファーのみです。
A sample batch script demonstrating this for a Cray system is appended.
Crayシステムでこれを示すサンプルバッチスクリプトが追加されています。

#!/bin/bash
#SBATCH --nodes=1 --constraint=haswell
#BB create_persistent name=alpha capacity=10 access=striped type=scratch
#DW persistentdw name=alpha
#SBATCH hetjob
#SBATCH --nodes=16 --constraint=knl
#DW persistentdw name=alpha
...

NOTE: Cray's DataWarp interface directly reads the job script, but has no knowledge of "Slurm's "hetjob" directive, so Slurm internally rebuilds the script for each job component so that only that job components burst buffer directives are included in that script.
注：CrayのDataWarpインターフェースはジョブスクリプトを直接読み取りますが、「Slurmの「hetjob」ディレクティブの知識がないため、Slurmは各ジョブコンポーネントのスクリプトを内部的に再構築し、そのジョブコンポーネントのバーストバッファーディレクティブのみがそのスクリプトに含まれるようにします。
The batch script first component of the job will be modified in order to replace the "#DW" directives of other job components with "#EXCLUDED DW" to prevent their interpretation by Cray infrastructure.
ジョブのバッチスクリプトの最初のコンポーネントは、他のジョブコンポーネントの「#DW」ディレクティブを「#EXCLUDED DW」に置き換えて、Crayインフラストラクチャによる解釈を防ぐために変更されます。
Since the batch script will only be executed by the first job component, the subsequent job components will not include commands from the original script.
バッチスクリプトは最初のジョブコンポーネントによってのみ実行されるため、後続のジョブコンポーネントには元のスクリプトのコマンドは含まれません。
These scripts are build and managed by Slurm for internal purposes (and visiable from various Slurm commands) from a user script as shown above.
これらのスクリプトは、上記のようにユーザースクリプトから内部目的で（そしてさまざまなSlurmコマンドから表示できるように）Slurmによってビルドおよび管理されます。
An example is shown below:
例を以下に示します。

Rebuilt script for first job component

#!/bin/bash
#SBATCH --nodes=1 --constraint=haswell
#BB create_persistent name=alpha capacity=10 access=striped type=scratch
#DW persistentdw name=alpha
#SBATCH hetjob
#SBATCH --nodes=16 --constraint=knl
#EXCLUDED DW persistentdw name=alpha
...


Rebuilt script for second job component

#!/bin/bash
#SBATCH --nodes=16 --constraint=knl
#DW persistentdw name=alpha
exit 0

Managing Jobs

Information maintained in Slurm for a heterogeneous job includes:
異種ジョブのためにSlurmで維持される情報には、次のものがあります。

• job_id: Each component of a heterogeneous job will have its own unique job_id.
  job_id：異種ジョブの各コンポーネントには、固有のjob_idがあります。
  
• het_job_id: This identification number applies to all components of the heterogeneous job.
  het_job_id：この識別番号は、異種ジョブのすべてのコンポーネントに適用されます。
  All components of the same job will have the same het_job_id value and it will be equal to the job_id of the first component.
  同じジョブのすべてのコンポーネントは同じhet_job_id値を持ち、最初のコンポーネントのjob_idと等しくなります。
  We refer to this as the "heterogeneous job leader".
  これを「異質なジョブリーダー」と呼びます。
  
• het_job_id_set: Regular expression identifying all job_id values associated with the job.
  het_job_id_set：ジョブに関連付けられているすべてのjob_id値を識別する正規表現。
  
• het_job_offset: A unique sequence number applied to each component of the heterogeneous job.
  het_job_offset：異種ジョブの各コンポーネントに適用される一意のシーケンス番号。
  The first component will have a het_job_offset value of 0, the next a value of 1, etc.
  最初のコンポーネントのhet_job_offset値は0、次のコンポーネントの値は1などになります。
  

job_id	het_job_id	het_job_offset	het_job_id_set
123	123	0	123-127
124	123	1	123-127
125	123	2	123-127
126	123	3	123-127
127	123	4	123-127

Table 1: Example job IDs

The squeue and sview commands report the components of a heterogeneous job using the format "<het_job_id>+<het_job_offset>".
squeueコマンドとsviewコマンドは、「＜het_job_id＞ + ＜het_job_offset＞」の形式を使用して異種ジョブのコンポーネントを報告します。
For example "123+4" would represent heterogeneous job id 123 and its fifth component (note: the first component has a het_job_offset value of 0).
たとえば、「123 + 4」は、異種ジョブID 123とその5番目のコンポーネントを表します（注：最初のコンポーネントのhet_job_offset値は0です）。

A request for a specific job ID that identifies a ID of the first component of a heterogeneous job (i.e. the "heterogeneous job leader") will return information about all components of that job.
異種ジョブの最初のコンポーネント（つまり、「異種ジョブリーダー」）のIDを識別する特定のジョブIDの要求は、そのジョブのすべてのコンポーネントに関する情報を返します。
For example:
例えば：

$ squeue --job=93
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST
 93+0     debug  bash  adam  R 18:18      1 nid00001
 93+1     debug  bash  adam  R 18:18      1 nid00011
 93+2     debug  bash  adam  R 18:18      1 nid00021

A request to cancel or otherwise signal a heterogeneous job leader will be applied to all components of that heterogeneous job.
異種のジョブリーダーをキャンセルまたは通知する要求は、その異種のジョブのすべてのコンポーネントに適用されます。
A request to cancel a specific component of the heterogeneous job using the "#+#" notation will apply only to that specific component.
「＃+＃」表記を使用して異種ジョブの特定のコンポーネントをキャンセルする要求は、その特定のコンポーネントにのみ適用されます。
For example:
例えば：

$ squeue --job=93
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST
 93+0     debug  bash  adam  R 19:18      1 nid00001
 93+1     debug  bash  adam  R 19:18      1 nid00011
 93+2     debug  bash  adam  R 19:18      1 nid00021
$ scancel 93+1
$ squeue --job=93
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST
 93+0     debug  bash  adam  R 19:38      1 nid00001
 93+2     debug  bash  adam  R 19:38      1 nid00021
$ scancel 93
$ squeue --job=93
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST

While a heterogeneous job is in pending state, only the entire job can be cancelled rather than its individual components.
異種ジョブが保留状態にある間は、個々のコンポーネントではなく、ジョブ全体のみをキャンセルできます。
A request to cancel an individual component of a heterogeneous job not in pending state will return an error.
保留状態にない異種ジョブの個々のコンポーネントをキャンセルする要求は、エラーを返します。
After the job has begun execution, the individual component can be cancelled.
ジョブの実行が開始された後、個々のコンポーネントをキャンセルできます。

Email notification for job state changes (the --mail-type option) is only supported for a heterogeneous job leader.
ジョブ状態の変更に関する電子メール通知（--mail-typeオプション）は、異種のジョブリーダーでのみサポートされます。
Requests for email notifications for other components of a heterogeneous job will be silently ignored.
異種ジョブの他のコンポーネントの電子メール通知の要求は、黙って無視されます。

Requests to modify an individual component of a job using the scontrol command must specify the job ID with the "#+#" notation.
scontrolコマンドを使用してジョブの個々のコンポーネントを変更する要求では、「＃+＃」表記でジョブIDを指定する必要があります。
A request to modify a job by specifying the het_job_id will modify all components of a heterogeneous job.
het_job_idを指定してジョブを変更するリクエストは、異種ジョブのすべてのコンポーネントを変更します。
For example:
例えば：

# Change the account of component 2 of heterogeneous job 123:
$ scontrol update jobid=123+2 account=abc

# Change the time limit of all components of heterogeneous job 123:
$ scontrol update jobid=123 timelimit=60

Requests to perform the following operations a job can only be requested for a heterogeneous job leader and will be applied to all components of that heterogeneous job.
次の操作を実行する要求は、異種のジョブリーダーに対してのみ要求でき、その異種のジョブのすべてのコンポーネントに適用されます。
Requests to operate on individual components of the heterogeneous will return an error.
異種の個々のコンポーネントを操作する要求はエラーを返します。

• requeue
• resume
• suspend

The sbcast command supports heterogeneous job allocations.
sbcastコマンドは、異種のジョブ割り当てをサポートします。
By default, sbcast will will copy files to all nodes in the job allocation.
デフォルトでは、sbcastはジョブ割り当て内のすべてのノードにファイルをコピーします。
The -j/--jobid option can be used to copy files to individual components as shown below.
以下に示すように、-j / -jobidオプションを使用して、ファイルを個々のコンポーネントにコピーできます。

$ sbcast --jobid=123   data /tmp/data
$ sbcast --jobid=123.0 app0 /tmp/app0
$ sbcast --jobid=123.1 app1 /tmp/app1

The srun commands --bcast option will transfer files to the nodes associated with the application to be launched as specified by the --het-group option.
srunコマンドの--bcastオプションは、-het-groupオプションで指定されているように、起動するアプリケーションに関連付けられているノードにファイルを転送します。

Slurm has a configuration option to control behavior of some commands with respect to heterogeneous jobs.
Slurmには、異種ジョブに関する一部のコマンドの動作を制御するための構成オプションがあります。
By default a request to cancel, hold or release a job ID that is not the het_job_id, but that of a job component will only operate that one component of the heterogeneous job.
デフォルトでは、het_job_idではないジョブIDをキャンセル、保留、または解放する要求がありますが、ジョブコンポーネントの要求は、異種ジョブのその1つのコンポーネントのみを操作します。
If SchedulerParameters configuration parameter includes the option "whole_hetjob" then the operation would apply to all components of the job if any job component is specified to be operated upon.
SchedulerParameters構成パラメーターにオプション「whole_hetjob」が含まれている場合、操作対象のジョブコンポーネントが指定されていれば、その操作はジョブのすべてのコンポーネントに適用されます。
In the below example, the scancel command will either cancel all components of job 93 if SchedulingParameters=whole_hetjob is configured, otherwise only job 93+1 will be cancelled.
以下の例では、SchedulingParameters = Wholesale_hetjobが設定されている場合、scancelコマンドはジョブ93のすべてのコンポーネントをキャンセルします。それ以外の場合、ジョブ93 +1のみがキャンセルされます。
If a specific heterogeneous job component is specified (e.g. "scancel 93+1"), then only that one component will be effected.
特定の異種ジョブコンポーネントが指定されている場合（「scancel93 + 1」など）、その1つのコンポーネントのみが影響を受けます。

$ squeue --job=93
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST
 93+0     debug  bash  adam  R 19:18      1 nid00001
 93+1     debug  bash  adam  R 19:18      1 nid00011
 93+2     debug  bash  adam  R 19:18      1 nid00021
$ scancel 94 (where job ID 94 is equivalent to 93+1)
# Cancel 93+0, 93+1 and 93+2 if SchedulerParameters includes "whole_hetjob"
# Cancel only 93+1 if SchedulerParameters does not include "whole_hetjob"

Accounting

Slurm's accounting database records the het_job_id and het_job_offset fields.
Slurmのアカウンティングデータベースは、het_job_idフィールドとhet_job_offsetフィールドを記録します。
The sacct command reports job's using the format "<het_job_id>+<het_job_offset>" and can accept a job ID specification for filtering using the same format.
sacctコマンドは、「＜het_job_id＞ + ＜het_job_offset＞」の形式を使用してジョブを報告し、同じ形式を使用してフィルタリングするためのジョブID指定を受け入れることができます。
If a het_job_id value is specified as a job filter, then information about all components of that job will be reported as shown below by default.
het_job_id値がジョブフィルターとして指定されている場合、そのジョブのすべてのコンポーネントに関する情報は、デフォルトで以下に示すように報告されます。
The --whole-hetjob=[yes|no] option can be used to force to report the information about all the components of that job or just about the specific component requested, no matter if the job filter includes the het_job_id (leader) or not.
--whole-hetjob = [yes | no]オプションを使用すると、ジョブフィルターにhet_job_id（リーダー）が含まれているかどうかに関係なく、そのジョブのすべてのコンポーネントまたは要求された特定のコンポーネントに関する情報を強制的にレポートできます。そうではありません。

$ sacct -j 67767
  JobID JobName Partition Account AllocCPUS     State ExitCode 
------- ------- --------- ------- --------- --------- -------- 
67767+0     foo     debug    test         2 COMPLETED      0:0 
67767+1     foo     debug    test         4 COMPLETED      0:0 

$  sacct -j 67767+1
  JobID JobName Partition Account AllocCPUS     State ExitCode 
------- ------- --------- ------- --------- --------- -------- 
67767+1     foo     debug    test         4 COMPLETED      0:0 

$  sacct -j 67767 --whole-hetjob=no
  JobID JobName Partition Account AllocCPUS     State ExitCode
------- ------- --------- ------- --------- --------- --------
67767+0     foo     debug    test         4 COMPLETED      0:0

$ sacct -j 67767+1 --whole-hetjob=yes
  JobID JobName Partition Account AllocCPUS     State ExitCode
------- ------- --------- ------- --------- --------- --------
67767+0     foo     debug    test         2 COMPLETED      0:0
67767+1     foo     debug    test         4 COMPLETED      0:0

Launching Applications (Job Steps)

The srun command is used to launch applications.
srunコマンドは、アプリケーションを起動するために使用されます。
By default, the application is launched only on the first component of a heterogeneous job, but options are available to support different behaviors.
デフォルトでは、アプリケーションは異種ジョブの最初のコンポーネントでのみ起動されますが、さまざまな動作をサポートするためのオプションを利用できます。

srun's "--het-group" option defines which hetjob component(s) are to have applications launched for them.
srunの「--het-group」オプションは、アプリケーションを起動するhetjobコンポーネントを定義します。
The --het-group option takes an expression defining which component(s) are to launch an application for an individual execution of the srun command.
--het-groupオプションは、srunコマンドを個別に実行するためにアプリケーションを起動するコンポーネントを定義する式を取ります。
The expression can contain one or more component index values in a comma separated list.
式には、コンマ区切りのリストに1つ以上のコンポーネントインデックス値を含めることができます。
Ranges of index values can be specified in a hyphen separated list.
インデックス値の範囲は、ハイフンで区切られたリストで指定できます。
By default, an application is launched only on component number zero.
デフォルトでは、アプリケーションはコンポーネント番号0でのみ起動されます。
Some examples follow:
いくつかの例を次に示します。

• --het-group=2
• --het-group=0,4
• --het-group=1,3-5

IMPORTANT: The ability to execute a single application across more than one job allocation does not work with all MPI implementations or Slurm MPI plugins.
重要：複数のジョブ割り当てにわたって単一のアプリケーションを実行する機能は、すべてのMPI実装またはSlurmMPIプラグインで機能するとは限りません。
Slurm's ability to execute such an application can be disabled on the entire cluster by adding "disable_hetjob_steps" to Slurm's SchedulerParameters configuration parameter.
このようなアプリケーションを実行するSlurmの機能は、SlurmのSchedulerParameters構成パラメーターに「disable_hetjob_steps」を追加することにより、クラスター全体で無効にすることができます。

IMPORTANT: While the srun command can be used to launch heterogeneous job steps, mpirun would require substantial modification to support heterogeneous applications.
重要：srunコマンドを使用して異種のジョブステップを起動できますが、mpirunでは、異種のアプリケーションをサポートするために大幅な変更が必要になります。
We are aware of no such mpirun development efforts at this time.
現時点では、そのようなmpirun開発の取り組みはありません。

By default, the applications launched by a single execution of the srun command (even for different components of the heterogeneous job) are combined into one MPI_COMM_WORLD with non-overlapping task IDs.
デフォルトでは、srunコマンドの1回の実行によって起動されたアプリケーションは（異種ジョブの異なるコンポーネントに対しても）、重複しないタスクIDを持つ1つのMPI_COMM_WORLDに結合されます。

As with the salloc and sbatch commands, the ":" character is used to separate multiple components of a heterogeneous job.
sallocおよびsbatchコマンドと同様に、「：」文字は、異種ジョブの複数のコンポーネントを区切るために使用されます。
This convention means that the stand-alone ":" character can not be used as an argument to an application launched by srun.
この規則は、スタンドアロンの「：」文字をsrunによって起動されたアプリケーションの引数として使用できないことを意味します。
This includes the ability to execute different applications and arguments for each job component.
これには、ジョブコンポーネントごとに異なるアプリケーションと引数を実行する機能が含まれます。
If some heterogeneous job component lacks an application specification, the next application specification provided will be used for earlier components lacking one as shown below.
一部の異種ジョブコンポーネントにアプリケーション仕様がない場合、次に示すアプリケーション仕様が、以下に示すように、アプリケーション仕様がない以前のコンポーネントに使用されます。

$ srun --label -n2 : -n1 hostname
0: nid00012
1: nid00012
2: nid00013

If multiple srun commands are executed concurrently, this may result in resource contention (e.g. memory limits preventing some job steps components from being allocated resources because of two srun commands executing at the same time).
複数のsrunコマンドが同時に実行されると、リソースの競合が発生する可能性があります（たとえば、2つのsrunコマンドが同時に実行されるため、メモリ制限により、一部のジョブステップコンポーネントにリソースが割り当てられなくなります）。
If the srun --het-group option is used to create multiple job steps (for the different components of a heterogeneous job), those job steps will be created sequentially.
srun --het-groupオプションを使用して複数のジョブステップを作成する場合（異種ジョブのさまざまなコンポーネントに対して）、それらのジョブステップは順番に作成されます。
When multiple srun commmands execute at the same time, this may result in some step allocations taking place, while others are delayed.
複数のsrunコマンドが同時に実行されると、一部のステップ割り当てが発生し、他のステップ割り当てが遅延する可能性があります。
Only after all job step allocations have been granted will the application being launched.
すべてのジョブステップの割り当てが許可された後でのみ、アプリケーションが起動されます。

All components of a job step will have the same step ID value.
ジョブステップのすべてのコンポーネントは、同じステップID値を持ちます。
If job steps are launched on subsets of the job components there may be gaps in the step ID values for individual job components.
ジョブステップがジョブコンポーネントのサブセットで起動される場合、個々のジョブコンポーネントのステップID値にギャップがある可能性があります。

$ salloc -n1 : -n2 beta bash
salloc: Pending job allocation 1721
salloc: Granted job allocation 1721
$ srun --het-group=0,1 true   # Launches steps 1721.0 and 1722.0
$ srun --het-group=0   true   # Launches step  1721.1, no 1722.1
$ srun --het-group=0,1 true   # Launches steps 1721.2 and 1722.2

The maximum het-group specified in a job step allocation (either explicitly specified or implied by the ":" separator) must not exceed the number of components in the heterogeneous job allocation.
ジョブステップ割り当てで指定される最大hetグループ（明示的に指定されるか、「：」区切り文字で暗黙的に指定される）は、異種ジョブ割り当てのコンポーネントの数を超えてはなりません。
For example
例えば

$ salloc -n1 -C alpha : -n2 -C beta bash
salloc: Pending job allocation 1728
salloc: Granted job allocation 1728
$ srun --het-group=0,1 hostname
nid00001
nid00008
nid00008
$ srun hostname : date : id
error: Attempt to run a job step with het-group value of 2,
       but the job allocation has maximum value of 1

Environment Variables

Slurm environment variables will be set independently for each component of the job by appending "_HET_GROUP_" and a sequence number the usual name.
Slurm環境変数は、「_ HET_GROUP_」と通常の名前のシーケンス番号を追加することにより、ジョブのコンポーネントごとに個別に設定されます。
In addition, the "SLURM_JOB_ID" environment variable will contain the job ID of the heterogeneous job leader and "SLURM_HET_SIZE" will contain the number of components in the job.
さらに、「SLURM_JOB_ID」環境変数には異種ジョブリーダーのジョブIDが含まれ、「SLURM_HET_SIZE」にはジョブ内のコンポーネントの数が含まれます。
If using srun with a single specific het group (for instance --het-group=1) "SLURM_JOB_ID" will contain the job ID of that specific component, behaving like a regular (non-heterogeneous job).
単一の特定のhetグループ（たとえば--het-group = 1）でsrunを使用する場合、「SLURM_JOB_ID」にはその特定のコンポーネントのジョブIDが含まれ、通常の（非異種ジョブ）のように動作します。
For example:
例えば：

$ salloc -N1 : -N2 bash
salloc: Pending job allocation 11741
salloc: job 11741 queued and waiting for resources
salloc: job 11741 has been allocated resources
$ env | grep SLURM
SLURM_JOB_ID=11741
SLURM_HET_SIZE=2
SLURM_JOB_ID_HET_GROUP_0=11741
SLURM_JOB_ID_HET_GROUP_1=11742
SLURM_JOB_NODES_HET_GROUP_0=1
SLURM_JOB_NODES_HET_GROUP_1=2
SLURM_JOB_NODELIST_HET_GROUP_0=nid00001
SLURM_JOB_NODELIST_HET_GROUP_1=nid[00011-00012]
...
$ srun --het-group=1 printenv SLURM_JOB_ID
11742
$ srun --het-group=0 printenv SLURM_JOB_ID
11741

The various MPI implementations rely heavily upon Slurm environment variables for proper operation.
さまざまなMPI実装は、適切な操作のためにSlurm環境変数に大きく依存しています。
A single MPI applications executing in a single MPI_COMM_WORLD require a uniform set of environment variables that reflect a single job allocation.
単一のMPI_COMM_WORLDで実行される単一のMPIアプリケーションには、単一のジョブ割り当てを反映する環境変数の統一されたセットが必要です。
The example below shows how Slurm sets environment variables for MPI.
以下の例は、SlurmがMPIの環境変数を設定する方法を示しています。

$ salloc -N1 : -N2 bash
salloc: Pending job allocation 11741
salloc: job 11751 queued and waiting for resources
salloc: job 11751 has been allocated resources
$ env | grep SLURM
SLURM_JOB_ID=11751
SLURM_HET_SIZE=2
SLURM_JOB_ID_HET_GROUP_0=11751
SLURM_JOB_ID_HET_GROUP_1=11752
SLURM_JOB_NODELIST_HET_GROUP_0=nid00001
SLURM_JOB_NODELIST_HET_GROUP_1=nid[00011-00012]
...
$ srun --het-group=0,1 env | grep SLURM
SLURM_JOB_ID=11751
SLURM_JOB_NODELIST=nid[00001,00011-00012]
...

Examples

Create a heterogeneous resource allocation containing one node with 256GB of memory and a feature of "haswell" plus 2176 cores on 32 nodes with a feature of "knl".
256GBのメモリと「haswell」の機能を備えた1つのノードと、「knl」の機能を備えた32ノード上の2176コアを含む異種リソース割り当てを作成します。
Then launch a program called "master" on the "haswell" node and "slave" on the "knl" nodes.
次に、「haswell」ノードで「master」、「knl」ノードで「slave」というプログラムを起動します。
Each application will be in its own MPI_COMM_WORLD.
各アプリケーションは、独自のMPI_COMM_WORLDにあります。

salloc -N1 --mem=256GB -C haswell : \
       -n2176 -N32 --ntasks-per-core=1 -C knl bash
srun master &
srun --het-group=1 slave &
wait

This variation of the above example launches programs "master" and "slave" in a single MPI_COMM_WORLD.
上記の例のこのバリエーションは、単一のMPI_COMM_WORLDでプログラム「master」と「slave」を起動します。

salloc -N1 --mem=256GB -C haswell : \
       -n2176 -N32 --ntasks-per-core=1 -C knl bash
srun master : slave &

The SLURM_PROCID and SLURM_TASKID environment variables will be set to reflect a global task rank (both environment variables will have the same value).
SLURM_PROCIDおよびSLURM_TASKID環境変数は、グローバルタスクランクを反映するように設定されます（両方の環境変数は同じ値になります）。
Each spawned process will have a unique SLURM_PROCID.
生成された各プロセスには、一意のSLURM_PROCIDがあります。

Similarly, the SLURM_NPROCS and SLURM_NTASKS environment variables will be set to reflect a global task count (both environment variables will have the same value).
同様に、SLURM_NPROCSおよびSLURM_NTASKS環境変数は、グローバルタスクカウントを反映するように設定されます（両方の環境変数は同じ値になります）。
SLURM_NTASKS will be set to the total count of tasks in all components.
SLURM_NTASKSは、すべてのコンポーネントのタスクの総数に設定されます。
Note that the task rank and count values are needed by MPI and typically determined by examining Slurm environment variables.
タスクのランクとカウントの値はMPIに必要であり、通常はSlurm環境変数を調べることによって決定されることに注意してください。

Limitations

The backfill scheduler has limitations in how it tracks usage of CPUs and memory in the future.
バックフィルスケジューラには、将来のCPUとメモリの使用状況を追跡する方法に制限があります。
This typically requires the backfill scheduler be able to allocate each component of a heterogeneous job on a different node in order to begin its resource allocation, even if multiple components of the job do actually get allocated resources on the same node.
これには通常、ジョブの複数のコンポーネントが実際に同じノードに割り当てられたリソースを取得する場合でも、リソース割り当てを開始するために、バックフィルスケジューラが異種ジョブの各コンポーネントを異なるノードに割り当てることができる必要があります。

In a federation of clusters, a heterogeneous job will execute entirely on the cluster from which the job is submitted.
クラスターのフェデレーションでは、異種ジョブは、ジョブの送信元のクラスターで完全に実行されます。
The heterogeneous job will not be eligible to migrate between clusters or to have different components of the job execute on different clusters in the federation.
異種ジョブは、クラスター間で移行したり、フェデレーション内の異なるクラスターでジョブの異なるコンポーネントを実行したりすることはできません。

Caution must be taken when submitting heterogeneous jobs that request multiple overlapping partitions.
複数の重複するパーティションを要求する異種ジョブを送信する場合は注意が必要です。
When the partitions share the same resources it's possible to starve your own job by having the first job component request enough nodes that the scheduler isn't able to fill the subsequent request(s).
パーティションが同じリソースを共有している場合、最初のジョブコンポーネントに十分なノードを要求させて、スケジューラーが後続の要求を満たすことができないようにすることで、独自のジョブを枯渇させる可能性があります。
Consider an example where you have partition p1 that contains 10 nodes and partition p2 that exists on 5 of the same nodes.
10個のノードを含むパーティションp1と、同じノードの5個に存在するパーティションp2がある例を考えてみます。
If you submit a heterogeneous job that requests 5 nodes in p1 and 5 nodes in p2, the scheduler may try to allocate some of the nodes from the p2 partition for the first job component, preventing the scheduler from being able to fulfill the second request, resulting in a job that is never able to start.
p1の5ノードとp2の5ノードを要求する異種ジョブを送信すると、スケジューラーは最初のジョブコンポーネントのp2パーティションからノードの一部を割り当てようとし、スケジューラーが2番目の要求を満たすことができなくなる可能性があります。その結果、ジョブを開始できなくなります。

Job arrays of heterogeneous jobs are not supported.
異種ジョブのジョブ配列はサポートされていません。

The srun command's --no-allocate option is not supported for heterogeneous jobs.
srunコマンドの--no-allocateオプションは、異種ジョブではサポートされていません。

Only one job step per heterogeneous job component can be launched by a single srun command (e.g. "srun --het-group=0 alpha : --het-group=0 beta" is not supported).
単一のsrunコマンドで起動できるジョブステップは、異種ジョブコンポーネントごとに1つだけです（たとえば、「srun --het-group = 0 alpha：-het-group = 0beta」はサポートされていません）。

The sattach command can only be used to attach to a single component of a heterogeneous job at a time.
sattachコマンドは、一度に異種ジョブの単一のコンポーネントにアタッチするためにのみ使用できます。

Heterogeneous jobs are only scheduled by the backfill scheduler plugin.
異種ジョブは、バックフィルスケジューラプラグインによってのみスケジュールされます。
The more frequently executed scheduling logic only starts jobs on a first-in first-out (FIFO) basis and lacks logic for concurrently scheduling all components of a heterogeneous job.
より頻繁に実行されるスケジューリングロジックは、先入れ先出し（FIFO）ベースでのみジョブを開始し、異種ジョブのすべてのコンポーネントを同時にスケジューリングするためのロジックを欠いています。

Heterogeneous jobs are not supported on Cray ALPS systems.
異種ジョブは、CrayALPSシステムではサポートされていません。

Heterogeneous jobs are not supported on IBM PE systems.
異種ジョブは、IBMPEシステムではサポートされていません。

Slurm's PERL APIs currently do not support heterogeneous jobs.
SlurmのPERLAPIは現在、異種ジョブをサポートしていません。

The srun --multi-prog option can not be used to span more than one heterogeneous job component.
srun --multi-progオプションを使用して、複数の異種ジョブコンポーネントにまたがることはできません。

The srun --open-mode option is by default set to "append".
srun --open-modeオプションは、デフォルトで「追加」に設定されています。

Ancient versions of OpenMPI and their derivatives (i.e. Cray MPI) are dependent upon communication ports being assigned to them by Slurm.
OpenMPIの古いバージョンとその派生物（つまり、Cray MPI）は、Slurmによって割り当てられている通信ポートに依存しています。
Such MPI jobs will experience step launch failure if any component of a heterogeneous job step is unable to acquire the allocated ports.
このようなMPIジョブでは、異種のジョブステップのいずれかのコンポーネントが割り当てられたポートを取得できない場合、ステップの起動に失敗します。
Non-heterogeneous job steps will retry step launch using a new set of communication ports (no change in Slurm behavior).
非異種のジョブステップは、新しい通信ポートのセットを使用してステップの起動を再試行します（Slurmの動作に変更はありません）。

System Administrator Information

The job submit plugin is invoked independently for each component of a heterogeneous job.
ジョブ送信プラグインは、異種ジョブのコンポーネントごとに個別に呼び出されます。

The spank_init_post_opt() function is invoked once for each component of a heterogeneous job.
spank_init_post_opt（）関数は、異種ジョブのコンポーネントごとに1回呼び出されます。
This permits site defined options on a per job component basis.
これにより、ジョブコンポーネントごとにサイト定義のオプションが許可されます。

Scheduling of heterogeneous jobs is performed only by the sched/backfill plugin and all heterogeneous job components are either all scheduled at the same time or deferred.
異種ジョブのスケジューリングは、sched / backfillプラグインによってのみ実行され、すべての異種ジョブコンポーネントは、すべて同時にスケジュールされるか、延期されます。
The pending reason of heterogeneous jobs isn't set until backfill evaluation.
異種ジョブの保留中の理由は、埋め戻し評価まで設定されません。
In order to ensure the timely initiation of both heterogeneous and non-heterogeneous jobs, the backfill scheduler alternates between two different modes on each iteration.
異種ジョブと非異種ジョブの両方をタイムリーに開始するために、バックフィルスケジューラは各反復で2つの異なるモードを交互に切り替えます。
In the first mode, if a heterogeneous job component can not be initiated immediately, its expected start time is recorded and all subsequent components of that job will be considered for starting no earlier than the latest component's expected start time.
最初のモードでは、異種ジョブコンポーネントをすぐに開始できない場合、その予想開始時刻が記録され、そのジョブの後続のすべてのコンポーネントは、最新のコンポーネントの予想開始時刻より前に開始されたと見なされます。
In the second mode, all heterogeneous job components will be considered for starting no earlier than the latest component's expected start time.
2番目のモードでは、すべての異種ジョブコンポーネントは、最新のコンポーネントの予想開始時刻より前に開始すると見なされます。
After completion of the second mode, all heterogeneous job expected start time data is cleared and the first mode will be used in the next backfill scheduler iteration.
2番目のモードの完了後、すべての異種ジョブの予想開始時刻データがクリアされ、最初のモードが次のバックフィルスケジューラの反復で使用されます。
Regular (non-heterogeneous jobs) are scheduled independently on each iteration of the backfill scheduler.
通常の（非異種ジョブ）は、バックフィルスケジューラの各反復で個別にスケジュールされます。

For example, consider a heterogeneous job with three components.
たとえば、3つのコンポーネントを持つ異種ジョブについて考えてみます。
When considered as independent jobs, the components could be initiated at times now (component 0), now plus 2 hour (component 1), and now plus 1 hours (component 2).
独立したジョブと見なされる場合、コンポーネントは、現在（コンポーネント0）、現在プラス2時間（コンポーネント1）、および現在プラス1時間（コンポーネント2）で開始される可能性があります。
When the backfill scheduler runs in the first mode:
バックフィルスケジューラが最初のモードで実行される場合：

1. Component 0 will be noted to possible to start now, but not initiated due to the additional components to be initiated
   コンポーネント0は、今すぐ開始できることに注意してください。ただし、追加のコンポーネントが開始されるため、開始されません。
   
2. Component 1 will be noted to be possible to start in 2 hours
   コンポーネント1は2時間で開始できることに注意してください
   
3. Component 2 will not be considered for scheduling until 2 hours in the future, which leave some additional resources available for scheduling to other jobs
   コンポーネント2は、将来2時間までスケジューリングの対象とは見なされません。これにより、他のジョブのスケジューリングに使用できる追加のリソースが残ります。
   

When the backfill scheduler executes next, it will use the second mode and (assuming no other state changes) all three job components will be considered available for scheduling no earlier than 2 hours in the future, which may allow other jobs to be allocated resources before heterogeneous job component 0 could be initiated.
バックフィルスケジューラが次に実行されると、2番目のモードが使用され、（他の状態が変化しないと仮定して）3つのジョブコンポーネントすべてが、2時間以内にスケジュール可能であると見なされます。これにより、他のジョブに前にリソースを割り当てることができます。異種ジョブコンポーネント0を開始できます。

The heterogeneous job start time data will be cleared before the first mode is used in the next iteration in order to consider system status changes which might permit the heterogeneous to be initiated at an earlier time than previously determined.
異種ジョブの開始時間データは、最初のモードが次の反復で使用される前にクリアされ、以前に決定されたよりも早い時間に異種を開始できる可能性のあるシステムステータスの変更を検討します。

A resource limit test is performed when a heterogeneous job is submitted in order to immediately reject jobs that will not be able to start with current limits.
リソース制限テストは、現在の制限で開始できないジョブをすぐに拒否するために、異種ジョブが送信されたときに実行されます。
The individual components of the heterogeneous job are validated, like all regular jobs.
異種ジョブの個々のコンポーネントは、すべての通常のジョブと同様に検証されます。
The heterogeneous job as a whole is also tested, but in a more limited fashion with respect to quality of service (QOS) limits.
全体としての異種ジョブもテストされますが、サービス品質（QOS）の制限に関してより限定された方法でテストされます。
This is due to the complexity of each job component having up to three sets of limits (association, job QOS and partition QOS).
これは、最大3セットの制限（関連付け、ジョブQOS、およびパーティションQOS）を持つ各ジョブコンポーネントの複雑さによるものです。
Note that successful submission of any job (heterogeneous or otherwise) does not ensure the job will be able to start without exceeding some limit.
（異種またはその他の）ジョブの送信が成功しても、制限を超えずにジョブを開始できるとは限らないことに注意してください。
For example a job's CPU limit test does not consider that CPUs might not be allocated individually, but resource allocations might be performed by whole core, socket or node.
たとえば、ジョブのCPU制限テストでは、CPUが個別に割り当てられていない可能性があるとは見なされませんが、リソースの割り当てはコア、ソケット、またはノード全体で実行される可能性があります。
Each component of a heterogeneous job counts as a "job" with respect to resource limits.
異種ジョブの各コンポーネントは、リソース制限に関して「ジョブ」としてカウントされます。

For example, a user might have a limit of 2 concurrent running jobs and submit a heterogeneous job with 3 components.
たとえば、ユーザーが同時に実行できるジョブは2つに制限されており、3つのコンポーネントを含む異種ジョブを送信する場合があります。
Such a situation will have an adverse effect upon scheduling other jobs, especially other heterogeneous jobs.
このような状況は、他のジョブ、特に他の異種ジョブのスケジューリングに悪影響を及ぼします。

Last modified 30 March 2020