これは、Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、MAC OS オンライン エミュレーターなどの複数の無料オンライン ワークステーションの XNUMX つを使用して、OnWorks 無料ホスティング プロバイダーで実行できるコマンド orte-submit です。
プログラム：
NAME
orte-submit、ompi-submit - DVM を使用して Open MPI でシリアル ジョブおよびパラレル ジョブを実行します。
注意： オムピ送信 オルテサブミット は互いに同義語です。 どちらかの名前を使用する
同じ動作を生成します。
SYNOPSIS
単一プロセス複数データ (SPMD) モデル:
オムピ送信 [オプション] [ ]
複数命令複数データ (MIMD) モデル:
オムピ送信 [ グローバルオプション ]
[ローカルオプション1] [ ]:
[ローカルオプション2] [ ]:
··· ：
[ local_optionsN ] [ 】
どちらのモデルでも、 オムピ送信 絶対パス名経由は次と同等です
の指定 --prefix オプション付き ディレクトリに相当する値。 オムピ
提出する 最後のサブディレクトリを除いた場所に存在します。 例えば：
% /usr/local/bin/ompi-submit ...
に相当します
% ompi-submit --prefix / usr / local
QUICK 概要
of オルテサブミット 必要 それ フォーム 最初の start 分散 バーチャル マシン (DVM)
オルテDVM.
MPI アプリケーションを実行する方法を単に探している場合は、おそらく、
次の形式のコマンドライン:
% ompi-submit [ -np X ] [ --hostfile ]
これにより、X 個のコピーが実行されます 現在のランタイム環境 (以下で実行している場合)
サポートされているリソース マネージャー、Open MPI オムピ送信 通常は自動的に使用されます
たとえば、対応するリソース マネージャー プロセス スターターではなく、 rsh or ssh,
ホストファイルを使用する必要があるか、デフォルトですべての X コピーを実行します。
localhost)、CPU スロットごとにラウンドロビン方式で (デフォルトで) スケジューリングします。 残りの部分を見る
詳細については、このページをご覧ください。
v1.8 の開始時点では、ompi-submit はプロセスを自動的にバインドすることに注意してください。
シリーズ。 それ以上のディレクティブがない場合は、XNUMX つのバインディング パターンが使用されます。
バインド 〜へ 芯： プロセス数が 2 以下の場合
バインド 〜へ ソケット： プロセス数が 2 を超える場合
アプリケーションがスレッドを使用する場合は、スレッドが使用されていないことを確認する必要があるでしょう。
まったくバインドされていない (--bind-to none を指定することにより)、または
アプリケーションごとの適切なバインディング レベルまたは特定の数の処理要素
プロセス。
OPTIONS
オムピ送信 ローカルノード上で呼び出されたディレクトリの名前を送信します。
各リモート ノードにアクセスし、そのディレクトリへの変更を試みます。 「現在」を参照してください。
詳細については、以下の「作業ディレクトリ」セクションを参照してください。
プログラムの実行可能ファイル。 これは最初の認識されない引数として識別されます
オムピ提出する。
これらの実行時引数をすべての新しいプロセスに渡します。 これらは常に
最後の引数 オムピ送信。 アプリコンテキストファイルを使用する場合、 なります
無視されます。
-h, - 助けて
このコマンドのヘルプを表示する
-q, - 静かな
アプリケーションの実行中に orte-submit からの情報メッセージを抑制します。
-v, -詳細
冗長にする
-V, - バージョン
バージョン番号を出力します。 他の引数が指定されていない場合も、
orte-submit で終了します。
次のオプションのいずれかを使用して、DVM のどのホスト (ノード) を実行するかを指定します。
DVM の外部のホストを指定するとエラーが発生します。
-H, -ホスト, - ホスト
プロセスを呼び出すホストのリスト。
-ホストファイル, --hostfile
使用するホストファイルを指定します。
-マシンファイル, --マシンファイル
の同義語 -ホストファイル.
次のオプションは、起動するプロセスの数を指定します。 いずれも存在しないことに注意してください。
オプションは特定のバインディング ポリシーを暗黙的に示します。たとえば、ソケットごとに N 個のプロセスを要求します。
プロセスがソケットにバインドされることを意味するものではありません。
-c, -n, --n, -np <#>
指定されたノード上でこの数のプログラムのコピーを実行します。 このオプションは次のことを示します
指定されたファイルは実行可能プログラムであり、アプリケーション コンテキストではありません。 いいえの場合
値は、実行するコピーの数として提供されます (つまり、「-np」も
その同義語はコマンドラインで提供されます)、Open MPI は自動的に実行されます
各プロセス スロット上のプログラムのコピー (「プロセス」の説明については、以下を参照してください)
スロット")。ただし、この機能は SPMD モデルでのみ使用でき、返されます。
それ以外の場合は、エラー (アプリケーションの実行は開始されません)。
—マップバイ ppr:N:
各ノードで指定されたタイプのオブジェクトの数を N 倍して起動します。
-npersocket, --npersocket <#パーソケット>
各ノードで、この数のプロセスにプロセッサ ソケットの数を乗じた数を起動します。
ノード。 の -npersocket オプションもオンになります -ソケットへのバインド オプションを選択します。
(非推奨となり、--map-by ppr:n:socket が使用されます)
-npernode, --npernode <#pernode>
各ノードで、これだけの数のプロセスを起動します。 (--map-by を推奨するため非推奨になりました)
ppr:n:ノード)
-pernode, --pernode
各ノードで XNUMX つのプロセスを起動します -- 以下に相当します -npernode 1. (で非推奨になりました)
--map-by ppr:1:node を優先します)
プロセスをマッピングするには:
--map-by
指定されたオブジェクトにマップします。デフォルトは ソケット。 サポートされているオプションには、スロット、
hwthread、コア、L1キャッシュ、L2キャッシュ、L3キャッシュ、ソケット、沼、ボード、ノード、シーケンシャル、
距離とppr。 どのオブジェクトにも : と任意の修飾子を追加することで修飾子を含めることができます。
PE=n (各プロシージャに n 個の処理要素をバインド)、SPAN (負荷分散) の組み合わせ
割り当て全体のプロセス)、OVERSUBSCRIBE (ノード上でより多くのプロセスを許可)
処理要素より)、および NOOVERSUBSCRIBE。 これには PPR が含まれます。
pattern は、修飾子から区切るために別のコロンで終了します。
-バイコア, --バイコア
コアごとにプロセスをマップします (--map-by core を推奨するため非推奨になりました)
-バイソケット, --バイソケット
ソケットごとにプロセスをマップします (--map-byソケットを優先して非推奨になりました)
-nolocal, --nolocal
起動したアプリケーションのコピーを orte-submit と同じノードで実行しないでください。
が走っています。 このオプションは、ローカルホストのリストを上書きします。 - ホスト または任意の
他のホスト指定メカニズム。
-nooversubscribe, --nooversubscribe
どのノードもオーバーサブスクライブしないでください。 (プロセスを開始せずに) エラーが発生した場合、
要求されたプロセス数によりオーバーサブスクリプションが発生する可能性があります。 このオプションは暗黙的に
「max_slots」を各ノードの「slots」値に等しく設定します。
-bynode, --bynode
プロセスはノードごとに XNUMX つずつ起動され、ラウンドロビン方式でノードごとに循環されます。 これ
プロセスをノード間で均等に分散し、ラウンドで MPI_COMM_WORLD ランクを割り当てます。
ロビン、「ノードごと」の方法。
MPI_COMM_WORLD でプロセスのランクを順序付けするには:
--ランクバイ
指定されたオブジェクトに従ってラウンドロビン方式でランク付けされます。デフォルトは次のとおりです。 スロット.
サポートされているオプションには、スロット、ハードウェアスレッド、コア、L1キャッシュ、L2キャッシュ、L3キャッシュ、ソケット、
沼、ボード、ノード。
プロセスバインディングの場合:
--バインド先
プロセスを指定されたオブジェクトにバインドします。デフォルトは 。 サポートされているオプションは次のとおりです
スロット、ハードウェアスレッド、コア、l1cache、l2cache、l3cache、ソケット、沼、ボード、およびなし。
-cpus-per-proc, --cpus-per-proc <#perproc>
各プロセスを指定された数の CPU にバインドします。 (--map- を推奨するため非推奨になりました)
に:PE=n)
-CPU ランクごと, --CPU ランクごと <#perrank>
のエイリアス -cpus-per-proc。 (--map-by を推奨するため非推奨になりました) :PE=n)
-コアへのバインド, --コアにバインド
プロセスをコアにバインドします (--bind-to core を推奨するため非推奨になりました)
-ソケットへのバインド, --ソケットにバインド
プロセスをプロセッサソケットにバインドします (--bind-toソケットを優先して非推奨になりました)
-バインドなし, --none にバインド
プロセスをバインドしない (--bind-to none を推奨するため非推奨)
-レポートバインディング, --レポートバインディング
起動されたプロセスのバインディングを報告します。
-スロットリスト, --スロットリスト
MPI プロセスのバインドに使用されるプロセッサ ID のリスト。 指定されたバインディング
すべての MPI プロセスに適用されます。 構文については、以下の説明を参照してください。
ランクファイルの場合:
-rf, --ランクファイル
ランクファイル ファイルを提供します。
標準 I/O を管理するには:
-出力ファイル名, -出力ファイル名
すべてのプロセスの stdout、stderr、および stddiag をプロセス固有のプロセスにリダイレクトします。
指定されたファイル名のバージョン。 ファイル名内のディレクトリはすべて、
自動的に作成されます。 各出力ファイルは filename.id で構成されます。
id は MPI_COMM_WORLD 内のプロセスのランクになります。
リスト内の正しい順序。
-標準入力, --標準入力
標準入力を受信するプロセスの MPI_COMM_WORLD ランク。 デフォルトは次のとおりです
標準入力を MPI_COMM_WORLD ランク 0 に転送しますが、このオプションは転送に使用できます。
任意のプロセスへの標準入力。 と指定することも可能です なし、いいえを示します
プロセスは標準入力を受信します。
-タグ出力, --タグ出力
出力の各行を stdout、stderr、stddiag にタグ付けします。 [ジョブビッド、
MCW_ランク] プロセスのジョブ ID と MPI_COMM_WORLD ランクを示します。
出力を生成したプロセスと、出力を生成したチャネル。
-タイムスタンプ出力, --タイムスタンプ出力
stdout、stderr、stddiag への出力の各行にタイムスタンプを付けます。
-xml, --xml
すべての出力を xml 形式で stdout、stderr、および stddiag に提供します。
-xterm, --xterm
MPI_COMM_WORLD ランクによって識別されるプロセスからの出力を表示します。
個別の xterm ウィンドウ。 ランクは、次のコンマ区切りのリストとして指定されます。
範囲。-1 はすべてを示します。 それぞれに別のウィンドウが作成されます
指定されたプロセス。 注意： xterm は通常、終了時にウィンドウを終了します。
その中で実行されているプロセスの。 ただし、「！」を追加すると、 リストの最後まで
指定されたランクの場合、xterm が確実に維持するために適切なオプションが提供されます。
窓が開いています After プロセスが終了するため、プロセスを確認できるようになります。
出力。 その後、各 xterm ウィンドウを手動で閉じる必要があります。 注意： In
一部の環境では、xterm では実行可能ファイルがユーザーのパスにあることが必要になる場合があります。
絶対条件または相対条件で指定できます。 したがって、次の指定が必要になる場合があります。
ローカル実行可能ファイルは、単なる「foo」ではなく「./foo」として実行されます。 xterm が
実行可能ファイルを実行すると、ompi-submit はハングしますが、ctrl-c には正しく応答します。 もしも
この問題が発生する場合は、実行可能ファイルが正しく指定されていることを確認して、試してください。
再び。
ファイルとランタイム環境を管理するには:
-道, - 道
これは、要求された実行可能ファイルを見つけようとするときに使用されます。 これ
ローカル PATH 設定を使用する前に使用されます。
--prefix
設定に使用されるプレフィックス ディレクトリ パス LD_LIBRARY_PATH
Open MPI またはターゲット プロセスを呼び出す前に、リモート ノードを実行します。 「リモート」を参照してください。
実行」セクションを参照してください。
--preload-binary
リモートを開始する前に、指定された実行可能ファイルをリモート マシンにコピーします。
プロセス。 実行可能ファイルは Open MPI セッション ディレクトリにコピーされ、
ジョブが完了すると削除されます。
--preload-files
ファイルのカンマ区切りリストを現在の作業ディレクトリにプリロードします。
プロセスが開始される前にプロセスが起動されるリモート マシン。
--preload-files-dest-dir
現在のディレクトリ以外の場合、プリロード ファイルに使用される宛先ディレクトリ。
作業ディレクトリ。 デフォルトでは、によって提供される絶対パスと相対パスは、
--preload-files が使用されます。
-wd
の同義語 -wdir.
-wdir
ディレクトリに移動しますユーザーのプログラムが実行される前に。 「現在」を参照してください。
相対パスに関する注意事項については、「作業ディレクトリ」セクションを参照してください。 注意： Status -wdir オプション
コマンドラインとアプリケーションコンテキストの両方に表示される場合、コンテキストは
コマンドラインよりも優先されます。 したがって、目的の wdir へのパスが
バックエンドノード上で異なる場合は、絶対パスとして指定する必要があります。
バックエンド ノードに関しては正しいです。
-x
を実行する前に、指定された環境変数をリモート ノードにエクスポートします。
プログラム。 XNUMX つにつき指定できる環境変数は XNUMX つだけです -x オプション。 既存
環境変数を指定することも、新しい変数名を指定することもできます。
対応する値。 例えば：
% ompi-submit -x DISPLAY -x OFILE=/tmp/out ...
のパーサー -x オプションはあまり洗練されていません。 それは理解さえできません
引用符で囲まれた値。 ユーザーは環境に変数を設定してから使用することをお勧めします。
-x それらをエクスポートする (定義しない)。
MCA パラメータの設定:
-gmca, --gmca
すべてのコンテキストに適用できるグローバル MCA パラメータを渡します。 は
パラメータ名; パラメータ値です。
-mca, --mca
引数をさまざまな MCA モジュールに送信します。 以下の「MCA」セクションを参照してください。
デバッグの場合:
-デバッグ, - デバッグ
で示されたユーザーレベルのデバッガーを呼び出します。 orte_base_user_debugger MCA
パラメータに一致する最初のデバイスのリモートコントロール URL を返します。
-デバッガ, - デバッガ
いつ検索するデバッガのシーケンス - デバッグ が使用されます（つまり、
orte_base_user_debugger MCAパラメータ）。
-テレビ, - テレビ
TotalView デバッガーでプロセスを起動します。 非推奨の下位互換性
国旗。 の同義語 - デバッグ.
他にも次のオプションがあります。
--allow-root として実行
許可する オムピ送信 root ユーザーによる実行時に実行されます (オムピ送信 デフォルトは
root ユーザーとして起動すると中止されます)。
-中止されました, --中止されました <#>
表示する中止されたプロセスの最大数を設定します。
- アプリ
他のすべてのコマンド ライン オプションを無視して、appfile を指定します。
-cf, --cartofile
地図作成ファイルを提供します。
--ヘテロ
32/64 ビットが混在した複数の app_context が提供されていることを示します
バイナリ。
-ompi-サーバー, --ompi-サーバー <ウリ or ファイル>
Open MPI サーバーの URI (または、
server) 、それを含むファイルの名前 (file:filename として指定)
info、またはとして使用される ompi-submit の PID (pid:# として指定)
サーバー。 Open MPI サーバーは、マルチアプリケーション データをサポートするために使用されます。
MPI-2 MPI_Publish_name および MPI_Lookup_name 関数を介して交換します。
次のオプションは開発者にとって便利です。 一般に、それらはほとんどの人にとって役に立ちません
ORTE および/または MPI ユーザー:
-d, --debug-開発
OmpiRTE (Open MPI のランタイム層) のデバッグを有効にします。 これではありません
通常、ほとんどのユーザーにとって便利です。
他のオプションがリストされている場合があります オムピ送信 - 助けて.
環境 変数
MPIEXEC_TIMEOUT
最大秒数 オムピ送信 (mpiexec）が実行されます。 この後たくさんの
秒、 オムピ送信 起動されたジョブを中止して終了します。
DESCRIPTION
XNUMX回の呼び出しで、 オムピ送信 Open MPI で実行される MPI アプリケーションを開始します。 もし
アプリケーションは単一プロセス複数データ (SPMD) であり、アプリケーションは
オムピ送信 コマンドライン。
アプリケーションが複数の命令で構成される複数データ (MIMD) の場合、
プログラム、プログラムのセット、および引数は、次の XNUMX つの方法のいずれかで指定できます。
コマンドライン引数とアプリケーションコンテキスト。
アプリケーション コンテキストは、すべての引数を含む MIMD プログラム セットを記述します。
別のファイル。 このファイルには基本的に複数のファイルが含まれています オムピ送信 コマンドライン、以下
コマンド名そのもの。 異なるオプションを指定する機能
プログラムのインスタンス化も、アプリケーション コンテキストを使用する理由の XNUMX つです。
拡張コマンドライン引数を使用すると、アプリケーションのレイアウトを
コロンを使用したコマンドライン (:) プログラムと引数の指定を区切ります。
一部のオプションは、指定されたすべてのプログラムにわたってグローバルに設定されます (例: --hostfile)。
その他は単一のプログラムに固有です (例: -np)。
指定 主催者 Nodes
ホスト ノードは、 オムピ送信 を使用したコマンドライン -ホスト オプションまたは
ホストファイル。
たとえば、
ompi-submit -H aa,aa,bb ./a.out
ノード aa で XNUMX つのプロセスを起動し、bb で XNUMX つのプロセスを起動します。
または、ホストファイルを考慮してください
% 猫 myhostfile
単三スロット=2
bbスロット=2
cc スロット = 2
DVM が起動されているため、 オルテDVM, オルテサブミット のスロット引数は無視されます。
ホストファイル。 ホストファイル経由で提供される値 オルテDVM 行動をコントロールしていきます。
ompi-submit -hostfile myhostfile ./a.out
XNUMX つのノードのそれぞれで XNUMX つのプロセスを起動します。
ompi-submit -hostfile myhostfile -host aa ./a.out
XNUMX つのプロセスが両方ともノード aa 上で起動されます。
ompi-submit -hostfile myhostfile -host dd ./a.out
実行するホストが見つからず、エラーが発生して中止されます。 つまり、指定されたホスト dd
指定されたホストファイルにありません。
指定 数 of プロセス
これまで見てきたように、実行するプロセスの数は、hostfile を使用して設定できます。 他の
メカニズムが存在します。
起動されるプロセスの数は、ノード数の倍数として指定することも、
プロセッサソケットが利用可能です。 例えば、
ompi-submit -H aa,bb -npersocket 2 ./a.out
プロセス 0 ～ 3 をノード aa で起動し、プロセス 4 ～ 7 をノード bb で起動します。ここで、aa と bb は両方とも
デュアルソケットノード。 の -npersocket オプションもオンになります -ソケットへのバインド オプション、
これについては後のセクションで説明します。
ompi-submit -H aa,bb -npernode 2 ./a.out
プロセス 0 ～ 1 をノード aa で起動し、プロセス 2 ～ 3 をノード bb で起動します。
ompi-submit -H aa,bb -npernode 1 ./a.out
ホスト ノードごとに XNUMX つのプロセスを起動します。
ompi-submit -H aa,bb -pernode ./a.out
と同じです。 -npernode 1.
もう XNUMX つの方法は、プロセスの数を指定することです。 -np オプション。 検討
今はホストファイル
% 猫 myhostfile
単三スロット=4
bbスロット=4
cc スロット = 4
今、
ompi-submit -hostfile myhostfile -np 6 ./a.out
プロセス 0 ～ 3 はノード aa で起動され、プロセス 4 ～ 5 はノード bb で起動されます。 残り
ホストファイル内のスロットは使用されません。 -np オプションは 6 のみを示しました
プロセスを開始する必要があります。
マッピング プロセス 〜へ ノード： 使い方 政策
上記の例は、プロセス process のノードへのデフォルトのマッピングを示しています。 これ
マッピングはさまざまな方法で制御することもできます オムピ送信 マッピングを説明するオプション
ポリシー。
上記と同じホストファイルをもう一度考えてみましょう。 -np 6:
ノード aa ノード bb ノード cc
ompi-送信 0 1 2 3 4 5
ompi-submit --map-by ノード 0 3 1 4 2 5
ompi-submit -nolocal 0 1 2 3 4 5
当学校区の --map-by オプションは、利用可能なノード間でプロセスの負荷を分散します。
ラウンドロビン方式で各プロセスに番号を付けます。
当学校区の -nolocal このオプションは、プロセスがローカル ホストにマップされるのを防ぎます (この例では
ケースノード aa)。 その間 オムピ送信 通常、システム リソースをほとんど消費しません。 -nolocal することができます
非常に大規模なジョブを開始する場合に役立ちます。 オムピ送信 実際に使用する必要があるかもしれません
顕著な量のメモリおよび/または処理時間。
同じように -np スロットよりも少ないプロセスを指定でき、オーバーサブスクライブすることもできます
スロット。 たとえば、同じホストファイルを使用すると、次のようになります。
ompi-submit -hostfile myhostfile -np 14 ./a.out
ノード aa でプロセス 0 ～ 3、bb でプロセス 4 ～ 7、cc でプロセス 8 ～ 11 を起動します。 次に、
残りの XNUMX つのプロセスは、選択したノードに送信されます。
オーバーサブスクリプションに対する制限を指定することもできます。 たとえば、同じホストファイルを使用すると、次のようになります。
ompi-submit -hostfile myhostfile -np 14 -nooversubscribe ./a.out
エラーが発生しますので、 -nooversubscribe オーバーサブスクリプションを防ぎます。
オーバーサブスクリプションの制限は、ホストファイル自体で指定することもできます。
% 猫の myhostfile
aa スロット = 4 max_slots = 4
bb max_slots=4
cc スロット = 4
当学校区の 最大スロット数 フィールドでそのような制限を指定します。 そうなると、 スロット 値のデフォルトは
限界。 今：
ompi-submit -hostfile myhostfile -np 14 ./a.out
最初の 12 プロセスは以前と同様に起動されますが、残りの XNUMX プロセスは起動されません。
プロセスはノード cc に強制的に配置されます。 他の XNUMX つのノードは、
このジョブによるオーバーサブスクリプションに対するホストファイル。
使い方 --nooversubscribe Open MPI は現在取得できないため、このオプションは役に立ちます。
リソースマネージャーからの「max_slots」値。
もちろん、 -np と一緒に使用することもできます -H or -ホスト オプション。 例えば、
ompi-submit -H aa,bb -np 8 ./a.out
8つのプロセスを起動します。 ホストが XNUMX つだけ指定されているため、最初の XNUMX つのホストの後に
プロセスは XNUMX つが aa に、もう XNUMX つが bb にマップされ、残りのプロセスはオーバーサブスクライブします
指定されたホスト。
MIMD の例は次のとおりです。
ompi-submit -H aa -np 1 ホスト名 : -H bb,cc -np 2 稼働時間
実行中のプロセス0を起動します hostname ノード aa 上でプロセス 1 と 2 がそれぞれ実行中
uptime それぞれノード bb と cc 上にあります。
マッピング、 ランキング、 バインディング： Oh 私の！
Open MPI では、プロセスの場所とランクを割り当てるために XNUMX 段階の手順が採用されています。
マッピング 各プロセスにデフォルトの場所を割り当てます
ランキング MPI_COMM_WORLD ランク値を各プロセスに割り当てます
拘束 各プロセスを特定のプロセッサ上で実行するように制約します。
当学校区の マッピング ステップは、マッパーに基づいて各プロセスにデフォルトの場所を割り当てるために使用されます。
雇用されている。 スロット、ノード、および順にマッピングすると、
ノードレベルまで処理します。 対照的に、オブジェクトによるマッピングでは、マッパーは次のことを割り当てることができます。
各ノード上で実際のオブジェクトへの処理を行います。
注意： プロセスに割り当てられる場所は、プロセスがバインドされる場所とは無関係です。
割り当ては、バインディング アルゴリズムへの入力としてのみ使用されます。
プロセスプロセスのノードへのマッピングは、一般的なポリシーだけでなく定義することもできます
また、必要に応じて、単純な表現では記述できない任意のマッピングを使用することもできます。
ポリシー。 ホストファイルを XNUMX 行ずつ読み取る「シーケンシャル マッパー」を使用できます。
ホストファイルで指定された順序でプロセスをノードに割り当てます。 使用 -mca マップ
seq オプション。 たとえば、前と同じホストファイルを使用します。
ompi-submit -hostfile myhostfile -mca rmaps seq ./a.out
は、ノード aa、bb、および cc のそれぞれに XNUMX つずつ、合計 XNUMX つのプロセスを起動します。 スロット
数は関係ありません。 リストされているノード上で XNUMX 行ごとに XNUMX つのプロセスが起動されます。
ライン。
任意のマッピングを指定するもう XNUMX つの方法は、ランクファイルを使用することです。
プロセスバインディングも制御します。 ランクファイルについては以下で説明します。
第 XNUMX フェーズでは、次の点に焦点を当てます。 ランキング ジョブの MPI_COMM_WORLD 内のプロセスの。
Open MPI はこれをマッピング手順から分離し、より柔軟なマッピング手順を可能にします。
MPI プロセスの相対的な配置。 これは、次のことを考慮するとよくわかります。
—map-by ppr:2:socket オプションを使用した XNUMX つのケース:
ノード aa ノード bb
ランクバイコア0 1 ! 2 3 4 5 ! 6 7
ランクバイソケット 0 2 ! 1 3 4 6 ! 5 7
ランク別ソケット:スパン 0 4 ! 1 5 2 6 ! 3 7
コア別とスロット別のランキングでは同じ結果が得られます。これは単純な経過です。
MPI_COMM_WORLD は各ノード全体でランク付けされます。 ソケットごとのランキングは、以下の範囲内でラウンドロビン ランキングを実行します。
すべてのプロセスに MCW ランクが割り当てられるまで各ノードを実行し、その後、
次のノード。 を追加すると、 スパン ランキング ディレクティブの修飾子により、ランキング アルゴリズムが実行されます。
割り当て全体を単一のエンティティとして扱うため、MCW ランクが割り当てられます。
最初に戻る前に、すべてのソケットにわたって実行します。
当学校区の 拘束 フェーズは実際に各プロセスを特定のプロセッサのセットにバインドします。 これはできる
オペレーティング システムがプロセスを最適に配置していない場合は、パフォーマンスが向上します。 ために
たとえば、一部のマルチコア プロセッサ ソケットをオーバーサブスクライブし、他のソケットを残す可能性があります。
アイドル状態。 これにより、プロセスが共通リソースを求めて不必要に競合する可能性があります。 あるいは、それ
プロセスが広範囲に分散しすぎる可能性があります。 アプリケーションのパフォーマンスが低い場合、これは最適ではない可能性があります
プロセス間通信コストに敏感です。 バインディングは動作を維持することもできます
プロセスがどれほど最適であるかに関係なく、システムはプロセスを過度に移行しないようにします。
初めから置かれていました。
バインディングに使用されるプロセッサは、トポロジー グループの観点から識別できます。
- たとえば、l3cache にバインドすると、各プロセスがスコープ内のすべてのプロセッサにバインドされます。
割り当てられた場所内の単一の L3 キャッシュ。 したがって、プロセスが
マッパーを特定のソケットに設定してから、 —バインド先 l3キャッシュ ディレクティブによりプロセスは次のようになります
そのソケット内で単一の L3 キャッシュを共有するプロセッサにバインドされます。
負荷のバランスをとるために、バインディング ディレクティブは、バインドするときにラウンドロビン方式を使用します。
マッパーで使用されるレベルよりも低いレベル。 たとえば、ジョブがマッピングされている場合を考えてみましょう。
ソケットレベルにバインドされてから、コアにバインドされます。 各ソケットには複数のコアがあるため、
複数のプロセスが特定のソケットにマップされると、バインディング アルゴリズムによってそれぞれのプロセスが割り当てられます。
ラウンドロビン方式で、ソケットに配置されたプロセスを一意のコアに割り当てます。
あるいは、l2cache によってマップされてからソケットにバインドされたプロセスは、単純にバインドされます。
それらが配置されているソケット内のすべてのプロセッサーに送信されます。 このようにして、ユーザーは次のことができます。
相対的な MCW ランクの位置とバインディングを詳細に制御します。
最後に、 --レポートバインディング バインディングのレポートに使用できます。
例として、それぞれが XNUMX つのコアで構成される XNUMX つのプロセッサ ソケットを持つノードを考えてみましょう。 私たち
ラン オムピ送信 -np 4 --レポートバインディング および次の追加オプション:
% ompi-submit ... --map-by core --bind-to core
[...] ... 子 [...,0] を CPU 0001 にバインドしています
[...] ... 子 [...,1] を CPU 0002 にバインドしています
[...] ... 子 [...,2] を CPU 0004 にバインドしています
[...] ... 子 [...,3] を CPU 0008 にバインドしています
% ompi-submit ... --map-by ソケット --bind-to ソケット
[...] ... 子 [...,0] をソケット 0 cpus 000f にバインドしています
[...] ... 子 [...,1] をソケット 1 cpus 00f0 にバインドしています
[...] ... 子 [...,2] をソケット 0 cpus 000f にバインドしています
[...] ... 子 [...,3] をソケット 1 cpus 00f0 にバインドしています
% ompi-submit ... --map-by core:PE=2 --bind-to core
[...] ... 子 [...,0] を CPU 0003 にバインドしています
[...] ... 子 [...,1] を CPU 000c にバインドしています
[...] ... 子 [...,2] を CPU 0030 にバインドしています
[...] ... 子 [...,3] を CPU 00c0 にバインドしています
% ompi-submit ... --bind-to none
ここでは、 --レポートバインディング は、各プロセスのバインディングをマスクとして示しています。 最初のケースでは、
プロセスは、マスク 0001、0002、0004、および
0008. XNUMX 番目のケースでは、プロセスは、示されているように、連続するソケット上のすべてのコアにバインドされます。
マスク 000f および 00f0 によって。 プロセスはプロセッサ ソケットをラウンドで循環します。
ロビンファッションを必要なだけ何度でも。 2 番目のケースでは、マスクは次のことを示しています。
コアはプロセスごとにバインドされています。 XNUMX 番目のケースでは、バインディングがオフになり、
バインディングが報告されています。
Open MPI によるプロセス バインディングのサポートは、基盤となるオペレーティング システムによって異なります。
したがって、特定のプロセス バインド オプションはすべてのシステムで利用できるわけではありません。
プロセス バインディングは、MCA パラメーターを使用して設定することもできます。 それらの使用法は以下よりも不便です
の オムピ送信 オプション。 一方、MCA パラメータは、
オムピ送信 コマンドライン、またはシステムまたはユーザーの mca-params.conf ファイル内、あるいは
以下の MCA セクションで説明されているように、環境変数。 例としては次のようなものがあります。
ompi-submit オプションの MCA パラメータのキー値
--map-by コア rmaps_base_mapping_policy コア
--map-by ソケット rmaps_base_mapping_policy ソケット
--rank-by コア rmaps_base_ranking_policy コア
--bind-to core hwloc_base_binding_policy core
--ソケットへのバインド hwloc_base_binding_policy ソケット
--bind-to なし hwloc_base_binding_policy なし
ランクファイル
Rankfile は、個々のプロセスの詳細情報を指定するテキスト ファイルです。
ノードにマッピングする必要があり、どのプロセッサにバインドする必要があります。 の各行
Rankfile は XNUMX つのプロセスの場所を指定します (MPI ジョブの場合、プロセスの「ランク」はプロセスを指します)
MPI_COMM_WORLD でのランクに)。 ランクファイルの各行の一般的な形式は次のとおりです。
ランク= スロット=
具体的な例を挙げますと、以下の通りです。
$猫myrankfile
ランク 0=aa スロット=1:0-2
ランク1=BBスロット=0:0,1
ランク 2=cc スロット=1-2
$ ompi-submit -H aa,bb,cc,dd -rf myrankfile ./a.out
という意味です
ランク 0 はノード aa で実行され、論理ソケット 1、コア 0 ～ 2 にバインドされます。
ランク 1 はノード bb 上で実行され、論理ソケット 0、コア 0 および 1 にバインドされます。
ランク 2 はノード cc 上で実行され、論理コア 1 および 2 にバインドされます。
代わりに Rankfile を使用して指定することもできます 物理的な プロセッサの場所。 この場合、
構文は多少異なります。 ソケットが認識されなくなり、スロット番号が
ほとんどの OS は一意の物理 PU を割り当てないため、指定されるのは物理 PU の番号である必要があります。
ノード内の各コアの識別子。 したがって、適切な物理ランクファイルは次のようになります。
以下
$ cat myphysicalrankfile
ランク 0=aa スロット=1
ランク1=BBスロット=8
ランク 2=cc スロット=6
これは、
ランク 0 は、物理 PU 1 を含むコアにバインドされたノード aa で実行されます。
ランク 1 は、物理 PU 8 を含むコアにバインドされたノード bb で実行されます。
ランク 2 はノード cc で実行され、物理 PU 6 を含むコアにバインドされます。
ランクファイルは次のように扱われます 論理的な デフォルトでは、MCA パラメータ
ランクファイルを指定するには、rmaps_rank_file_physical を 1 に設定する必要があります。
と見なされる 物理的な.
上記のホスト名は「絶対」です。つまり、実際に解決可能なホスト名は次のとおりです。
指定。 ただし、ホスト名は「相対」として指定することもできます。
外部で指定されたホスト名のリストに関連して指定されます (例: ompi-submit の
--host 引数、ホストファイル、またはジョブ スケジューラ)。
「相対」指定は「+n」の形式です。 "、ここで、X は、
使用可能なすべてのホスト名のセット内の X 番目のホスト名。0 からインデックスが付けられます。次に例を示します。
$猫myrankfile
rank 0=+n0 slot=1:0-2
ランク 1=+n1 スロット=0:0,1
ランク 2=+n2 スロット=1-2
$ ompi-submit -H aa,bb,cc,dd -rf myrankfile ./a.out
Open MPI v1.7 以降、すべてのソケット/コア スロットの位置は次のように指定されます。 論理的な
インデックス (Open MPI v1.6 シリーズを使用) 物理的な インデックス）。 などのツールを使用できます
HWLOC の「lstopo」は、ソケットとコアの論理インデックスを検索します。
Application コンテキスト or 実行可能ファイル プログラム？
XNUMX つの異なる形式を区別するには、 オムピ送信 コマンドラインで検索します - アプリ
オプション。 これが指定されている場合、コマンドラインで指定されたファイルは
アプリケーションコンテキスト。 指定しない場合、ファイルは実行可能ファイルとみなされます。
プログラム。
位置
ファイルの相対パスまたは絶対パスが指定されていない場合、Open MPI は最初にファイルを検索します。
で指定されたディレクトリを検索してファイルを検索します。 - 道 オプション。 ない場合 - 道
オプションが設定されているか、ファイルが見つからない場合は、 - 道 場所を指定すると、Open MPI が検索します
ソース ノードで定義されているユーザーの PATH 環境変数。
相対ディレクトリを指定する場合は、初期作業ディレクトリからの相対ディレクトリである必要があります。
使用する特定のスターターによって決まります。 たとえば、rsh または ssh スターターを使用する場合、
デフォルトでは、初期ディレクトリは $HOME です。 他のスターターは初期ディレクトリを次のように設定する場合があります。
の呼び出しによる現在の作業ディレクトリ オムピ送信.
電流プローブ ワーキング ディレクトリ
当学校区の -wdir ompi-submit オプション (およびその同義語、 -wd) に変更できるようになります。
プログラムが呼び出される前の任意のディレクトリ。 応用でも使えます
特定のノード上および/または特定のノード上の作業ディレクトリを指定するためのコンテキスト ファイル
分野の様々なアプリケーションで使用されています。
Status -wdir オプションはコンテキスト ファイルとコマンド ラインの両方に表示されます。
ファイルディレクトリはコマンドライン値をオーバーライドします。
Status -wdir オプションが指定されている場合、Open MPI は指定されたものに変更しようとします。
すべてのリモート ノード上のディレクトリ。 これが失敗した場合、 オムピ送信 中止します。
Status -wdir オプションがある 指定すると、Open MPI はディレクトリ名を送信します。 オムピ
提出する 各リモート ノードに対して呼び出されます。 リモートノードは次のように変更しようとします。
そのディレクトリ。 それができない場合 (たとえば、そのノードにディレクトリが存在しない場合)、
Open MPI はスターターによって決定されたデフォルトのディレクトリを使用します。
ディレクトリの変更はすべて、ユーザーのプログラムが呼び出される前に行われます。 それまで待たない
MPI_INIT が呼び出されます。
スタンダード I / O
Open MPI は、UNIX 標準入力を /dev/null を除くすべてのプロセスに送信します。
MPI_COMM_WORLD ランク 0 プロセス。 MPI_COMM_WORLD ランク 0 プロセスは標準入力を継承します
from オムピ送信. 注意： 呼び出したノード オムピ送信 と同じである必要はない
MPI_COMM_WORLD ランク 0 プロセスが存在するノード。 Open MPI は、次のリダイレクトを処理します。
オムピ送信のランク 0 プロセスへの標準入力。
Open MPI は、UNIX 標準出力とエラーをリモート ノードから呼び出したノードに送信します。
オムピ送信 そしてそれを標準出力/エラーに出力します。 オムピ送信。 ローカルプロセス
の標準出力/エラーを継承します。 オムピ送信 直接転送します。
したがって、Open MPI アプリケーションの標準 I/O をリダイレクトするには、
典型的なシェルのリダイレクト手順 オムピ送信.
% ompi-submit -np 2 my_app < my_input > my_output
この例では、 の MPI_COMM_WORLD ランク 0 プロセスがストリームを受信します
from 私の入力 標準入力で。 他のすべてのノードの stdin は /dev/null に関連付けられます。
ただし、すべてのノードからの標準出力は 私の出力 ファイルにソフトウェアを指定する必要があります。
シグナル 伝播
orte-submit が SIGTERM と SIGINT を受け取ると、次の方法でジョブ全体を強制終了しようとします。
ジョブ内のすべてのプロセスに SIGTERM を送信し、数秒待機してから、
ジョブ内のすべてのプロセスに SIGKILL を送信します。
orte-submit によって受信された SIGUSR1 および SIGUSR2 シグナルは、
仕事。
ompi-submit によって実行されるプログラムへの SIGSTOP および SIGCONT の転送をオンにすることができます。
MCA パラメータ orte_forward_job_control を 1 に設定することにより、SIGTSTOP シグナルが
submit により、ompi によって開始されたすべてのプログラムに SIGSTOP シグナルが送信されます。
submit と同様に、ompi-submit への SIGCONT シグナルによって SIGCONT が送信されます。
現在、他のシグナルは orte-submit によって伝播されません。
プロセス 終了 / シグナル ハンドリング
MPI アプリケーションの実行中に、いずれかのプロセスが異常終了した場合 (終了するか、
呼び出す前に MPI_FINALIZE、または信号の結果として死亡します）、 オムピ送信 印刷します
エラー メッセージを出力し、残りの MPI アプリケーションを強制終了します。
ユーザーシグナルハンドラーはおそらく MPI 状態をクリーンアップしようとすることを避けるべきです (Open MPI は
現在、非同期シグナルセーフではありません。 見る MPI_Init_thread(3)詳細はこちら
MPI_THREAD_MULTIPLE およびスレッドの安全性)。 たとえば、セグメンテーション違反が発生した場合、
MPI_SEND (おそらく不正なバッファが渡されたため)、ユーザーシグナルハンドラーは
このユーザーハンドラーが呼び出そうとした場合に呼び出されます。 MPI_FINALIZE、悪いことが起こる可能性があります
エラーが発生したとき、Open MPI はすでに MPI 内にあったためです。 以来 オムピ送信 意志
プロセスがシグナルにより終了したことに注意してください。おそらくこれは必要ありません (そして最も安全です)。
ユーザーは非 MPI 状態のみをクリーンアップできます。
プロセス 環境
MPI アプリケーション内のプロセスは、Open RTE デーモンから環境を継承します。
それらが実行されているノード。 環境は通常、
ユーザーのシェル。 リモート ノードでは、正確な環境はブート MCA モジュールによって決定されます。
中古。 NS rsh たとえば、起動モジュールは次のいずれかを使用します rsh/ssh Open RTE を起動するには
リモート ノード上のデーモンであり、通常はユーザーの XNUMX つ以上のシェルセットアップ ファイルを実行します。
Open RTE デーモンを起動する前に。 動的にリンクされたアプリケーションを実行する場合、
が必要 LD_LIBRARY_PATH 環境変数を設定する必要があるため、次のことを確認する必要があります。
Open MPI の起動時に正しく設定されていることを確認します。
詳細については、「リモート実行」セクションを参照してください。
リモート 実行
オープン MPI では、 パス リモートで実行可能ファイルを見つけるために環境変数を設定する必要があります
ノード (これは通常、次の場合にのみ必要です) rsh- または ssh-ベースの環境 --
バッチ/スケジュール環境は通常、現在の環境を実行環境にコピーします。
リモート ジョブなので、現在の環境に パス および LD_LIBRARY_PATH 適切に設定し、
リモート ノードでも適切に設定されます)。 Open MPI が共有でコンパイルされた場合
ライブラリのサポートも必要になる場合があります。 LD_LIBRARY_PATH 環境変数
リモート ノードにも設定します (特にユーザーの実行に必要な共有ライブラリを見つけるため)
MPI アプリケーション)。
ただし、シェル起動ファイルを編集して設定することが常に望ましいとは限らず、また可能であるとは限りません。 パス
および LD_LIBRARY_PATHを選択します。 --prefix いくつかの単純な構成のためにオプションが提供されています
それが不可能な場合。
当学校区の --prefix オプションは XNUMX つの引数を取ります。リモート ノードのベース ディレクトリです。
オープンMPIがインストールされています。 Open MPI はこのディレクトリを使用してリモートを設定します パス
LD_LIBRARY_PATH Open MPI またはユーザー アプリケーションを実行する前に。 これによりランニングが可能になります
事前設定を行わずに MPI ジョブを開く パス LD_LIBRARY_PATH リモートで
ノード。
Open MPI は、現在のノードの「bindir」(Open MPI が保存されているディレクトリ) のベース名を追加します。
実行可能ファイルがインストールされている) をプレフィックスに追加し、それを使用して パス リモートノード上で。
同様に、Open MPI は現在のノードの「libdir」(ディレクトリ
Open MPI のライブラリがインストールされている) をプレフィックスに追加し、それを使用して LD_LIBRARY_PATH
リモートノード上で。 例えば：
ローカルバインドディレクトリ: /local/node/directory/bin
ローカル libdir: /local/node/directory/lib64
次のコマンドラインが使用される場合:
% ompi-submit --prefix /remote/node/directory
Open MPI は、「/remote/node/directory/bin」を パス
試行する前に、「/remote/node/directory/lib64」をリモート ノードの D_LIBRARY_PATH に追加します。
何かを実行すること。
当学校区の --prefix リモート ノード上のインストール パスが次の場合、このオプションは十分ではありません。
ローカルノードとは異なります (例: "/ lib" はローカルノードで使用されますが、"/ lib64「です
リモート ノードで使用される)、またはインストール パスが
共通のプレフィックスの下にあるサブディレクトリ。
実行することに注意してください オムピ送信 絶対パス名を使用して指定することは、
--prefix 絶対パス名の最後のサブディレクトリを除く オムピ送信。 のために
例：
% /usr/local/bin/ompi-submit ...
に相当します
% ompi-submit --prefix / usr / local
輸出 環境 変数
OMPI_* の形式で名前が付けられたすべての環境変数は自動的にエクスポートされます。
ローカルノードとリモートノード上の新しいプロセスに適用されます。 環境パラメータも次のように指定できます。
MCAパラメータを使用して新しいプロセスに設定/転送されます。 mca_base_env_listを選択します。 -x
オプション オムピ送信 は非推奨になりましたが、MCA パラメータの構文は次のとおりです。
前の例。 一方、の構文は、 -x オプションと MCA パラメータにより、次の定義が可能になります。
新しい変数。これらのオプションのパーサーは現在あまり洗練されていないことに注意してください。
- 引用符で囲まれた値さえ理解できません。 ユーザーは変数を設定することをお勧めします。
環境を変更し、オプションを使用してそれらをエクスポートします。 それらを定義しないこと。
Setting MCA 技術パラメータ
当学校区の -mca スイッチを使用すると、さまざまな MCA (モジュラー コンポーネント) にパラメーターを渡すことができます。
アーキテクチャ) モジュール。 MCA モジュールは、MPI プログラムに直接影響を与えます。
実行時に設定する調整可能なパラメータ (どの BTL 通信デバイス ドライバを設定するかなど)
使用するか、その BTL に渡すパラメータなど)。
当学校区の -mca switchはXNUMXつの引数を取ります： を選択します。 一般的に議論
どの MCA モジュールが値を受け取るかを指定します。 たとえば、 「btl」が使用されます
MPI メッセージの転送に使用する BTL を選択します。 の 引数は
渡される値。 例えば：
ompi-submit -mca btl tcp,self -np 1 foo
「tcp」および「self」BTL を使用し、「foo」の単一コピーを実行するように Open MPI に指示します。
割り当てられたノード。
ompi-submit -mca btl self -np 1 foo
Open MPI に「self」BTL を使用し、割り当てられた「foo」の単一コピーを実行するように指示します。
ノード。
当学校区の -mca スイッチを複数回使用して、異なるものを指定できます および
引数。 同じ場合 複数回指定されている場合、 は連結されます
カンマ (",") で区切ります。
なお、 -mca switchは、環境変数を設定するための単なるショートカットです。 NS
同じ効果は、前に対応する環境変数を設定することによって達成される可能性があります
ランニング オムピ送信。 Open MPI が設定する環境変数の形式は次のとおりです。
OMPI_MCA_ =
マルサス、 -mca スイッチは、以前に設定された環境変数をオーバーライドします。 の -mca
設定も同様に、$OPAL_PREFIX/etc/openmpi-mca- で設定された MCA パラメーターをオーバーライドします。
params.conf または $HOME/.openmpi/mca-params.conf ファイル。
不明 引数は環境変数として設定されたままです -- チェックされません (
オムピ送信）正確さのために。 違法または不正確 引数はそうであるかもしれないし、そうでないかもしれない
報告されています -- それは特定の MCA モジュールに依存します。
MCA アーキテクチャで使用可能なコンポーネント タイプを見つけるには、または使用可能なコンポーネント タイプを見つけるには、
特定のコンポーネントのパラメータを使用するには、 ompi_info 指図。 を参照してください。 ompi_info(1) man
コマンドの詳細については、ページを参照してください。
Running: as ルート
Open MPI チームは、実行しないことを強く推奨します。 オムピ送信 root ユーザーとして。 MPI
アプリケーションは通常の (非 root) ユーザーとして実行する必要があります。
このアドバイスを反映して、ompi-submit はデフォルトで root としての実行を拒否します。 上書きするには
このデフォルトでは、 --allow-root として実行 オプションを オムピ送信 コマンドライン。
出口 status
何についての標準的な定義はありません オムピ送信 終了ステータスとして返される必要があります。
検討を重ねた結果、以下のような割り当て方法に落ち着きました。 オムピ
提出する 終了ステータス (注: 以下の説明では、「プライマリ」ジョブは初期ジョブです)
ompi-submit によって開始されたアプリケーション - そのジョブによって生成されたすべてのジョブが指定されます
「二次」ジョブ):
· プライマリ ジョブ内のすべてのプロセスが終了ステータス 0 で正常に終了した場合、0 を返します。
· プライマリ ジョブ内の XNUMX つ以上のプロセスがゼロ以外の終了で通常終了する場合
status では、MPI_COMM_WORLD ランクが最も低いプロセスの終了ステータスを返します。
ゼロ以外のステータスを持つ
· プライマリ ジョブ内のすべてのプロセスが終了ステータス 0 で正常に終了し、XNUMX または
二次ジョブ内のより多くのプロセスは通常、ゼロ以外の終了ステータスで終了します。
MPI_COMM_WORLD ランクが最も低いプロセスの終了ステータスを最下位で返します。
jobid をゼロ以外のステータスに設定し、(b) ジョブ ID の終了ステータスを要約したメッセージを出力します。
プライマリ ジョブとすべてのセカンダリ ジョブ。
· コマンド ライン オプション --report-child-jobs- Separately が設定されている場合、 -only- を返します。
プライマリジョブの終了ステータス。 二次ジョブのゼロ以外の終了ステータスは次のようになります。
概要の印刷ステートメントでのみ報告されます。
デフォルトでは、OMPI は MPI プロセスがゼロ以外の終了で終了したことを記録しメモします。
スターテス。 これは通常、「異常終了」とはみなされません。つまり、OMPI は異常終了を行いません。
XNUMX つ以上のプロセスがゼロ以外のステータスを返した場合、MPI ジョブを中止します。 代わりに、デフォルトの
この動作は単に、ゼロ以外のステータスで終了したプロセスの数を報告するだけです。
仕事の完了。
ただし、場合によっては、プロセスが終了したときにジョブを中止することが望ましい場合があります。
ゼロ以外のステータスで終了します。 たとえば、非 MPI ジョブは、次のような不正な結果を検出する可能性があります。
計算を中止したいが、コア ファイルは生成したくない。 または MPI ジョブ
MPI_Finalize の呼び出しを超えて続行する可能性がありますが、すべてのプロセスを中止する必要があることを示します
MPI 後の結果が原因です。
このような状況が頻繁に発生するとは予想されていません。 ただし、利益のために
より広範なコミュニティにサービスを提供するために、OMPI はユーザーがそれを指示できる手段を備えています。
ジョブは、プロセスがゼロ以外のステータスで終了すると中止されます。 MCAパラメータの設定
「orte_abort_on_non_zero_status」を 1 にすると、OMPI はすべてのプロセスを一度に中止します。
プロセス
ゼロ以外のステータスで終了します。
この方法で発生した終了は、コンソール上で「異常」として報告されます。
終了」。終了する最初のプロセスがその終了ステータスとともに識別されます。
例
上記のセクション全体の例も必ず参照してください。
ompi-submit -np 4 -mca btl ib、tcp、self prog1
MPI のトランスポートに「ib」、「tcp」、および「self」BTL を使用して prog4 の 1 つのコピーを実行します。
メッセージ。
ompi-submit -np 4 -mca btl tcp、sm、self
--mca btl_tcp_if_include eth0 prog1
MPI のトランスポートに「tcp」、「sm」、および「self」BTL を使用して prog4 の 1 つのコピーを実行します。
TCP は通信に eth0 インターフェイスのみを使用します。 他のBTLに注意してください
同様の if_include MCA パラメータがあります。
リターン VALUE
オムピ送信 すべてのプロセスが開始された場合、0 を返します。 オムピ送信 電話した後退出する
MPI_FINALIZE。 ompi-submit で内部エラーが発生した場合は、ゼロ以外の値が返されます。
または、MPI_FINALIZE を呼び出す前に XNUMX つ以上のプロセスが終了しました。 内部エラーの場合
ompi-submit で発生した場合は、対応するエラー コードが返されます。 その場合には、
MPI_FINALIZE (MPI_COMM_WORLD の戻り値) を呼び出す前に、XNUMX つ以上のプロセスが終了します。
プロセスのランク オムピ送信 最初の通知は MPI_FINALIZE を呼び出す前に無効になります。
返される。 一般に、これは停止した最初のプロセスですが、停止していないことに注意してください。
そうであることが保証されています。
onworks.net サービスを使用してオンラインで orte-submit を使用する
