mpiexec.openmpi - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

orterun, mpirun, mpiexec - Führen Sie serielle und parallele Jobs in Open MPI aus. oshrun, shmemrun
- Führen Sie serielle und parallele Jobs in Open SHMEM aus.

Hinweis: mpirun, mpiexec und Ortrun sind alle Synonyme füreinander sowie oschrun,
schemrun falls Open SHMEM installiert ist. Wenn Sie einen der Namen verwenden, wird das gleiche erzeugt
Verhalten.

ZUSAMMENFASSUNG

Single Process Multiple Data (SPMD)-Modell:

mpirun [ Optionen ] [ ]

Multiple Instruction Multiple Data (MIMD)-Modell:

mpirun [ globale_optionen ]
[ lokale_optionen1 ] [ ] :
[ lokale_optionen2 ] [ ] :
...:
[ lokale_optionenN ] [ ]

Beachten Sie, dass in beiden Modellen der Aufruf von mpirun über einen absoluten Pfadnamen ist äquivalent zu
Angabe der prefix Option mit a Wert, der dem Verzeichnis entspricht, in dem mpirun
residiert, abzüglich des letzten Unterverzeichnisses. Zum Beispiel:

% /usr/local/bin/mpirun ...

entspricht

% mpirun - Präfix Verzeichnis / usr / local

SCHNELL ZUSAMMENFASSUNG

Wenn Sie einfach nur suchen, wie eine MPI-Anwendung ausgeführt wird, möchten Sie wahrscheinlich a
Befehlszeile der folgenden Form:

% mpirun [ -np X ] [ --hostfile ]

Dadurch werden X Kopien von ausgeführt in Ihrer aktuellen Laufzeitumgebung (bei Ausführung unter
ein unterstützter Ressourcenmanager, Open MPI's mpirun verwendet normalerweise automatisch die
entsprechenden Ressourcenmanager-Prozessstarter, im Gegensatz zu beispielsweise rsh or ssh,
die die Verwendung einer Hostdatei erfordern oder standardmäßig alle X-Kopien auf dem
localhost), Scheduling (standardmäßig) im Round-Robin-Verfahren nach CPU-Steckplatz. Sehen Sie den Rest von
diese Seite für weitere Details.

Bitte beachten Sie, dass mpirun ab dem Start der v1.8-Serie automatisch Prozesse bindet.
In Ermangelung weiterer Anweisungen werden zwei Bindungsmuster verwendet:

Binden zu Ader: wenn die Anzahl der Prozesse <= 2 . ist

Binden zu Steckdose: wenn die Anzahl der Prozesse > 2 . ist

Wenn Ihre Anwendung Threads verwendet, möchten Sie wahrscheinlich sicherstellen, dass dies nicht der Fall ist
überhaupt gebunden (durch Angabe von --bind-to none) oder an mehrere Kerne gebunden mit an
entsprechendes Bindungsniveau oder bestimmte Anzahl von Verarbeitungselementen pro Anwendung
verarbeiten.

OPTIONAL

mpirun sendet den Namen des Verzeichnisses, in dem es auf dem lokalen Knoten aufgerufen wurde, an jeden
der entfernten Knoten und versuchen, in dieses Verzeichnis zu wechseln. Siehe "Aktuelle Arbeiten"
Verzeichnis" unten für weitere Details.

Das ausführbare Programm. Dies wird als erstes nicht erkanntes Argument identifiziert
zu mpirun.

Übergeben Sie diese Laufzeitargumente an jeden neuen Prozess. Das müssen immer die sein
letzte Argumente zu mpirun. Wenn eine App-Kontextdatei verwendet wird, wird sein
ignoriert.

-h, --help
Hilfe zu diesem Befehl anzeigen

-q, --ruhig
Unterdrücken Sie informative Nachrichten von orterun während der Anwendungsausführung.

-v, - ausführlich
Seien Sie ausführlich

-V, --Version
Versionsnummer drucken. Wenn keine anderen Argumente angegeben werden, führt dies ebenfalls zu
orterun zu verlassen.

-Anzeige-Karte, --Karte anzeigen
Zeigen Sie eine Tabelle mit den zugeordneten Standorten jedes Prozesses vor dem Start an.

-Anzeige-Entwicklung-Karte, --display-devel-map
Zeigen Sie eine detailliertere Tabelle an, die den zugeordneten Standort jedes Prozesses vorher anzeigt
zu starten (normalerweise für Entwickler von Interesse).

-Anzeige-Zuordnung, --display-allocation
Zeigt die erkannte Ressourcenzuordnung an.

Verwenden Sie eine der folgenden Optionen, um anzugeben, auf welchen Hosts (Knoten) des Clusters ausgeführt werden soll.
Beachten Sie, dass mpirun ab dem Start der Version 1.8 einen Daemon auf jedem Host startet
in der Zuweisung (wie durch die folgenden Optionen geändert) ganz am Anfang von
Ausführung, unabhängig davon, ob Bewerbungsprozesse letztendlich auf . abgebildet werden oder nicht
dort ausführen. Dies geschieht, um das Sammeln von Informationen zur Hardware-Topologie aus dem
entfernte Knoten, wodurch wir Prozesse anhand bekannter Topologien abbilden können. Es ist jedoch ein
Änderung gegenüber dem Verhalten in früheren Releases, bei denen Daemons erst nach dem Mapping gestartet wurden
war abgeschlossen und trat daher nur auf Knoten auf, auf denen Anwendungsprozesse tatsächlich stattfinden würden
ausgeführt werden.

-H, -Wirt, --Gastgeber
Liste der Hosts, auf denen Prozesse aufgerufen werden sollen.

-hostdatei, --Hostdatei
Geben Sie eine zu verwendende Hostdatei an.

-Maschinendatei, --machinefile
Synonym für -hostdatei.

-CPU-Satz, --cpu-set
Beschränken Sie gestartete Prozesse auf die angegebenen logischen CPUs auf jedem Knoten. Beachten Sie, dass
die Bindungsoptionen gelten weiterhin innerhalb des angegebenen Umschlags - z. B. können Sie
Wählen Sie, um jeden Prozess nur an eine CPU innerhalb des angegebenen CPU-Sets zu binden.

Die folgenden Optionen geben die Anzahl der zu startenden Prozesse an. Beachten Sie, dass keiner der
Optionen implizieren eine bestimmte Bindungsrichtlinie - z. B. das Anfordern von N Prozessen für jeden Socket
bedeutet nicht, dass die Prozesse an den Socket gebunden werden.

-c, -n, --N, -np <#>
Führen Sie so viele Kopien des Programms auf den angegebenen Knoten aus. Diese Option zeigt an, dass
die angegebene Datei ist ein ausführbares Programm und kein Anwendungskontext. Wenn nein
Wert wird für die Anzahl der auszuführenden Kopien angegeben (dh weder "-np" noch
seine Synonyme werden auf der Befehlszeile bereitgestellt), Open MPI wird automatisch ausgeführt
eine Kopie des Programms auf jedem Prozessplatz (siehe unten für die Beschreibung eines "Prozesses"
Steckplatz"). Diese Funktion kann jedoch nur im SPMD-Modell verwendet werden und kehrt zurück
ein Fehler (ohne die Ausführung der Anwendung zu beginnen) andernfalls.

—map-by ppr:N:
Starten Sie N-mal die Anzahl der Objekte des angegebenen Typs auf jedem Knoten.

-nperSteckdose, --npersocket <#persocket>
Starten Sie auf jedem Knoten so viele Prozesse mal die Anzahl der Prozessorsockel auf
der Knoten. Die -nperSteckdose Option schaltet auch die -Binde-an-Buchse .
(veraltet zugunsten von --map-by ppr:n:socket)

-npernode, --npernode <#pernode>
Starten Sie auf jedem Knoten so viele Prozesse. (veraltet zugunsten von --map-by
ppr:n:Knoten)

-pernode, --pernode
Starten Sie auf jedem Knoten einen Prozess – äquivalent zu -npernode 1. (veraltet in
zugunsten von --map-by ppr:1:node)

Um Prozesse abzubilden:

--map-by
Dem angegebenen Objekt zuordnen, standardmäßig auf Buchse. Zu den unterstützten Optionen gehören Steckplatz,
hwthread, core, L1cache, L2cache, L3cache, socket, numa, board, node, sequentiell,
Entfernung und pp. Jedes Objekt kann Modifikatoren enthalten, indem ein : und any . hinzugefügt wird
Kombination von PE=n (bindet n Verarbeitungselemente an jeden Prozess), SPAN (Lastausgleich
die Prozesse über die Zuweisung), OVERSUBSCRIBE (mehr Prozesse auf einem Knoten zulassen
als Verarbeitungselemente) und NOOVERSUBSCRIBE. Dazu gehört PPR, bei dem die
Muster würde durch einen weiteren Doppelpunkt beendet, um es von den Modifikatoren zu trennen.

-bycore, --bycore
Prozesse nach Kern zuordnen (veraltet zugunsten von --map-by core)

-bysocket, --bysocket
Prozesse nach Socket zuordnen (veraltet zugunsten von --map-by socket)

-nolokal, - nolocal
Führen Sie keine Kopien der gestarteten Anwendung auf demselben Knoten wie orterun aus
Laufen. Diese Option überschreibt das Auflisten des localhost mit --Gastgeber oder irgend ein anderer
Host-spezifizierter Mechanismus.

-nooversubscribe, --nooversubscribe
Überzeichnen Sie keine Knoten; Fehler (ohne irgendwelche Prozesse zu starten), wenn die
angeforderte Anzahl von Prozessen würde eine Überbelegung verursachen. Diese Option implizit
setzt "max_slots" gleich dem "slots"-Wert für jeden Knoten.

-bynode, --bynode
Starten Sie einen Prozess pro Knoten und durchlaufen Sie ihn im Round-Robin-Verfahren. Dies
verteilt Prozesse gleichmäßig auf die Knoten und weist MPI_COMM_WORLD Ränge in einer Runde zu.
Robin, "nach Knoten".

Um die Ränge von Prozessen in MPI_COMM_WORLD zu bestellen:

--Rang-nach
Rang im Round-Robin-Verfahren gemäß dem angegebenen Objekt, standardmäßig auf Schloß.
Zu den unterstützten Optionen gehören Slot, Hwthread, Core, L1cache, L2cache, L3cache, Socket,
numa, Board und Node.

Für Prozessbindung:

--zu binden
Bindet Prozesse an das angegebene Objekt, standardmäßig auf Core. Zu den unterstützten Optionen gehören
Slot, Hwthread, Core, l1Cache, l2Cache, l3Cache, Socket, Numa, Board und keine.

-cpus-pro-proc, --cpus-per-proc <#perproc>
Binden Sie jeden Prozess an die angegebene Anzahl von CPUs. (veraltet zugunsten von --map-
von :PE=n)

-cpus-pro-rank, --cpus-per-rank <#perrank>
Alias ​​für -cpus-pro-proc. (veraltet zugunsten von --map-by :PE=n)

-an-Kern binden, --bind-to-core
Binden von Prozessen an Kerne (veraltet zugunsten von --bind-to core)

-Binde-an-Buchse, --bind-to-socket
Binden von Prozessen an Prozessorsockets (veraltet zugunsten von --bind-to socket)

-an-nichts binden, --bind-to-none
Prozesse nicht binden (veraltet zugunsten von --bind-to none)

-Berichtsbindungen, --report-bindings
Melden Sie alle Bindungen für gestartete Prozesse.

-Slot-Liste, --Slot-Liste
Liste der Prozessor-IDs, die zum Binden von MPI-Prozessen verwendet werden sollen. Die angegebenen Bindungen
wird auf alle MPI-Prozesse angewendet. Siehe Erläuterung unten für Syntax.

Für Ranglisten:

-R F, --rankfile
Stellen Sie eine Rangdatei-Datei bereit.

So verwalten Sie Standard-E/A:

-Name der Ausgabedatei, --Name der Ausgabedatei
Leiten Sie stdout, stderr und stddiag aller Prozesse auf einen eindeutigen Prozess um
Version des angegebenen Dateinamens. Alle Verzeichnisse im Dateinamen werden
automatisch erstellt werden. Jede Ausgabedatei besteht aus filename.id, wobei die
id ist der Rang des Prozesses in MPI_COMM_WORLD, links aufgefüllt mit Nullen für
richtige Reihenfolge in Listen.

-stdin, --stdin
Der MPI_COMM_WORLD-Rang des Prozesses, der stdin empfangen soll. Die Standardeinstellung ist zu
stdin an MPI_COMM_WORLD Rang 0 weiterleiten, aber diese Option kann zum Weiterleiten verwendet werden
stdin zu einem beliebigen Prozess. Es ist auch akzeptabel, anzugeben keine, was darauf hinweist, dass nein
Prozesse sollen stdin erhalten.

-Tag-Ausgabe, --tag-ausgabe
Markieren Sie jede Ausgabezeile mit stdout, stderr und stddiag mit [Job-ID,
MCW_Rang] Angabe der Prozess-Job-ID und des MPI_COMM_WORLD-Rangs des
Prozess, der die Ausgabe generiert hat, und der Kanal, der sie generiert hat.

-Zeitstempel-Ausgabe, --timestamp-output
Versehen Sie jede Ausgabezeile mit einem Zeitstempel mit stdout, stderr und stddiag.

-xml, --xml
Stellen Sie alle Ausgaben für stdout, stderr und stddiag im XML-Format bereit.

-xterm, --xterm
Zeigen Sie die Ausgabe der Prozesse an, die durch ihre MPI_COMM_WORLD-Ränge identifiziert werden
separate xterm-Fenster. Die Ränge werden als durch Kommas getrennte Liste von angegeben
Bereiche, wobei eine -1 alle anzeigt. Für jede wird ein eigenes Fenster erstellt
angegebenen Prozess. Hinweis: xterm beendet normalerweise das Fenster bei Beendigung
des darin ablaufenden Prozesses. Durch Hinzufügen eines "!" bis zum Ende der Liste
der angegebenen Ränge werden die richtigen Optionen bereitgestellt, um sicherzustellen, dass xterm
das fenster offen nachdem Der Prozess wird beendet, sodass Sie den Prozess sehen können.'
Ausgang. Jedes xterm-Fenster muss anschließend manuell geschlossen werden. Hinweis: In
In einigen Umgebungen kann es für xterm erforderlich sein, dass sich die ausführbare Datei im Pfad des Benutzers befindet, oder
absolut oder relativ angegeben werden. Daher kann es notwendig sein, a . anzugeben
lokale ausführbare Datei als "./foo" statt nur "foo". Wenn xterm die nicht findet
ausführbare Datei, bleibt mpirun hängen, reagiert aber immer noch korrekt auf ein Strg-C. Wenn das
passiert, überprüfen Sie bitte, ob die ausführbare Datei richtig angegeben ist und versuchen Sie es
erneut.

So verwalten Sie Dateien und Laufzeitumgebung:

-Pfad, --Weg
die verwendet wird, wenn versucht wird, die angeforderten ausführbaren Dateien zu finden. Dies
wird vor der Verwendung der lokalen PATH-Einstellung verwendet.

prefix
Präfix-Verzeichnis, das verwendet wird, um die PATH und LD_LIBRARY_PATH auf die
entfernten Knoten, bevor Sie Open MPI oder den Zielprozess aufrufen. Siehe "Fernbedienung"
Ausführung" unten.

--preload-binär
Kopieren Sie die angegebene(n) ausführbare(n) Datei(en) auf Remote-Rechner, bevor Sie Remote starten
Prozesse. Die ausführbaren Dateien werden in das Open MPI-Sitzungsverzeichnis kopiert und
werden nach Beendigung des Auftrags gelöscht.

--preload-Dateien
Laden Sie die durch Kommas getrennte Dateiliste vorab in das aktuelle Arbeitsverzeichnis des
Remote-Maschinen, auf denen Prozesse gestartet werden, bevor diese Prozesse gestartet werden.

--preload-files-dest-dir
Das für Preload-Dateien zu verwendende Zielverzeichnis, falls nicht das aktuelle
Arbeitsverzeichnis. Standardmäßig werden die absoluten und relativen Pfade bereitgestellt von
--preload-Dateien werden verwendet.

--tmpdir
Legen Sie das Stammverzeichnis für den Sitzungsverzeichnisbaum nur für mpirun fest.

-wd
Synonym für -wdir.

-wdir
Wechseln Sie in das Verzeichnis bevor das Programm des Benutzers ausgeführt wird. Siehe "Aktuelles"
Arbeitsverzeichnis" für Hinweise zu relativen Pfaden. Hinweis: Besitzt das -wdir zu erhalten
erscheint sowohl in der Befehlszeile als auch in einem Anwendungskontext, der Kontext wird
haben Vorrang vor der Befehlszeile. Ist der Pfad zum gewünschten wdir also
auf den Backend-Knoten unterschiedlich, dann muss als absoluter Pfad angegeben werden, dass
ist für den Backend-Knoten richtig.

-x
Exportieren Sie die angegebenen Umgebungsvariablen in die Remote-Knoten, bevor Sie die
Programm. Es kann nur eine Umgebungsvariable pro angegeben werden -x Möglichkeit. Bestehende
Mit . können Umgebungsvariablen angegeben oder neue Variablennamen angegeben werden
entsprechende Werte. Zum Beispiel:
% mpirun -x ANZEIGE -x OFILE=/tmp/out ...

Der Parser für die -x Option ist nicht sehr anspruchsvoll; es versteht nicht einmal
zitierte Werte. Benutzern wird empfohlen, Variablen in der Umgebung festzulegen und dann zu verwenden
-x um sie zu exportieren (nicht zu definieren).

MCA-Parameter einstellen:

-gmca, --gmca
Übergeben Sie globale MCA-Parameter, die für alle Kontexte gelten. lernen muss die
Parametername; ist der Parameterwert.

-mca, --mca
Senden Sie Argumente an verschiedene MCA-Module. Siehe den Abschnitt "MCA" unten.

Zum Debuggen:

-debuggen, --debuggen
Rufen Sie den Debugger auf Benutzerebene auf, der durch das angezeigt wird orte_base_user_debugger MCA
Parameters.

-Debugger, - Debugger
Abfolge von Debuggern, nach denen gesucht werden soll --debuggen verwendet wird (dh ein Synonym für
orte_base_user_debugger MCA-Parameter).

-Fernseher, --Fernseher
Starten Sie Prozesse unter dem TotalView-Debugger. Abwärtskompatibilität eingestellt
Flagge. Synonym für --debuggen.

Es gibt auch andere Möglichkeiten:

--allow-run-as-root
Erlauben mpirun ausführen, wenn sie vom Root-Benutzer ausgeführt werden (mpirun Standardmäßig wird abgebrochen
beim Start als Root-Benutzer).

-abgebrochen, --abgebrochen <#>
Legen Sie die maximale Anzahl der anzuzeigenden abgebrochenen Prozesse fest.

- App
Geben Sie eine App-Datei an und ignorieren Sie alle anderen Befehlszeilenoptionen.

-vgl, --cartofile
Stellen Sie eine Kartografiedatei bereit.

--Hetero
Zeigt an, dass mehrere app_contexts bereitgestellt werden, die eine Mischung aus 32/64-Bit sind
Binärdateien.

-Leave-Session-Attached, --leave-session-attached
Trennen Sie die von dieser Anwendung verwendeten OmpiRTE-Daemons nicht. Dies ermöglicht Fehlermeldungen
sowohl von den Daemons als auch von der zugrunde liegenden Umgebung (z
einen Daemon starten) ausgegeben werden.

-ompi-server, --ompi-server <uri or Datei>
Geben Sie die URI des Open MPI-Servers (oder des als Server zu verwendenden mpiruns) an,
der Name der Datei (angegeben als Datei:Dateiname), die diese Informationen enthält, oder die
PID (angegeben als pid:#) des zu verwendenden Mpiruns
der Kellner. Der Open MPI-Server wird verwendet, um Multi-Application-Daten zu unterstützen
Austausch über die Funktionen MPI-2 MPI_Publish_name und MPI_Lookup_name.

-report-pid, --report-pid
Drucken Sie die PID von mpirun während des Startvorgangs aus. Der Kanal muss entweder ein '-' sein, um anzugeben
kat, dass die pid auf stdout ausgegeben werden soll, ein '+' um anzuzeigen, dass die pid auf
nach stderr ausgegeben werden, oder ein Dateiname, in den die pid geschrieben werden soll.

-bericht-uri, --report-uri
Drucken Sie die URI von mpirun während des Startvorgangs aus. Der Kanal muss entweder ein '-' sein, um anzugeben
kat, dass die URI auf stdout ausgegeben werden soll, ein '+' um anzuzeigen, dass die URI auf
nach stderr ausgegeben werden, oder ein Dateiname, in den die URI geschrieben werden soll.

-warten-auf-server, --wait-for-server
Halten Sie mpirun an, bevor Sie den Job starten, bis ompi-server erkannt wird. Das ist nützlich
in Skripten, bei denen ompi-server im Hintergrund gestartet werden kann, sofort gefolgt
durch eine mpirun Befehl, der eine Verbindung herstellen möchte. Mpirun wird pausieren, bis entweder
der angegebene ompi-server wird kontaktiert oder die Server-Wartezeit ist überschritten.

-Server-Wartezeit, --server-wartezeit
Die maximale Zeit (in Sekunden), die mpirun warten sollte, bis der ompi-Server
Anfang. Der Standardwert beträgt 10 Sekunden.

Die folgenden Optionen sind für Entwickler nützlich; Sie sind für die meisten im Allgemeinen nicht nützlich
ORTE- und/oder MPI-Benutzer:

-d, --debug-devel
Aktivieren Sie das Debuggen von OmpiRTE (der Laufzeitschicht in Open MPI). Das ist nicht
im Allgemeinen für die meisten Benutzer nützlich.

--debug-daemons
Aktivieren Sie das Debuggen aller OmpiRTE-Daemons, die von dieser Anwendung verwendet werden.

--debug-daemons-Datei
Aktivieren Sie das Debuggen aller OmpiRTE-Daemons, die von dieser Anwendung verwendet werden, und speichern Sie die Ausgabe in
Dateien.

-Launch-Agent, --Launch-Agent
Name der ausführbaren Datei, die zum Starten von Prozessen auf den entfernten Knoten verwendet werden soll.
Die Vorgabe ist "ortiert". Diese Option kann verwendet werden, um neue Daemon-Konzepte zu testen oder um
Optionen an die Daemons zurückgeben, ohne dass mpirun sie selbst sieht. Zum
Wenn Sie beispielsweise einen Startagenten von orted -mca odls_base_verbose 5 angeben, können Sie
Entwickler, um die Ausgabe von orted ohne Unordnung von mpirun selbst zu debuggen.

--noprefix
Deaktivieren Sie das automatische --prefix-Verhalten

Möglicherweise sind andere Optionen mit aufgeführt mpirun --help.

Arbeitsumfeld Variablen
MPIEXEC_TIMEOUT
Die maximale Anzahl von Sekunden, die mpirun (mpiexec) werde rennen. Nach so vielen
Sekunden mpirun wird den gestarteten Job abbrechen und beenden.

BESCHREIBUNG

Ein Aufruf von mpirun startet eine MPI-Anwendung, die unter Open MPI ausgeführt wird. Wenn die
Anwendung ist Single Process Multiple Data (SPMD), die Anwendung kann auf angegeben werden
mpirun Befehlszeile.

Wenn es sich bei der Anwendung um Multiple Instruction Multiple Data (MIMD) handelt, bestehend aus mehreren
Programme können die Programmmenge und das Argument auf zwei Arten angegeben werden: Erweitert
Befehlszeilenargumente und Anwendungskontext.

Ein Anwendungskontext beschreibt den MIMD-Programmsatz einschließlich aller Argumente in a
separate Datei. Diese Datei enthält im Wesentlichen mehrere mpirun Befehlszeilen, weniger die
Befehlsname selbst. Die Möglichkeit, verschiedene Optionen für verschiedene . anzugeben
Instanziierungen eines Programms ist ein weiterer Grund, einen Anwendungskontext zu verwenden.

Erweiterte Befehlszeilenargumente ermöglichen die Beschreibung des Anwendungslayouts auf dem
Befehlszeile mit Doppelpunkten (:), um die Spezifikation von Programmen und Argumenten zu trennen.
Einige Optionen werden global für alle angegebenen Programme gesetzt (zB --hostfile), während
andere sind spezifisch für ein einzelnes Programm (zB -np).

Angeben Gastgeber Nodes
Hostknoten können auf dem . identifiziert werden mpirun Kommandozeile mit dem -Wirt Option oder in a
Hostdatei.

Zum Beispiel,

mpirun -H aa,aa,bb ./a.out
startet zwei Prozesse auf Knoten aa und einen auf bb.

Oder betrachten Sie die Hostdatei

% Katze myhostfile
aa-Slots=2
bb-Slots = 2
CC-Steckplätze = 2

Hier listen wir sowohl die Hostnamen (aa, bb und cc) als auch die Anzahl der "Slots" auf
jede einzelne. Slots geben an, wie viele Prozesse potenziell auf einem Knoten ausgeführt werden können. Für das Beste
Leistung, die Anzahl der Steckplätze kann so gewählt werden, dass sie der Anzahl der Kerne auf dem Knoten entspricht oder
die Anzahl der Prozessorsockel. Wenn die Hostdatei keine Slot-Informationen bereitstellt, a
Standardwert von 1 wird angenommen. Bei Ausführung unter Ressourcenmanagern (z. B. SLURM, Torque,
etc.), erhält Open MPI sowohl die Hostnamen als auch die Anzahl der Slots direkt vom
Ressourcenmanager bzw.

mpirun -hostfile myhostfile ./a.out
startet zwei Prozesse auf jedem der drei Knoten.

mpirun -hostfile myhostfile -host aa ./a.out
startet zwei Prozesse, beide auf Knoten aa.

mpirun -hostfile myhostfile -host dd ./a.out
findet keine Hosts zum Ausführen und bricht mit einem Fehler ab. Das heißt, der angegebene Host dd
ist nicht in der angegebenen Hostdatei.

Angeben Nummer of Prozesse
Wie wir gerade gesehen haben, kann die Anzahl der auszuführenden Prozesse mithilfe der Hostdatei eingestellt werden. Sonstiges
Mechanismen bestehen.

Die Anzahl der gestarteten Prozesse kann als Vielfaches der Anzahl der Knoten angegeben werden oder
Prozessorsockel verfügbar. Zum Beispiel,

mpirun -H aa,bb -npersocket 2 ./a.out
startet Prozesse 0-3 auf Knoten aa und Prozess 4-7 auf Knoten bb, wobei aa und bb beides sind
Dual-Socket-Knoten. Die -nperSteckdose Option schaltet auch die -Binde-an-Buchse Option,
was in einem späteren Abschnitt besprochen wird.

mpirun -H aa,bb -npernode 2 ./a.out
startet die Prozesse 0-1 auf Knoten aa und Prozesse 2-3 auf Knoten bb.

mpirun -H aa,bb -npernode 1 ./a.out
startet einen Prozess pro Hostknoten.

mpirun -H aa,bb -pernode ./a.out
ist die gleiche wie -npernode 1.

Eine andere Alternative ist die Angabe der Anzahl der Prozesse mit dem -np Möglichkeit. Erwägen
jetzt die hostfile

% Katze myhostfile
aa-Slots=4
bb-Slots = 4
CC-Steckplätze = 4

Jetzt,

mpirun -hostfile myhostfile -np 6 ./a.out
startet die Prozesse 0-3 auf dem Knoten aa und die Prozesse 4-5 auf dem Knoten bb. Der Rest
Slots in der Hostdatei werden nicht verwendet, da die -np Option zeigte an, dass nur 6
Prozesse eingeleitet werden sollen.

Mapping Prozesse zu Nodes: Die richtigen Richtlinien
Die obigen Beispiele veranschaulichen die Standardzuordnung von Prozessprozessen zu Knoten. Dies
Mapping kann auch mit verschiedenen mpirun Optionen, die Zuordnungsrichtlinien beschreiben.

Betrachten Sie dieselbe Hostdatei wie oben, wieder mit -np 6:

Knoten aa Knoten bb Knoten cc

mpirun 0 1 2 3 4 5

mpirun --map-by-Knoten 0 3 1 4 2 5

mpirun -nolokal 0 1 2 3 4 5

Die --map-by Knoten Option wird die Prozesse auf die verfügbaren Knoten verteilen,
Nummerierung jedes Prozesses in einer Round-Robin-Weise.

Die -nolokal verhindert, dass Prozesse auf dem lokalen Host abgebildet werden (in diesem
Fallknoten aa). Während mpirun verbraucht normalerweise nur wenige Systemressourcen, -nolokal kann sein
hilfreich beim Starten sehr großer Aufträge, bei denen mpirun kann tatsächlich auffällig gebrauchen
Speicher und/oder Verarbeitungszeit.

Ebenso -np kann weniger Prozesse spezifizieren, als Slots vorhanden sind, es kann auch überschreiben
die Schlitze. Zum Beispiel mit derselben Hostdatei:

mpirun -hostfile myhostfile -np 14 ./a.out
startet die Prozesse 0-3 auf Knoten aa, 4-7 auf bb und 8-11 auf cc. Es wird dann die hinzufügen
die verbleibenden zwei Prozesse an einen beliebigen Knoten weiterleiten.

Es können auch Grenzen für die Überzeichnung festgelegt werden. Zum Beispiel mit derselben Hostdatei:

mpirun -hostfile myhostfile -np 14 -nooversubscribe ./a.out
wird einen Fehler erzeugen, da -nooversubscribe verhindert eine Überbelegung.

Grenzen für die Überzeichnung können auch in der Hostdatei selbst angegeben werden:
% cat myhostfile
aa Slots=4 max_slots=4
bbmax_slots=4
CC-Steckplätze = 4

Die max_slots Feld gibt eine solche Grenze an. Wenn dies der Fall ist, Slots Standardwert ist der
Grenze. Jetzt:

mpirun -hostfile myhostfile -np 14 ./a.out
bewirkt, dass die ersten 12 Prozesse wie zuvor gestartet werden, aber die restlichen zwei
Prozesse werden auf den Knoten cc gezwungen. Die anderen beiden Knoten werden durch die
hostfile gegen Überbelegung durch diesen Job.

Verwendung der --nooversubscribe Option kann hilfreich sein, da Open MPI derzeit nicht
"max_slots"-Werte aus dem Ressourcenmanager.

Natürlich -np kann auch mit verwendet werden -H or -Wirt Möglichkeit. Beispielsweise,

mpirun -H aa,bb -np 8 ./a.out
startet 8 Prozesse. Da nur zwei Hosts angegeben sind, werden nach den ersten beiden
Prozesse werden abgebildet, einer auf aa und einer auf bb, die restlichen Prozesse überzeichnen
die angegebenen Hosts.

Und hier ist ein MIMD-Beispiel:

mpirun -H aa -np 1 Hostname : -H bb,cc -np 2 Betriebszeit
startet Prozess 0 läuft hostname auf Knoten aa und Prozesse 1 und 2 laufen jeweils
Betriebszeit auf den Knoten bb bzw. cc.

Mapping, Rangfolge, und Binding: Oh Mein!
Open MPI verwendet ein dreistufiges Verfahren zur Vergabe von Prozessstandorten und -rängen:

Mapping Weist jedem Prozess einen Standardspeicherort zu

Rang Weist jedem Prozess einen MPI_COMM_WORLD-Rangwert zu

Bindung Beschränkt jeden Prozess auf die Ausführung auf bestimmten Prozessoren

Die Mapping Schritt wird verwendet, um jedem Prozess basierend auf dem Mapper einen Standardstandort zuzuweisen
angestellt sein. Die Zuordnung nach Steckplatz, Knoten und sequentiell ergibt die Zuweisung der
Prozesse auf Knotenebene. Im Gegensatz dazu ermöglicht das Mapping nach Objekt dem Mapper die Zuweisung
den Prozess zu einem tatsächlichen Objekt auf jedem Knoten.

Hinweis: der dem Prozess zugewiesene Ort ist unabhängig davon, wohin er gebunden wird - die
Die Zuweisung wird ausschließlich als Eingabe für den Bindungsalgorithmus verwendet.

Die Abbildung von Prozessprozessen auf Knoten kann nicht nur mit allgemeinen Richtlinien definiert werden
aber ggf. auch mit beliebigen Abbildungen, die nicht durch ein einfaches
Politik. Man kann den "sequentiellen Mapper" verwenden, der die Hostdatei zeilenweise ausliest,
Zuweisen von Prozessen zu Knoten in beliebiger Reihenfolge, die die Hostdatei vorgibt. Verwenden Sie die -mca Rmaps
ff Möglichkeit. Verwenden Sie beispielsweise dieselbe Hostdatei wie zuvor:

mpirun -hostfile myhostfile -mca rmaps seq ./a.out

startet drei Prozesse, einen auf jedem der Knoten aa, bb bzw. cc. Der Schlitz
zählt nicht; ein Prozess wird pro Zeile auf jedem Knoten gestartet, der auf der Liste aufgeführt ist
Linie.

Eine andere Möglichkeit, beliebige Zuordnungen anzugeben, ist die Verwendung einer Rangdatei, die Ihnen detaillierte
auch die Kontrolle über die Prozessbindung. Rankfiles werden weiter unten besprochen.

Die zweite Phase konzentriert sich auf die Rang des Prozesses innerhalb der MPI_COMM_WORLD des Jobs.
Open MPI trennt dies von der Mapping-Prozedur, um mehr Flexibilität in der zu ermöglichen
relative Platzierung von MPI-Prozessen. Dies lässt sich am besten veranschaulichen, wenn man Folgendes bedenkt:
zwei Fälle, in denen wir die Option —map-by ppr:2:socket verwendet haben:

Knoten aa Knoten bb

Rang nach Kern 0 1 ! 2 3 4 5 ! 6 7

Rang-by-Sockel 0 2 ! 1 3 4 6 ! 5 7

Rang-by-Socket: Span 0 4 ! 1 5 2 6 ! 3 7

Das Ranking nach Kern und Slot liefert das gleiche Ergebnis - eine einfache Progression von
MPI_COMM_WORLD rangiert für jeden Knoten. Das Ranking nach Socket führt zu einem Round-Robin-Ranking innerhalb von
jedem Knoten, bis allen Prozessen ein MCW-Rang zugewiesen wurde, und geht dann zum
nächster Knoten. Hinzufügen der Spannweite Modifikator der Rangordnungsdirektive bewirkt den Rangordnungsalgorithmus
die gesamte Zuweisung als eine Einheit zu behandeln - somit werden die MCW-Ränge zugewiesen
über alle Steckdosen, bevor Sie wieder zum Anfang kreisen.

Die Bindung Phase bindet tatsächlich jeden Prozess an einen bestimmten Satz von Prozessoren. Das kann
die Leistung zu verbessern, wenn das Betriebssystem Prozesse suboptimal platziert. Zum
Beispielsweise könnte es einige Multi-Core-Prozessor-Sockel überbeanspruchen, so dass andere Sockel übrig bleiben
Leerlauf; Dies kann dazu führen, dass Prozesse unnötigerweise um gemeinsame Ressourcen kämpfen. Oder es
könnte Prozesse zu weit ausbreiten; Dies kann suboptimal sein, wenn die Anwendungsleistung
ist empfindlich gegenüber Interprozesskommunikationskosten. Bindung kann auch den Betrieb halten
System davon ab, Prozesse übermäßig zu migrieren, unabhängig davon, wie optimal diese Prozesse sind
wurden zunächst platziert.

Die für die Bindung zu verwendenden Prozessoren können anhand topologischer Gruppierungen identifiziert werden
- zB bindet an einen l3cache jeden Prozess an alle Prozessoren im Rahmen von
einen einzelnen L3-Cache innerhalb ihres zugewiesenen Speicherorts. Wenn also ein Prozess von der
Mapper auf einen bestimmten Socket, dann a -zu binden l3cache Direktive bewirkt, dass der Prozess
an die Prozessoren gebunden, die sich einen einzelnen L3-Cache innerhalb dieses Sockels teilen.

Um Lasten auszugleichen, verwendet die Binding-Direktive eine Round-Robin-Methode beim Binden an
Ebenen niedriger als im Mapper verwendet. Betrachten Sie zum Beispiel den Fall, in dem ein Job zugeordnet ist
auf Socket-Ebene und dann an Core gebunden. Jeder Sockel hat mehrere Kerne, also wenn
Mehrere Prozesse werden einem bestimmten Socket zugeordnet, der Bindungsalgorithmus weist jeden zu
Prozess, der sich in einem Round-Robin-Verfahren an einem Socket zu einem eindeutigen Kern befindet.

Alternativ werden Prozesse, die von l2cache gemappt und dann an Socket gebunden werden, einfach gebunden
an alle Prozessoren in dem Sockel, in dem sie sich befinden. Auf diese Weise können Benutzer
eine detaillierte Kontrolle über die relative Position und Bindung des MCW-Rangs ausüben.

Schließlich --report-bindings kann verwendet werden, um Bindungen zu melden.

Betrachten Sie als Beispiel einen Knoten mit zwei Prozessorsockeln, die jeweils vier Kerne umfassen. Wir
Lauf mpirun mit -np 4 --report-bindings und die folgenden zusätzlichen Optionen:

% mpirun ... --map-by core --bind-to core
[...] ... Kind [...,0] an CPU 0001 binden
[...] ... Kind [...,1] an CPU 0002 binden
[...] ... Kind [...,2] an CPU 0004 binden
[...] ... Kind [...,3] an CPU 0008 binden

% mpirun ... --map-by socket --bind-to socket
[...] ... Bindung von Kind [...,0] an Sockel 0 CPU 000f
[...] ... Kind [...,1] an Sockel 1 CPU binden 00f0
[...] ... Bindung von Kind [...,2] an Sockel 0 CPU 000f
[...] ... Kind [...,3] an Sockel 1 CPU binden 00f0

% mpirun ... --map-by core:PE=2 --bind-to core
[...] ... Kind [...,0] an CPU 0003 binden
[...] ... Bindung von Kind [...,1] an CPU 000c
[...] ... Kind [...,2] an CPU 0030 binden
[...] ... Kind [...,3] an CPU binden 00c0

% mpirun ... --bind-to-none

Hier --report-bindings zeigt die Bindung jedes Prozesses als Maske an. Im ersten Fall,
die Prozesse binden an aufeinanderfolgende Kerne, wie durch die Masken 0001, 0002, 0004 angezeigt, und
0008. Im zweiten Fall binden Prozesse an alle Kerne auf aufeinanderfolgenden Sockets, wie angegeben
durch die Masken 000f und 00f0. Die Prozesse durchlaufen die Prozessorsockel im Rundlauf.
Robin Fashion so oft wie nötig. Im dritten Fall zeigen uns die Masken, dass 2
Kerne wurden pro Prozess gebunden. Im vierten Fall wird die Bindung ausgeschaltet und nein
Bindungen werden gemeldet.

Die Unterstützung von Open MPI für die Prozessbindung hängt vom zugrunde liegenden Betriebssystem ab.
Daher sind bestimmte Prozessbindungsoptionen möglicherweise nicht auf jedem System verfügbar.

Die Prozessbindung kann auch mit MCA-Parametern eingestellt werden. Ihre Verwendung ist weniger bequem als
dass von mpirun Optionen. Andererseits können MCA-Parameter nicht nur auf dem
mpirun Befehlszeile, aber alternativ in einer System- oder Benutzerdatei mca-params.conf oder als
Umgebungsvariablen, wie im Abschnitt MCA unten beschrieben. Einige Beispiele sind:

mpirun-Option MCA-Parameterschlüsselwert

--map-by Kern rmaps_base_mapping_policy Kern
--map-by-Socket rmaps_base_mapping_policy-Socket
--rank-by Kern rmaps_base_ranking_policy Kern
--bind-to-Kern hwloc_base_binding_policy-Kern
--bind-to-Socket hwloc_base_binding_policy-Socket
--bind-to keine hwloc_base_binding_policy keine

Rangdateien
Rankfiles sind Textdateien, die detaillierte Informationen darüber angeben, wie einzelne Prozesse
Knoten zugeordnet werden sollen und an welche(n) Prozessor(en) sie gebunden werden sollen. Jede Zeile von a
rankfile gibt den Speicherort eines Prozesses an (bei MPI-Jobs bezieht sich der "Rang" des Prozesses auf
auf seinen Rang in MPI_COMM_WORLD). Die allgemeine Form jeder Zeile in der Rangliste ist:

Rang = Schlitz=

Beispielsweise:

$ cat myrankfile
Rang 0=aa-Slot=1:0-2
Rang 1=BB-Slot=0:0,1
Rang 2=cc Slot=1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Bedeutet, dass

Rang 0 läuft auf Knoten aa, gebunden an logisches Socket 1, Kerne 0-2.
Rang 1 läuft auf Knoten bb, gebunden an den logischen Socket 0, Kerne 0 und 1.
Rang 2 wird auf Knoten cc ausgeführt, der an die logischen Kerne 1 und 2 gebunden ist.

Rankfiles können alternativ zur Angabe verwendet werden physikalisch Prozessorstandorte. In diesem Fall,
die Syntax ist etwas anders. Steckdosen werden nicht mehr erkannt und die Steckplatznummer
angegeben muss die Nummer der physischen PU sein, da die meisten Betriebssysteme keine eindeutige physische zuweisen
Bezeichner für jeden Kern im Knoten. Ein richtiges physisches Rangfile sieht also in etwa so aus
die folgende:

$ cat myphysicalrankfile
Rang 0=ein Slot=1
Rang 1=BB-Slot=8
Rang 2=cc-Slot=6

Dies bedeutet, dass

Rang 0 wird auf Knoten aa ausgeführt, der an den Kern gebunden ist, der die physische PU 1 enthält
Rang 1 wird auf Knoten bb ausgeführt, der an den Kern gebunden ist, der die physische PU 8 enthält
Rang 2 wird auf dem Knoten cc ausgeführt, der an den Kern gebunden ist, der die physische PU 6 enthält

Rankfiles werden behandelt als logisch standardmäßig und der MCA-Parameter
rmaps_rank_file_physical muss auf 1 gesetzt werden, um anzuzeigen, dass die Rangdatei
betrachtet als physikalisch.

Die oben aufgeführten Hostnamen sind "absolut", was bedeutet, dass tatsächlich auflösbare Hostnamen
spezifiziert. Hostnamen können jedoch auch als "relativ" angegeben werden, was bedeutet, dass sie
angegeben in Bezug auf eine extern angegebene Liste von Hostnamen (z. B. durch mpiruns
--host Argument, eine Hostdatei oder ein Job-Scheduler).

Die "relative" Angabe hat die Form "+n ", wobei X eine ganze Zahl ist, die die
X-ter Hostname in der Menge aller verfügbaren Hostnamen, indiziert von 0. Beispiel:

$ cat myrankfile
rank 0=+n0 slot=1:0-2
Rang 1=+n1 Slot=0:0,1
Rang 2=+n2 Slot=1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Ab Open MPI v1.7 werden alle Socket-/Core-Slot-Positionen angegeben als logisch
Indizes (die verwendete Open MPI v1.6-Serie) physikalisch Indizes). Sie können Tools wie
HWLOCs "lstopo", um die logischen Indizes von Sockets und Cores zu finden.

Anwendungs- Kontext or Ausführbar Programm?
Um die beiden unterschiedlichen Formen zu unterscheiden, mpirun sucht in der Kommandozeile nach - App .
Wenn es angegeben ist, wird angenommen, dass die in der Befehlszeile angegebene Datei eine Datei ist
Anwendungskontext. Wenn es nicht angegeben ist, wird die Datei als ausführbar angenommen


Lokalisierung Mappen
Wenn für eine Datei kein relativer oder absoluter Pfad angegeben ist, sucht Open MPI zuerst nach
Dateien, indem Sie die Verzeichnisse durchsuchen, die durch die --Weg Möglichkeit. Wenn es keine gibt --Weg
Optionssatz oder wenn die Datei nicht am --Weg Speicherort, dann wird Open MPI suchen
die Umgebungsvariable PATH des Benutzers, wie auf den Quellknoten definiert.

Wenn ein relatives Verzeichnis angegeben wird, muss es relativ zum ursprünglichen Arbeitsverzeichnis sein
bestimmt durch den verwendeten spezifischen Starter. Wenn Sie beispielsweise die Starter rsh oder ssh verwenden,
das Anfangsverzeichnis ist standardmäßig $HOME. Andere Starter können das Anfangsverzeichnis auf setzen
das aktuelle Arbeitsverzeichnis aus dem Aufruf von mpirun.

Strom Arbeiten Verzeichnis
Die -wdir mpirun-Option (und ihr Synonym, -wd) ermöglicht dem Benutzer den Wechsel zu einem beliebigen
Verzeichnis, bevor das Programm aufgerufen wird. Es kann auch in Anwendungskontextdateien verwendet werden
um Arbeitsverzeichnisse auf bestimmten Knoten und/oder für bestimmte Anwendungen anzugeben.

Besitzt das -wdir Option erscheint sowohl in einer Kontextdatei als auch in der Befehlszeile, der Kontext
Dateiverzeichnis überschreibt den Befehlszeilenwert.

Besitzt das -wdir Option angegeben ist, versucht Open MPI, auf die angegebene zu wechseln
Verzeichnis auf allen entfernten Knoten. Wenn dies fehlschlägt, mpirun wird abbrechen.

Besitzt das -wdir Option ist nicht angegeben, sendet Open MPI den Verzeichnisnamen, wohin mpirun
wurde für jeden der entfernten Knoten aufgerufen. Die entfernten Knoten werden versuchen, dies zu ändern
Verzeichnis. Wenn dies nicht möglich ist (z. B. wenn das Verzeichnis auf diesem Knoten nicht existiert), dann
Open MPI verwendet das vom Starter festgelegte Standardverzeichnis.

Alle Verzeichnisänderungen erfolgen, bevor das Programm des Benutzers aufgerufen wird; es wartet nicht bis
MPI_INIT wird genannt.

Standard I / O
Open MPI leitet die UNIX-Standardeingabe für alle Prozesse außer dem . an /dev/null
MPI_COMM_WORLD Rang 0 Prozess. Der MPI_COMM_WORLD Rang 0-Prozess erbt die Standardeingabe
für mpirun. Hinweis: Der aufgerufene Knoten mpirun muss nicht mit dem Knoten identisch sein, bei dem
der MPI_COMM_WORLD Rang 0-Prozess befindet sich. Open MPI übernimmt die Umleitung von mpirun's
Standardeingabe für den Rang 0-Prozess.

Open MPI leitet UNIX-Standardausgaben und -Fehler von Remote-Knoten an den aufgerufenen Knoten weiter
mpirun und druckt es auf der Standardausgabe/Fehler von mpirun. Lokale Prozesse erben die
Standardausgabe/Fehler von mpirun und direkt dorthin überweisen.

Somit ist es möglich, Standard-I/O für Open-MPI-Anwendungen umzuleiten, indem die
typisches Shell-Umleitungsverfahren an mpirun.

% mpirun -np 2 my_app < ​​my_input > my_output

Beachten Sie, dass in diesem Beispiel einzige der MPI_COMM_WORLD Rang 0-Prozess erhält den Stream
für meine_eingabe auf std. Die stdin auf allen anderen Knoten wird an /dev/null gebunden.
Die Standardausgabe aller Knoten wird jedoch in der meine_ausgabe Datei.

Signal Fortpflanzung
Wenn orterun ein SIGTERM und SIGINT empfängt, wird versucht, den gesamten Job zu beenden bis
Senden Sie allen Prozessen im Job ein SIGTERM, warten Sie einige Sekunden, dann
Senden aller Prozesse im Job ein SIGKILL.

Die von Orterun empfangenen SIGUSR1- und SIGUSR2-Signale werden an alle Prozesse in der
Job.

Man kann die Weiterleitung von SIGSTOP und SIGCONT an das von mpirun ausgeführte Programm einschalten von
Setzen des MCA-Parameters orte_forward_job_control auf 1. Ein SIGTSTOP-Signal an mpirun wird
dann veranlassen, dass ein SIGSTOP-Signal an alle von mpirun gestarteten Programme gesendet wird und
ebenso wird ein SIGCONT-Signal an mpirun dazu führen, dass ein SIGCONT gesendet wird.

Andere Signale werden derzeit nicht von Orterun verbreitet.

Prozess Kündigung / Signal Handling
Wenn während der Ausführung einer MPI-Anwendung ein Prozess abnormal abstürzt (entweder beim Beenden
vor dem Aufrufen MPI_FINALIZE, oder als Folge eines Signals sterben), mpirun werde ausdrucken
eine Fehlermeldung und beenden Sie den Rest der MPI-Anwendung.

Benutzersignalhandler sollten es wahrscheinlich vermeiden, den MPI-Status zu bereinigen (Open MPI is
derzeit nicht async-signalsicher; sehen MPI_Init_Thread(3) für Details zu
MPI_THREAD_MULTIPLE und Fadensicherheit). Wenn zum Beispiel ein Segmentierungsfehler auftritt in
MPI_SEND (vielleicht weil ein fehlerhafter Puffer übergeben wurde) und ein Benutzersignal-Handler ist
aufgerufen, wenn dieser Benutzer-Handler versucht, aufzurufen MPI_FINALIZE, Schlimme Dinge könnten passieren
da Open MPI bereits "in" MPI war, als der Fehler auftrat. Schon seit mpirun werde es merken
dass der Prozess aufgrund eines Signals gestorben ist, ist es wahrscheinlich nicht notwendig (und am sichersten) für die
Benutzer, um nur Nicht-MPI-Status zu bereinigen.

Prozess Arbeitsumfeld
Prozesse in der MPI-Anwendung erben ihre Umgebung vom Open RTE-Daemon auf
den Knoten, auf dem sie ausgeführt werden. Die Umgebung wird in der Regel von der
Shell des Benutzers. Auf Remote-Knoten wird die genaue Umgebung durch das Boot-MCA-Modul bestimmt
Gebraucht. Die rsh Startmodul verwendet zum Beispiel entweder rsh/ssh um die Open RTE zu starten
Daemon auf Remote-Knoten und führt normalerweise eine oder mehrere Shell-Setup-Dateien des Benutzers aus
bevor Sie den Open RTE-Daemon starten. Beim Ausführen von dynamisch verknüpften Anwendungen, die
benötigen die LD_LIBRARY_PATH Umgebungsvariable gesetzt werden, muss darauf geachtet werden
dass es beim Booten von Open MPI richtig eingestellt ist.

Weitere Informationen finden Sie im Abschnitt "Remote-Ausführung".

Remote Ausführung
Open MPI erfordert, dass die PATH Umgebungsvariable gesetzt werden, um ausführbare Dateien auf der Fernbedienung zu finden
Knoten (dies ist normalerweise nur notwendig in rsh- oder ssh-basierte Umgebungen --
Batch-/geplante Umgebungen kopieren normalerweise die aktuelle Umgebung in die Ausführung von
Remote-Jobs, also wenn die aktuelle Umgebung PATH und / oder LD_LIBRARY_PATH richtig einstellen,
die Remote-Knoten haben es auch richtig eingestellt). Wenn Open MPI mit shared kompiliert wurde
Bibliotheksunterstützung kann es auch erforderlich sein, die LD_LIBRARY_PATH variable Umgebung
auch auf Remote-Knoten gesetzt (insbesondere um die Shared Libraries zu finden, die zum Ausführen von user
MPI-Anwendungen).

Es ist jedoch nicht immer wünschenswert oder möglich, Shell-Startdateien so zu bearbeiten, dass sie eingestellt werden PATH
und / oder LD_LIBRARY_PATHdem „Vermischten Geschmack“. Seine prefix Option ist für einige einfache Konfigurationen vorgesehen
wo dies nicht möglich ist.

Die prefix Option nimmt ein einziges Argument an: das Basisverzeichnis auf dem entfernten Knoten, wo
OpenMPI ist installiert. Open MPI verwendet dieses Verzeichnis, um die Fernbedienung einzurichten PATH und
LD_LIBRARY_PATH bevor Sie Open MPI oder Benutzeranwendungen ausführen. Dies ermöglicht das Laufen
Öffnen Sie MPI-Jobs, ohne die . vorkonfiguriert zu haben PATH und LD_LIBRARY_PATH auf der Fernbedienung
Knoten.

Open MPI fügt den Basisnamen des "bindir" des aktuellen Knotens hinzu (das Verzeichnis, in dem Open MPIs
ausführbare Dateien installiert sind) an das Präfix und verwendet dieses, um die PATH auf dem entfernten Knoten.
Auf ähnliche Weise fügt Open MPI den Basisnamen des "libdir" des aktuellen Knotens hinzu (das Verzeichnis, in dem
Die Bibliotheken von Open MPI werden installiert) an das Präfix und verwendet dieses, um die LD_LIBRARY_PATH
auf dem entfernten Knoten. Zum Beispiel:

Lokales Bindir: /local/node/directory/bin

Lokales libdir: /local/node/directory/lib64

Wenn die folgende Befehlszeile verwendet wird:

% mpirun --prefix /remote/node/directory

Open MPI fügt "/remote/node/directory/bin" zum PATH und
"/remote/node/directory/lib64" zum D_LIBRARY_PATH auf dem Remote-Knoten, bevor Sie es versuchen
um etwas auszuführen.

Die prefix Option ist nicht ausreichend, wenn die Installationspfade auf dem Remote-Knoten
anders als der lokale Knoten (z. B. wenn "/ lib" wird auf dem lokalen Knoten verwendet, aber "/lib64"ist
auf dem Remote-Knoten verwendet) oder wenn die Installationspfade nicht a
Unterverzeichnis unter einem gemeinsamen Präfix.

Beachten Sie, dass die Ausführung mpirun über einen absoluten Pfadnamen entspricht der Angabe prefix
ohne das letzte Unterverzeichnis im absoluten Pfadnamen zu mpirun. Zum Beispiel:

% /usr/local/bin/mpirun ...

entspricht

% mpirun - Präfix Verzeichnis / usr / local

Exportiert Arbeitsumfeld Variablen
Alle Umgebungsvariablen, die in der Form OMPI_* benannt sind, werden automatisch exportiert
zu neuen Prozessen auf den lokalen und entfernten Knoten. Umweltparameter können auch
über den MCA-Parameter an die neuen Prozesse gesetzt/weitergeleitet mca_base_env_listdem „Vermischten Geschmack“. Seine -x
Option zu mpirun ist veraltet, aber die Syntax des MCA-Parameters folgt dem vorherigen
Beispiel. Während die Syntax des -x Option und MCA param erlaubt die Definition neuer
Beachten Sie, dass der Parser für diese Optionen derzeit nicht sehr ausgereift ist -
es versteht nicht einmal zitierte Werte. Benutzern wird empfohlen, Variablen im
Umgebung und verwenden Sie die Option zum Exportieren; sie nicht zu definieren.

Rahmen MCA Parameter
Die -mca switch ermöglicht die Übergabe von Parametern an verschiedene MCA (Modular Component
Architektur) Module. MCA-Module wirken sich direkt auf MPI-Programme aus, da sie
einstellbare Parameter, die zur Laufzeit eingestellt werden (z. B. welcher BTL-Kommunikationsgerätetreiber
verwenden, welche Parameter an diese BTL übergeben werden sollen usw.).

Die -mca switch nimmt zwei Argumente an: und dem „Vermischten Geschmack“. Seine argumentieren im Allgemeinen
gibt an, welches MCA-Modul den Wert erhält. Zum Beispiel die "btl" wird verwendet
um auszuwählen, welche BTL für den Transport von MPI-Nachrichten verwendet werden soll. Die Argument ist das
Wert, der übergeben wird. Zum Beispiel:

mpirun -mca btl tcp,self -np 1 foo
Weist Open MPI an, die BTLs "tcp" und "self" zu verwenden und eine einzelne Kopie von "foo" und "foo" auszuführen
zugewiesenen Knoten.

mpirun -mca btl selbst -np 1 foo
Weist Open MPI an, die „self“-BTL zu verwenden und eine einzelne Kopie von „foo“ auszuführen und zuzuordnen
Knoten.

Die -mca Schalter kann mehrmals verwendet werden, um unterschiedliche zu spezifizieren und / oder
Argumente. Wenn das gleiche wird mehrfach angegeben, die s sind verkettet
mit einem Komma (",") trennen.

Beachten Sie, dass die -mca switch ist einfach eine Verknüpfung zum Setzen von Umgebungsvariablen. Die
Der gleiche Effekt kann erreicht werden, indem vorher entsprechende Umgebungsvariablen gesetzt werden
Laufen mpirun. Die Form der Umgebungsvariablen, die Open MPI festlegt, ist:

OMPI_MCA_ =

Somit wird die -mca switch überschreibt alle zuvor festgelegten Umgebungsvariablen. Die -mca
Einstellungen überschreiben in ähnlicher Weise die MCA-Parameter, die in $OPAL_PREFIX/etc/openmpi-mca-
params.conf oder $HOME/.openmpi/mca-params.conf-Datei.

Unbekannt Argumente werden immer noch als Umgebungsvariable gesetzt -- sie werden nicht überprüft (von
mpirun) auf Richtigkeit. Unzulässig oder falsch Argumente können sein oder nicht
gemeldet -- es hängt vom jeweiligen MCA-Modul ab.

Um die verfügbaren Komponententypen unter der MCA-Architektur zu finden, oder um die verfügbaren
Parameter für eine bestimmte Komponente verwenden Sie die ompi_info Befehl. Siehe die ompi_info(1) Mann
Seite für detaillierte Informationen zum Befehl.

Laufen as Wurzel
Das Open MPI-Team rät dringend von der Ausführung ab mpirun als Root-Benutzer. MPI
Anwendungen sollten als normale (Nicht-Root-)Benutzer ausgeführt werden.

Diesem Rat entsprechend wird mpirun standardmäßig die Ausführung als Root verweigern. Um dies zu überschreiben
Standardmäßig können Sie die --allow-run-as-root Option zum mpirun Befehlszeile.

Beenden Status
Es gibt keine Standarddefinition für was mpirun sollte als Exit-Status zurückkehren. Nach
Diskussionen haben wir uns für die folgende Methode zur Zuweisung der mpirun wunsch
Status (Anmerkung: in der folgenden Beschreibung ist die "erste" Stelle die Erstbewerbung
Gestartet von mpirun - alle Jobs, die von diesem Job erzeugt werden, werden als "sekundär" bezeichnet
Arbeitsplätze):

· wenn alle Prozesse im primären Job normalerweise mit dem Exit-Status 0 enden, geben wir 0 zurück

· wenn ein oder mehrere Prozesse im primären Job normalerweise mit einem Exit ungleich Null enden
status geben wir den Exit-Status des Prozesses mit dem niedrigsten MPI_COMM_WORLD-Rang zurück an
einen Nicht-Null-Status haben

· wenn alle Prozesse im Primärjob normalerweise mit dem Exit-Status 0 enden und eins oder
mehr Prozesse in einem sekundären Job enden normalerweise mit einem Exit-Status ungleich Null, wir (a)
den Exit-Status des Prozesses mit dem niedrigsten MPI_COMM_WORLD-Rang in der niedrigsten zurückgeben
jobid einen Nicht-Null-Status haben und (b) eine Nachricht ausgeben, die den Exit-Status von . zusammenfasst
die Haupt- und alle Nebenjobs.

· wenn die cmd-Zeilenoption --report-child-jobs-separately gesetzt ist, geben wir -nur- die
Exit-Status des primären Jobs. Jeder Exit-Status ungleich Null in sekundären Jobs ist
nur in einer zusammenfassenden Druckaussage gemeldet.

Standardmäßig zeichnet OMPI auf und stellt fest, dass MPI-Prozesse mit einer Beendigung ungleich Null beendet wurden
Status. Dies wird im Allgemeinen nicht als "abnormale Beendigung" angesehen - dh OMPI wird dies nicht tun
einen MPI-Job abbrechen, wenn ein oder mehrere Prozesse einen Status ungleich Null zurückgeben. Stattdessen ist die Standardeinstellung
Verhalten meldet einfach die Anzahl der Prozesse, die mit einem Status ungleich Null beendet werden, wenn
Abschluss der Arbeit.

In einigen Fällen kann es jedoch wünschenswert sein, den Job abzubrechen, wenn ein Prozess
endet mit einem Nicht-Null-Status. Beispielsweise kann ein Nicht-MPI-Job ein schlechtes Ergebnis von
eine Berechnung und möchte abbrechen, aber keine Kerndatei generieren. Oder einen MPI-Job
kann nach einem Aufruf von MPI_Finalize fortfahren, aber angeben, dass alle Prozesse abgebrochen werden sollen
aufgrund einiger Post-MPI-Ergebnisse.

Es ist nicht zu erwarten, dass diese Situation häufig auftritt. Allerdings im Interesse
Um der breiteren Gemeinschaft zu dienen, hat OMPI jetzt die Möglichkeit, den Benutzern die Möglichkeit zu geben, dies zu lenken
Jobs werden abgebrochen, wenn ein Prozess mit einem Status ungleich Null beendet wird. Einstellen des MCA-Parameters
"orte_abort_on_non_zero_status" auf 1 bewirkt, dass OMPI alle Prozesse einmal abbricht
Prozessdefinierung
wird mit einem Nicht-Null-Status beendet.

Auf diese Weise verursachte Kündigungen werden auf der Konsole als "abnormal" gemeldet
Beendigung", wobei der erste Prozess, der so beendet wird, zusammen mit seinem Beendigungsstatus identifiziert wird.

Beispiele:

Beachten Sie auch die Beispiele in den obigen Abschnitten.

mpirun -np 4 -mca btl ib,tcp,self prog1
Führen Sie 4 Kopien von prog1 mit den BTLs "ib", "tcp" und "self" für den Transport von MPI . aus
Nachrichten.

mpirun -np 4 -mca btl tcp,sm,selbst
--mca btl_tcp_if_include eth0 prog1
Führen Sie 4 Kopien von prog1 mit den BTLs "tcp", "sm" und "self" für den Transport von MPI . aus
Nachrichten, wobei TCP nur die eth0-Schnittstelle verwendet, um zu kommunizieren. Beachten Sie, dass andere BTLs
haben ähnliche if_include MCA-Parameter.

RÜCKKEHR BEWERTUNG

mpirun gibt 0 zurück, wenn alle Prozesse gestartet wurden von mpirun Exit nach Aufruf von MPI_FINALIZE. EIN
Ein Wert ungleich Null wird zurückgegeben, wenn ein interner Fehler in mpirun aufgetreten ist, oder einer oder mehrere
Prozesse, die vor dem Aufruf von MPI_FINALIZE beendet wurden. Wenn in mpirun ein interner Fehler aufgetreten ist,
der entsprechende Fehlercode wird zurückgegeben. Falls ein oder mehrere Prozesse beendet werden
vor dem Aufruf von MPI_FINALIZE der Rückgabewert des MPI_COMM_WORLD-Rangs des Prozesses
zur Verbesserung der Gesundheitsgerechtigkeit mpirun erste Nachrichten, die vor dem Aufrufen von MPI_FINALIZE gestorben sind, werden zurückgegeben. Beachten Sie, dass,
Im Allgemeinen wird dies der erste Prozess sein, der gestorben ist, aber es ist nicht garantiert, dass dies der Fall ist.

Verwenden Sie mpiexec.openmpi online mit den onworks.net-Diensten