orte-submit - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

orte-submit, ompi-submit - Führen Sie serielle und parallele Jobs in Open MPI mit einem DVM aus.

Hinweis: ompi-senden und orte-senden sind Synonyme füreinander. Einen der Namen verwenden
wird das gleiche Verhalten hervorrufen.

ZUSAMMENFASSUNG

Single Process Multiple Data (SPMD)-Modell:

ompi-senden [ Optionen ] [ ]

Multiple Instruction Multiple Data (MIMD)-Modell:

ompi-senden [ globale_optionen ]
[ lokale_optionen1 ] [ ] :
[ lokale_optionen2 ] [ ] :
...:
[ lokale_optionenN ] [ ]

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

% /usr/local/bin/ompi-submit ...

entspricht

% ompi-submit --prefix Verzeichnis / usr / local

SCHNELL ZUSAMMENFASSUNG

Nutzen Sie of orte-senden erfordert zur Abwicklung, Integrierung, Speicherung und Sie zuerst Anfang die Verteilt Assistent Maschine (DVM)
mit automatisierten orte-dvm.

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

% ompi-submit [ -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 ompi-senden 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 ompi-submit ab dem Start von v1.8 automatisch Prozesse bindet
Serie. 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

OPTIONAL

ompi-senden 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 "Aktuelles"
Arbeitsverzeichnis" unten für weitere Details.

Das ausführbare Programm. Dies wird als erstes nicht erkanntes Argument identifiziert
zu ompi-senden.

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

-h, --help
Hilfe zu diesem Befehl anzeigen

-q, --ruhig
Unterdrücken Sie informative Nachrichten von orte-submit 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
orte-submit zum Beenden.

Verwenden Sie eine der folgenden Optionen, um anzugeben, auf welchen Hosts (Knoten) der DVM ausgeführt werden soll.
Die Angabe von Hosts außerhalb des DVM führt zu einem Fehler.

-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.

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 orte-submit . aus
läuft. Diese Option überschreibt das Auflisten des localhost mit --Gastgeber oder irgendein
anderen Host-spezifizierten 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, ompi-submit hängt sich auf, reagiert aber immer noch korrekt auf ein Strg-C. Wenn
Wenn dies passiert, überprüfen Sie bitte, ob die ausführbare Datei richtig angegeben wurde, 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.

-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 ganz ohne irgendetwas tun oder drücken zu müssen.
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:
% ompi-submit -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. ist das
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 ompi-senden ausführen, wenn sie vom Root-Benutzer ausgeführt werden (ompi-senden Standardmäßig ist
Abbruch 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.

-ompi-server, --ompi-server <uri or Datei>
Geben Sie den URI des Open MPI-Servers an (oder den ompi-submit, der als
server) , der Name der Datei (angegeben als file:filename), die das enthält
info, oder die PID (angegeben als pid:#) des zu verwendenden ompi-submit
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.

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.

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

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

BESCHREIBUNG

Ein Aufruf von ompi-senden 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
die ompi-senden 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 ompi-senden Befehlszeilen, weniger
der 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 ompi-senden Kommandozeile mit dem -Wirt Option oder in a
Hostdatei.

Zum Beispiel,

ompi-submit -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

Da das DVM mit gestartet wurde orte-dvm, orte-senden ignoriert alle Slot-Argumente in
die Hostdatei. Über Hostdatei bereitgestellte Werte an orte-dvm wird das Verhalten kontrollieren.

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

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

ompi-submit -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,

ompi-submit -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.

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

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

ompi-submit -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,

ompi-submit -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 ompi-senden Optionen, die das Mapping beschreiben
Politik.

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

Knoten aa Knoten bb Knoten cc

ompi-senden 0 1 2 3 4 5

ompi-submit --map-by Knoten 0 3 1 4 2 5

ompi-submit -nolocal 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 ompi-senden verbraucht normalerweise nur wenige Systemressourcen, -nolokal kann sein
hilfreich beim Starten sehr großer Aufträge, bei denen ompi-senden möglicherweise tatsächlich verwenden müssen
spürbare Mengen an 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:

ompi-submit -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:

ompi-submit -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:

ompi-submit -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,

ompi-submit -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:

ompi-submit -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:

ompi-submit -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 ompi-senden mit -np 4 --report-bindings und die folgenden zusätzlichen Optionen:

% ompi-submit ... --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

% ompi-submit ... --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

% ompi-submit ... --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

% ompi-submit ... --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 ompi-senden Optionen. Andererseits können MCA-Parameter nicht nur auf dem
ompi-senden Befehlszeile, aber alternativ in einer System- oder Benutzerdatei mca-params.conf oder als
Umgebungsvariablen, wie im Abschnitt MCA unten beschrieben. Einige Beispiele sind:

ompi-submit-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
$ ompi-submit -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 ompi-submit's
--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
$ ompi-submit -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.

Antragsprozess Kontext or Ausführbar Programm?
Um die beiden unterschiedlichen Formen zu unterscheiden, ompi-senden sucht in der Kommandozeile nach - App
Möglichkeit. 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 ompi-senden.

Aktuell Arbeiten Verzeichnis
Die -wdir ompi-submit-Option (und ihr Synonym, -wd) ermöglicht dem Benutzer den Wechsel zu einem
beliebiges Verzeichnis, bevor das Programm aufgerufen wird. Es kann auch in der Anwendung verwendet werden
Kontextdateien, um Arbeitsverzeichnisse auf bestimmten Knoten und/oder für bestimmte
um weitere Anwendungsbeispiele zu finden.

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, ompi-senden wird abbrechen.

Besitzt das -wdir Option ist nicht angegeben, sendet Open MPI den Verzeichnisnamen, wohin ompi-
abschicken wurde für jeden der entfernten Knoten aufgerufen. Die Remote-Knoten werden versuchen, zu zu wechseln
dieses Verzeichnis. Wenn dies nicht möglich ist (z. B. wenn das Verzeichnis auf diesem Knoten nicht existiert),
dann verwendet Open MPI 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
von ompi-senden. Hinweis: Der aufgerufene Knoten ompi-senden muss nicht dasselbe sein wie die
Knoten, in dem sich der Rang 0-Prozess MPI_COMM_WORLD befindet. Open MPI übernimmt die Umleitung von
ompi-senden's Standardeingabe für den Rang 0-Prozess.

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

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

% ompi-submit -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
von 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 orte-submit ein SIGTERM und SIGINT empfängt, wird versucht, den gesamten Job zu beenden, indem
Senden Sie allen Prozessen im Job ein SIGTERM, warten Sie einige Sekunden, dann
Senden aller Prozesse im Job ein SIGKILL.

Die von orte-submit empfangenen SIGUSR1- und SIGUSR2-Signale werden an alle Prozesse im
Job.

Man kann die Weiterleitung von SIGSTOP und SIGCONT an das von ompi-submit ausgeführte Programm einschalten
indem Sie den MCA-Parameter orte_forward_job_control auf 1 setzen. Ein SIGTSTOP-Signal zum
Submit wird dann ein SIGSTOP-Signal an alle von ompi gestarteten Programme gesendet.
Submit und ebenso ein SIGCONT-Signal an ompi-submit wird ein SIGCONT gesendet.

Andere Signale werden derzeit nicht durch orte-submit propagiert.

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), ompi-senden wird gedruckt
eine Fehlermeldung aus 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 ompi-senden werden wir
Beachten Sie, dass der Prozess aufgrund eines Signals gestorben ist, es ist wahrscheinlich nicht notwendig (und am sichersten)
damit der Benutzer nur Nicht-MPI-Status bereinigen kann.

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".

Verbund 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:

% ompi-submit --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 ompi-senden über einen absoluten Pfadnamen entspricht der Angabe
prefix ohne das letzte Unterverzeichnis im absoluten Pfadnamen zu ompi-senden. For
Beispiel:

% /usr/local/bin/ompi-submit ...

entspricht

% ompi-submit --prefix 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 ompi-senden ist veraltet, aber die Syntax des MCA-Parameters folgt dem
vorheriges Beispiel. Während die Syntax des -x Option und MCA param erlaubt die Definition von
neue Variablen, 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 Kenngrößen
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:

ompi-submit -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.

ompi-submit -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 ompi-senden. 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
ompi-senden) 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 ompi-senden als Root-Benutzer. MPI
Anwendungen sollten als normale (Nicht-Root-)Benutzer ausgeführt werden.

Diesem Rat entsprechend wird ompi-submit standardmäßig die Ausführung als Root verweigern. Überschreiben
diese Standardeinstellung können Sie hinzufügen --allow-run-as-root Option zum ompi-senden Befehlszeile.

Beenden Status
Es gibt keine Standarddefinition für was ompi-senden sollte als Exit-Status zurückkehren.
Nach ausführlicher Diskussion haben wir uns für die folgende Methode zur Zuweisung der ompi-
abschicken Exit-Status (Hinweis: in der folgenden Beschreibung ist der "primäre" Job der initiale
Anwendung gestartet von ompi-submit - alle Jobs, die von diesem Job erzeugt werden, sind gekennzeichnet
"Nebenberufe":

· 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.

ompi-submit -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.

ompi-submit -np 4 -mca btl tcp,sm,self
--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 Mehrwert

ompi-senden gibt 0 zurück, wenn alle Prozesse gestartet wurden von ompi-senden nach Anruf verlassen
MPI_FINALIZE. Ein Wert ungleich Null wird zurückgegeben, wenn ein interner Fehler in ompi-submit aufgetreten ist,
oder ein oder mehrere Prozesse wurden vor dem Aufrufen von MPI_FINALIZE beendet. Bei einem internen Fehler
in ompi-submit aufgetreten ist, wird der entsprechende Fehlercode zurückgegeben. Für den Fall, dass man
oder mehr Prozesse beenden vor dem Aufruf von MPI_FINALIZE, dem Rückgabewert von MPI_COMM_WORLD
Rang des Prozesses, der ompi-senden erste Benachrichtigungen starben, bevor MPI_FINALIZE aufgerufen wurde
zurück. Beachten Sie, dass dies im Allgemeinen der erste Prozess ist, der gestorben ist, aber nicht ist
garantiert so.

Verwenden Sie orte-submit online mit den onworks.net-Diensten