orte-submit - Online nel cloud

PROGRAMMA:

NOME

orte-submit, ompi-submit - Esegue lavori seriali e paralleli in Open MPI utilizzando un DVM.

Nota: ompi-submit e orte-sottomettere sono sinonimi l'uno dell'altro. Usando uno dei nomi
produrrà lo stesso comportamento.

SINOSSI

Modello di dati multipli a processo singolo (SPMD):

ompi-submit [ opzioni ] [ ]

Modello a dati multipli con istruzioni multiple (MIMD):

ompi-submit [ opzioni_globali ]
[ opzioni_locali1 ] [ ] :
[ opzioni_locali2 ] [ ] :
...:
[ opzioni_localiN ] [ ]

Si noti che in entrambi i modelli, invocando ompi-submit tramite un nome di percorso assoluto è equivalente a
specificando il --prefisso opzione con a valore equivalente alla directory dove ompi-
inviare risiede, meno la sua ultima sottodirectory. Per esempio:

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

è equivalente

% ompi-submit --prefisso / Usr / local

VELOCE SOMMARIO

Usa il of orte-sottomettere richiede che Tu prima di tutto inizia a , il distribuito virtuale Macchina (DVM)
utilizzando orte-dvm.

Se stai semplicemente cercando come eseguire un'applicazione MPI, probabilmente vorrai usare a
riga di comando della seguente forma:

% ompi-submit [ -np X ] [ --hostfile ]

Questo eseguirà X copie di nel tuo attuale ambiente di runtime (se in esecuzione sotto
un gestore di risorse supportato, Open MPI's ompi-submit di solito utilizzerà automaticamente il
corrispondente avviatore del processo di gestione delle risorse, al contrario, ad esempio, rsh or SSH,
che richiedono l'uso di un file host, o eseguiranno per impostazione predefinita tutte le copie X sul
localhost), pianificazione (per impostazione predefinita) in modalità round-robin per slot della CPU. Guarda il resto
questa pagina per maggiori dettagli.

Si prega di notare che ompi-submit associa automaticamente i processi a partire dall'inizio della v1.8
serie. In assenza di ulteriori direttive vengono utilizzati due modelli vincolanti:

legante a nucleo: quando il numero di processi è <= 2

legante a presa: quando il numero di processi è > 2

Se la tua applicazione utilizza thread, probabilmente vorrai assicurarti di non esserlo
legato a tutti (specificando --bind-to none), o legato a più core usando an
livello vincolante appropriato o numero specifico di elementi di elaborazione per domanda
processo.

VERSIONI

ompi-submit invierà il nome della directory in cui è stato invocato sul nodo locale a
ciascuno dei nodi remoti e tentare di passare a quella directory. Vedi la "Corrente"
Directory di lavoro" di seguito per ulteriori dettagli.

Il programma eseguibile. Questo è identificato come il primo argomento non riconosciuto
ompi-sottomettere.

Passa questi argomenti di runtime a ogni nuovo processo. Questi devono essere sempre i
ultimi argomenti a ompi-submit. Se viene utilizzato un file di contesto dell'app, sarà
ignorato.

-h, --Aiuto
Visualizza la guida per questo comando

-q, --silenzioso
Elimina i messaggi informativi da orte-submit durante l'esecuzione dell'applicazione.

-v, --verboso
Sii prolisso

-V, --versione
Stampa il numero della versione. Se non vengono forniti altri argomenti, anche questo causerà
orte-submit per uscire.

Utilizzare una delle seguenti opzioni per specificare su quali host (nodi) del DVM eseguire.
La specifica di host esterni al DVM genererà un errore.

-H, -ospite, --ospite
Elenco di host su cui richiamare i processi.

-file host, --file host
Fornisci un file host da usare.

-filemacchina, --filemacchina
Sinonimo di -file host.

Le seguenti opzioni specificano il numero di processi da avviare. Nota che nessuno dei
le opzioni implicano una particolare politica di associazione, ad esempio la richiesta di N processi per ogni socket
non implica che i processi saranno legati al socket.

-c, -n, -N, -np <#>
Esegui questo numero di copie del programma sui nodi indicati. Questa opzione indica che
il file specificato è un programma eseguibile e non un contesto dell'applicazione. se no
viene fornito un valore per il numero di copie da eseguire (ovvero, né "-np" né
i suoi sinonimi sono forniti sulla riga di comando), Open MPI verrà eseguito automaticamente
una copia del programma su ogni slot di processo (vedi sotto per la descrizione di un "processo
slot"). Questa funzione, tuttavia, può essere utilizzata solo nel modello SPMD e tornerà
un errore (senza iniziare l'esecuzione dell'applicazione) altrimenti.

—map-by ppr:N:
Avvia N volte il numero di oggetti del tipo specificato su ciascun nodo.

-npersocket, --npersocket <#persocket>
Su ogni nodo, avvia tanti processi per il numero di socket del processore attivi
il nodo. Il -npersocket l'opzione attiva anche il -bind-to-socket opzione.
(deprecato a favore di --map-by ppr:n:socket)

-npernodo, --npernodo <#pernode>
Su ogni nodo, avvia questo numero di processi. (deprecato a favore di --map-by
ppr:n:nodo)

-pernodo, --pernodo
Su ogni nodo, avvia un processo -- equivalente a -npernodo 1. (deprecato in
favore di --map-by ppr:1:node)

Per mappare i processi:

--map-da
Mappa sull'oggetto specificato, il valore predefinito è presa di corrente. Le opzioni supportate includono slot,
hwthread, core, L1cache, L2cache, L3cache, socket, numa, board, node, sequenziale,
distanza, e ppr. Qualsiasi oggetto può includere modificatori aggiungendo : e any
combinazione di PE=n (associa n elementi di elaborazione a ciascuna procedura), SPAN (bilanciamento del carico
i processi attraverso l'allocazione), OVERSUBSCRIBE (consentire più processi su un nodo
rispetto agli elementi di elaborazione) e NOOVERSUBSCRIBE. Questo include PPR, dove il
pattern verrebbe terminato da altri due punti per separarlo dai modificatori.

-bycore, --bycore
Mappare i processi per core (deprecato a favore di --map-by core)

- presa di corrente, --bysocket
Mappa i processi per socket (deprecato a favore di --map-by socket)

-nolocale, --nolocale
Non eseguire alcuna copia dell'applicazione avviata sullo stesso nodo di orte-submit
sta correndo. Questa opzione sovrascriverà l'elenco del localhost con --ospite o qualsiasi
altro meccanismo che specifica l'host.

-nooversubscribe, --nooversubscribe
Non sovrascrivere alcun nodo; errore (senza avviare alcun processo) se il
il numero di processi richiesto causerebbe una sottoscrizione eccessiva. Questa opzione implicitamente
imposta "max_slots" uguale al valore "slots" per ogni nodo.

-bynodo, --bynodo
I processi di avvio uno per nodo, ciclicamente per nodo in modo round-robin. Questo
distribuisce i processi in modo uniforme tra i nodi e assegna i ranghi MPI_COMM_WORLD in un round-
pettirosso, modo "per nodo".

Per ordinare i ranghi dei processi in MPI_COMM_WORLD:

--classifica per
Classifica in modalità round-robin in base all'oggetto specificato, il valore predefinito è fessura.
Le opzioni supportate includono slot, hwthread, core, L1cache, L2cache, L3cache, socket,
numa, tavola e nodo.

Per l'associazione del processo:

--vincolato a
Associa i processi all'oggetto specificato, il valore predefinito è core. Le opzioni supportate includono
slot, hwthread, core, l1cache, l2cache, l3cache, socket, numa, board e none.

-cpus-per-proc, --cpus-per-proc <#perproc>
Associa ogni processo al numero specificato di CPU. (deprecato a favore di --map-
di :PE=n)

-cpus per rango, --cpus-per-grado <#perrank>
Alias ​​per -cpus-per-proc. (deprecato a favore di --map-by :PE=n)

-bind-to-core, --bind-to-core
Associa i processi ai core (deprecato a favore di --bind-to core)

-bind-to-socket, --bind-to-socket
Associa i processi ai socket del processore (deprecato a favore di --bind-to socket)

-legare a nessuno, --bind-to-none
Non associare i processi (deprecato a favore di --bind-to none)

-report-binding, --report-binding
Segnala eventuali associazioni per i processi avviati.

-lista-slot, --lista-slot
Elenco di ID processore da utilizzare per l'associazione dei processi MPI. Gli attacchi specificati
verrà applicato a tutti i processi MPI. Vedere la spiegazione di seguito per la sintassi.

Per i file di rango:

-R F, --rankfile
Fornisci un file di rango.

Per gestire l'I/O standard:

-nome-file-output, --nome-file di output
Reindirizzare lo stdout, stderr e stddiag di tutti i processi a un processo univoco
versione del nome file specificato. Qualsiasi directory nel nome del file lo farà
essere creato automaticamente. Ogni file di output sarà composto da nomefile.id, dove il
id sarà il rango dei processi in MPI_COMM_WORLD, riempito a sinistra con zero per
corretto ordinamento negli elenchi.

-stdin, --stdin
Il rango MPI_COMM_WORLD del processo che deve ricevere stdin. L'impostazione predefinita è
inoltra stdin a MPI_COMM_WORLD rank 0, ma questa opzione può essere utilizzata per inoltrare
stdin a qualsiasi processo. È anche accettabile specificare nessuna, indicando che no
i processi devono ricevere stdin.

-tag-uscita, --tag-uscita
Contrassegna ogni riga di output con stdout, stderr e stddiag con [lavoro,
MCW_rank] indicando il jobid del processo e il rango MPI_COMM_WORLD del
processo che ha generato l'output e il canale che lo ha generato.

-output timestamp, --timestamp-output
Contrassegnare ogni riga di output su stdout, stderr e stddiag.

-xml, --xml
Fornisci tutto l'output a stdout, stderr e stddiag in un formato xml.

-xtermine, --xterm
Visualizza l'output dei processi identificati dai loro ranghi MPI_COMM_WORLD in
finestre xterm separate. I ranghi sono specificati come un elenco separato da virgole di
intervalli, con un -1 che indica tutto. Verrà creata una finestra separata per ciascuno
processo specificato. Nota: xterm normalmente chiuderà la finestra al termine
del processo in esecuzione al suo interno. Tuttavia, aggiungendo un "!" alla fine della lista
di ranghi specificati, verranno fornite le opzioni appropriate per garantire che xterm mantenga
la finestra aperta dopo il processo termina, consentendo così di vedere il processo'
produzione. Ogni finestra xterm dovrà successivamente essere chiusa manualmente. Nota: In
alcuni ambienti, xterm potrebbe richiedere che l'eseguibile si trovi nel percorso dell'utente, oppure
essere specificato in termini assoluti o relativi. Pertanto, potrebbe essere necessario specificare a
eseguibile locale come "./foo" anziché solo "foo". Se xterm non riesce a trovare il
eseguibile, ompi-submit si bloccherà, ma risponderà comunque correttamente a ctrl-c. Se
questo accade, controlla che l'eseguibile sia stato specificato correttamente e prova
nuovamente.

Per gestire i file e l'ambiente di runtime:

-sentiero, --il percorso
che verrà utilizzato durante il tentativo di individuare gli eseguibili richiesti. Questo
viene utilizzato prima di utilizzare l'impostazione PATH locale.

--prefisso
Directory dei prefissi che verrà utilizzata per impostare il PERCORSO e LD_LIBRARY_PATH sul canale
nodo remoto prima di richiamare Open MPI o il processo di destinazione. Vedi il "Telecomando
Esecuzione", di seguito.

--preload-binario
Copia gli eseguibili specificati su macchine remote prima di avviare remote
processi. Gli eseguibili verranno copiati nella directory della sessione Open MPI e
verrà cancellato al termine del lavoro.

--precarica-file
Precarica l'elenco di file separati da virgole nella directory di lavoro corrente del
macchine remote in cui i processi verranno avviati prima di avviare tali processi.

--preload-file-dest-dir
La directory di destinazione da utilizzare per i file di precaricamento, se diversa da quella corrente
directory di lavoro. Per impostazione predefinita, i percorsi assoluti e relativi forniti da
--preload-file vengono utilizzati.

-wd
Sinonimo di -dir.

-dir
Passa alla directory prima che il programma dell'utente venga eseguito. Vedi la "Corrente"
Working Directory" per le note sui relativi percorsi. Nota: Se l' -dir opzione
appare sia sulla riga di comando che in un contesto dell'applicazione, il contesto sarà
avere la precedenza sulla riga di comando. Quindi, se il percorso per il wdir desiderato è
diverso sui nodi di backend, allora deve essere specificato come un percorso assoluto che
è corretto per il nodo di backend.

-x
Esportare le variabili di ambiente specificate sui nodi remoti prima di eseguire il
programma. È possibile specificare solo una variabile di ambiente per -x opzione. Esistente
le variabili di ambiente possono essere specificate o nuovi nomi di variabili specificati con
valori corrispondenti. Per esempio:
% ompi-submit -x DISPLAY -x OFILE=/tmp/out ...

Il parser per -x l'opzione non è molto sofisticata; non si capisce nemmeno
valori citati. Si consiglia agli utenti di impostare le variabili nell'ambiente e quindi utilizzare
-x esportarli (non definirli).

Impostazione dei parametri MCA:

-gmca, --gmca
Passa i parametri MCA globali applicabili a tutti i contesti. Europe è
nome del parametro; è il valore del parametro.

-mc, --mca
Invia argomenti a vari moduli MCA. Vedere la sezione "MCA", di seguito.

Per il debug:

-debug, - debug
Invocare il debugger a livello utente indicato da orte_base_user_debugger MCA
parametro.

-debug, --debugger
Sequenza di debugger da cercare quando - debug è usato (cioè un sinonimo di
orte_base_user_debugger parametro MCA).

- tv, --tv
Avvia i processi nel debugger di TotalView. Compatibilità con le versioni precedenti deprecata
bandiera. Sinonimo di - debug.

Ci sono anche altre opzioni:

--allow-esegui-come-root
Consentire ompi-submit da eseguire quando eseguito dall'utente root (ompi-submit il valore predefinito è
si interrompe quando viene avviato come utente root).

-abortito, --abortito <#>
Imposta il numero massimo di processi interrotti da visualizzare.

--app
Fornisci un file app, ignorando tutte le altre opzioni della riga di comando.

-cfr, --cartofile
Fornire un file di cartografia.

--etero
Indica che vengono forniti più app_context che sono un mix di 32/64 bit
binari.

-ompi-server, --ompi-server <uri or file>
Specificare l'URI del server Open MPI (o l'ompi-submit da usare come
server), il nome del file (specificato come file:filename) che lo contiene
info, o il PID (specificato come pid:#) dell'ompi-submit da usare come
il server. Il server Open MPI viene utilizzato per supportare dati multi-applicazione
scambio tramite le funzioni MPI-2 MPI_Publish_name e MPI_Lookup_name.

Le seguenti opzioni sono utili per gli sviluppatori; non sono generalmente utili ai più
Utenti ORTE e/o MPI:

-d, --debug-sviluppo
Abilita il debug di OmpiRTE (il livello di runtime in Open MPI). Questo non è
generalmente utile per la maggior parte degli utenti.

Potrebbero esserci altre opzioni elencate con ompi-submit --Aiuto.

Ambiente Variabili
MPIEXEC_TIMEOUT
Il numero massimo di secondi che ompi-submit (mpiexec) correrà. Dopo questi tanti
secondi, ompi-submit interromperà il lavoro avviato e uscirà.

DESCRIZIONE

Un'invocazione di ompi-submit avvia un'applicazione MPI in esecuzione in Open MPI. Se la
l'applicazione è un singolo processo di dati multipli (SPMD), l'applicazione può essere specificata su
, il ompi-submit riga di comando.

Se l'applicazione è più dati multipli di istruzioni (MIMD), comprendenti più
programmi, l'insieme di programmi e argomenti può essere specificato in due modi: Esteso
Argomenti della riga di comando e contesto dell'applicazione.

Un contesto applicativo descrive il set di programmi MIMD inclusi tutti gli argomenti in a
file separato. Questo file contiene essenzialmente più ompi-submit righe di comando, meno
il nome del comando stesso. La possibilità di specificare diverse opzioni per diversi
le istanze di un programma sono un altro motivo per utilizzare un contesto applicativo.

Gli argomenti della riga di comando estesi consentono la descrizione del layout dell'applicazione sul
riga di comando usando i due punti (:) per separare la specificazione di programmi e argomenti.
Alcune opzioni sono impostate globalmente su tutti i programmi specificati (ad esempio --hostfile), mentre
altri sono specifici di un singolo programma (es. -np).

specificando ospite Nodes
I nodi host possono essere identificati sul ompi-submit riga di comando con il -ospite opzione o in a
file host.

Per esempio,

ompi-submit -H aa,aa,bb ./a.out
lancia due processi sul nodo aa e uno su bb.

Oppure, considera il file host

% gatto miofilehost
aa slot=2
bb slot=2
cc slot=2

Da quando il DVM è stato avviato con orte-dvm, orte-sottomettere ignorerà tutti gli argomenti degli slot in
il file host. Valori forniti tramite hostfile a orte-dvm controllerà il comportamento.

ompi-submit -hostfile miohostfile ./a.out
avvierà due processi su ciascuno dei tre nodi.

ompi-submit -hostfile miohostfile -host aa ./a.out
avvierà due processi, entrambi sul nodo aa.

ompi-submit -hostfile miohostfile -host dd ./a.out
non troverà host su cui eseguire e interromperà con un errore. Cioè, l'host specificato dd
non è nel file host specificato.

specificando Numero of Processi
Come abbiamo appena visto, il numero di processi da eseguire può essere impostato utilizzando l'hostfile. Altro
esistono meccanismi.

Il numero di processi avviati può essere specificato come multiplo del numero di nodi o
socket del processore disponibili. Per esempio,

ompi-submit -H aa,bb -npersocket 2 ./a.out
avvia i processi 0-3 sul nodo aa e il processo 4-7 sul nodo bb, dove aa e bb sono entrambi
nodi a doppio socket. Il -npersocket l'opzione attiva anche il -bind-to-socket opzione,
che è discusso in una sezione successiva.

ompi-submit -H aa,bb -npernode 2 ./a.out
lancia i processi 0-1 sul nodo aa ed elabora 2-3 sul nodo bb.

ompi-submit -H aa,bb -npernode 1 ./a.out
avvia un processo per nodo host.

ompi-submit -H aa,bb -pernode ./a.out
equivale a -npernodo 1.

Un'altra alternativa è specificare il numero di processi con il -np opzione. Tener conto di
ora il file host

% gatto miofilehost
aa slot=4
bb slot=4
cc slot=4

Adesso,

ompi-submit -hostfile miohostfile -np 6 ./a.out
avvierà i processi 0-3 sul nodo aa e i processi 4-5 sul nodo bb. Il resto
gli slot nel file host non verranno utilizzati poiché il -np opzione indicava che solo 6
dovrebbero essere avviati i processi.

Mappatura Processi a nodi: utilizzando Politiche
Gli esempi sopra illustrano la mappatura predefinita dei processi di processo ai nodi. Questo
la mappatura può anche essere controllata con vari ompi-submit opzioni che descrivono la mappatura
politiche.

Considera lo stesso file host di cui sopra, di nuovo con -np 6:

nodo aa nodo bb nodo cc

ompi-invia 0 1 2 3 4 5

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

ompi-submit -nolocal 0 1 2 3 4 5

Il --map-da nodo l'opzione bilancia il carico dei processi tra i nodi disponibili,
numerando ogni processo in modo round-robin.

Il -nolocale l'opzione impedisce a qualsiasi processo di essere mappato sull'host locale (in questo
nodo caso aa). Mentre ompi-submit consuma in genere poche risorse di sistema, -nolocale può essere
utile per avviare lavori molto grandi dove ompi-submit potrebbe effettivamente essere necessario utilizzare
notevoli quantità di memoria e/o tempo di elaborazione.

Come -np può specificare meno processi di quanti siano gli slot, può anche sovrascrivere
gli slot. Ad esempio, con lo stesso file host:

ompi-submit -hostfile miohostfile -np 14 ./a.out
avvierà i processi 0-3 sul nodo aa, 4-7 su bb e 8-11 su cc. Quindi aggiungerà il
rimanenti due processi a qualsiasi nodo scelga.

Si possono anche specificare limiti all'oversubscription. Ad esempio, con lo stesso file host:

ompi-submit -hostfile miohostfile -np 14 -nooversubscribe ./a.out
produrrà un errore poiché -nooversubscribe impedisce l'eccessivo abbonamento.

I limiti all'oversubscription possono essere specificati anche nel file host stesso:
% cat miofilehost
aa slot=4 max_slots=4
bb max_slot=4
cc slot=4

Il max_slot campo specifica tale limite. Quando lo fa, il slot il valore predefinito è
limite. Ora:

ompi-submit -hostfile miohostfile -np 14 ./a.out
fa sì che i primi 12 processi vengano lanciati come prima, ma i restanti due
i processi verranno forzati sul nodo cc. Gli altri due nodi sono protetti dal
hostfile contro l'oversubscription da parte di questo lavoro.

Usando il --nooversubscribe l'opzione può essere utile poiché Open MPI attualmente non ottiene
valori "max_slots" dal gestore delle risorse.

Naturalmente, -np può essere utilizzato anche con il -H or -ospite opzione. Per esempio,

ompi-submit -H aa,bb -np 8 ./a.out
avvia 8 processi. Poiché sono specificati solo due host, dopo i primi due
i processi sono mappati, uno su aa e uno su bb, i restanti processi sono sovrascritti
gli host specificati.

Ed ecco un esempio MIMD:

ompi-submit -H aa -np 1 hostname: -H bb,cc -np 2 uptime
avvierà il processo 0 in esecuzione hostname sul nodo aa e sui processi 1 e 2 ciascuno in esecuzione
uptime rispettivamente sui nodi bb e cc.

Mapping, Classifica, e Rilegatura: Oh Mio!
Open MPI utilizza una procedura in tre fasi per l'assegnazione delle posizioni e dei ranghi dei processi:

mappatura Assegna una posizione predefinita a ciascun processo

posto Assegna un valore di classificazione MPI_COMM_WORLD a ciascun processo

rilegatura Vincola ogni processo per essere eseguito su processori specifici

Il mappatura viene utilizzato per assegnare una posizione predefinita a ciascun processo in base al mappatore
essere impiegato. La mappatura per slot, nodo e risultati sequenziali nell'assegnazione del
processi a livello di nodo. Al contrario, la mappatura per oggetto consente al mappatore di assegnare
il processo a un oggetto effettivo su ciascun nodo.

Nota: la posizione assegnata al processo è indipendente da dove sarà legato - il
l'assegnazione viene utilizzata esclusivamente come input per l'algoritmo di associazione.

La mappatura dei processi di processo ai nodi può essere definita non solo con politiche generali
ma anche, se necessario, usando mappature arbitrarie che non possono essere descritte da un semplice
politica. Si può usare il "mapper sequenziale", che legge il file host riga per riga,
assegnando i processi ai nodi nell'ordine specificato dal file host. Utilizzare il -mc mappe
ss opzione. Ad esempio, utilizzando lo stesso file host di prima:

ompi-submit -hostfile miohostfile -mca rmaps seq ./a.out

avvierà tre processi, uno su ciascuno dei nodi aa, bb e cc, rispettivamente. lo slot
i conteggi non contano; viene avviato un processo per riga su qualunque nodo sia elencato nella
linea.

Un altro modo per specificare mappature arbitrarie è con un rankfile, che fornisce dettagli
controllo anche sul binding del processo. I file di rango sono discussi di seguito.

La seconda fase si concentra sul posto del processo all'interno di MPI_COMM_WORLD del lavoro.
Open MPI lo separa dalla procedura di mappatura per consentire una maggiore flessibilità nel
posizionamento relativo dei processi MPI. Ciò è meglio illustrato considerando quanto segue
due casi in cui abbiamo usato l'opzione —map-by ppr:2:socket:

nodo aa nodo bb

classifica per core 0 1 ! 2 3 4 5 ! 6 7

zoccolo di classificazione per 0 2 ! 1 3 4 6 ! 5 7

presa classificata: span 0 4 ! 1 5 2 6 ! 3 7

La classifica per core e per slot fornisce lo stesso risultato: una semplice progressione di
MPI_COMM_WORLD si classifica in ogni nodo. La classifica per socket fa una classifica round-robin all'interno
ciascun nodo fino a quando a tutti i processi è stato assegnato un rango MCW, quindi si procede al
nodo successivo. Aggiungendo il campata modificatore alla direttiva ranking provoca l'algoritmo di ranking
trattare l'intera allocazione come un'unica entità, quindi vengono assegnati i ranghi MCW
su tutte le prese prima di tornare all'inizio.

Il rilegatura fase lega effettivamente ogni processo a un dato insieme di processori. questo può
migliorare le prestazioni se il sistema operativo posiziona i processi in modo non ottimale. Per
ad esempio, potrebbe sovrascrivere alcuni socket del processore multi-core, lasciando altri socket
oziare; questo può portare i processi a contendersi inutilmente le risorse comuni. oppure
potrebbe diffondere troppo ampiamente i processi; questo può essere non ottimale se le prestazioni dell'applicazione
è sensibile ai costi di comunicazione tra processi. La rilegatura può anche mantenere il funzionamento
sistema dalla migrazione eccessiva dei processi, indipendentemente da quanto questi processi siano ottimali
sono stati posti per cominciare.

I processori da utilizzare per il binding possono essere identificati in termini di raggruppamenti topologici
- ad esempio, l'associazione a un l3cache legherà ogni processo a tutti i processori nell'ambito di
una singola cache L3 all'interno della posizione assegnata. Quindi, se un processo è assegnato dal
mappatore a un certo socket, quindi a -vincolato a l3cache direttiva farà sì che il processo sia
legato ai processori che condividono una singola cache L3 all'interno di quel socket.

Per aiutare a bilanciare i carichi, la direttiva vincolante utilizza un metodo round-robin quando si lega a
livelli inferiori a quelli utilizzati nel mappatore. Ad esempio, considera il caso in cui un lavoro è mappato
al livello del socket e quindi legato al core. Ogni socket avrà più core, quindi se
più processi sono mappati su un dato socket, l'algoritmo di associazione assegnerà ciascuno
processo localizzato in un socket in un core univoco in modo round-robin.

In alternativa, i processi mappati da l2cache e quindi associati al socket saranno semplicemente associati
a tutti i processori nel socket in cui si trovano. In questo modo, gli utenti possono
esercitare un controllo dettagliato sulla posizione relativa del rango MCW e sul legame.

Infine, --report-binding può essere utilizzato per segnalare le associazioni.

Ad esempio, si consideri un nodo con due socket del processore, ciascuno composto da quattro core. Noi
eseguire il ompi-submit con -np 4 --report-binding e le seguenti opzioni aggiuntive:

% ompi-submit ... --map-by core --bind-to core
[...] ... vincolante figlio [...,0] a cpus 0001
[...] ... vincolante figlio [...,1] a cpus 0002
[...] ... vincolante figlio [...,2] a cpus 0004
[...] ... vincolante figlio [...,3] a cpus 0008

% ompi-submit ... --map-by socket --bind-to socket
[...] ... associazione figlio [...,0] al socket 0 cpus 000f
[...] ... binding figlio [...,1] al socket 1 cpus 00f0
[...] ... associazione figlio [...,2] al socket 0 cpus 000f
[...] ... binding figlio [...,3] al socket 1 cpus 00f0

% ompi-submit ... --map-by core:PE=2 --bind-to core
[...] ... vincolante figlio [...,0] a cpus 0003
[...] ... vincolante figlio [...,1] a cpus 000c
[...] ... vincolante figlio [...,2] a cpus 0030
[...] ... vincolante figlio [...,3] a cpus 00c0

% ompi-submit ... --bind-to none

Qui, --report-binding mostra il legame di ogni processo come una maschera. Nel primo caso,
i processi si legano ai nuclei successivi come indicato dalle maschere 0001, 0002, 0004 e
0008. Nel secondo caso, i processi si legano a tutti i core su socket successivi come indicato
dalle maschere 000f e 00f0. I processi passano attraverso i socket del processore in un round-
pettirosso tutte le volte che è necessario. Nel terzo caso, le maschere ci mostrano che 2
core sono stati vincolati per processo. Nel quarto caso, il binding è disattivato e no
sono segnalati i vincoli.

Il supporto di Open MPI per l'associazione dei processi dipende dal sistema operativo sottostante.
Pertanto, alcune opzioni di associazione del processo potrebbero non essere disponibili su tutti i sistemi.

L'associazione al processo può essere impostata anche con i parametri MCA. Il loro utilizzo è meno conveniente di
quella di ompi-submit opzioni. D'altra parte, i parametri MCA possono essere impostati non solo sul
ompi-submit riga di comando, ma in alternativa in un file mca-params.conf di sistema o utente o as
variabili di ambiente, come descritto nella sezione MCA di seguito. Alcuni esempi includono:

ompi-submit opzione valore chiave parametro MCA

--map-by core rmaps_base_mapping_policy core
--map-by socket rmaps_base_mapping_policy socket
--rank-by core rmaps_base_ranking_policy core
--bind-to core hwloc_base_binding_policy core
--bind-to socket socket hwloc_base_binding_policy
--bind-to nessuno hwloc_base_binding_policy nessuno

File di classifica
I Rankfile sono file di testo che specificano informazioni dettagliate su come i singoli processi
dovrebbero essere mappati ai nodi ea quale(i) processore(i) dovrebbero essere legati. Ogni riga di a
rankfile specifica la posizione di un processo (per i lavori MPI, il "rank" del processo si riferisce
al suo rango in MPI_COMM_WORLD). La forma generale di ogni riga nel rankfile è:

classifica = slot=

Per esempio:

$ cat miofile di rango
rango 0=aa slot=1:0-2
rango 1=bb slot=0:0,1
rango 2=cc slot=1-2
$ ompi-submit -H aa,bb,cc,dd -rf miorankfile ./a.out

Significa che

Il rango 0 viene eseguito sul nodo aa, legato al socket logico 1, core 0-2.
Il rango 1 viene eseguito sul nodo bb, legato al socket logico 0, core 0 e 1.
Il rango 2 viene eseguito sul nodo cc, legato ai core logici 1 e 2.

I file di rango possono essere utilizzati in alternativa per specificare Fisico posizioni del processore. In questo caso,
la sintassi è un po' diversa. Le prese non vengono più riconosciute e il numero di slot
dato deve essere il numero della PU fisica poiché la maggior parte dei sistemi operativi non assegna un fisico univoco
identificatore a ciascun core nel nodo. Quindi, un file di rango fisico appropriato assomiglia a
il seguente:

$ cat miofilefisico
rango 0=aa slot=1
rango 1 = slot bb = 8
rango 2=cc slot=6

Ciò significa che

Il rango 0 verrà eseguito sul nodo aa, legato al core che contiene la PU fisica 1
Il rango 1 verrà eseguito sul nodo bb, legato al core che contiene la PU fisica 8
Rank 2 verrà eseguito sul nodo cc, legato al core che contiene la PU fisica 6

I file di rango sono trattati come logico per impostazione predefinita, e il parametro MCA
rmaps_rank_file_physical deve essere impostato su 1 per indicare che il rankfile deve essere
considerato come Fisico.

I nomi host elencati sopra sono "assoluti", il che significa che i nomi host risolvibili effettivi sono
specificato. Tuttavia, i nomi host possono anche essere specificati come "relativi", nel senso che sono
specificato in relazione a un elenco di nomi host specificato esternamente (ad es. da ompi-submit's
--host argomento, un file host o un pianificatore di lavori).

La specifica "relativa" è della forma "+n ", dove X è un numero intero che specifica il
X-esimo nome host nell'insieme di tutti i nomi host disponibili, indicizzato da 0. Ad esempio:

$ cat miofile di rango
rank 0=+n0 slot=1:0-2
rango 1=+n1 slot=0:0,1
rango 2=+n2 slot=1-2
$ ompi-submit -H aa,bb,cc,dd -rf miorankfile ./a.out

A partire da Open MPI v1.7, tutte le posizioni degli slot socket/core vengono specificate come logico
indici (utilizzata la serie Open MPI v1.6 Fisico indici). È possibile utilizzare strumenti come
"lstopo" di HWLOC per trovare gli indici logici di socket e core.

Applicazioni Contesto or eseguibile Programma?
Per distinguere le due diverse forme, ompi-submit cerca sulla riga di comando per --app
opzione. Se è specificato, si presume che il file indicato sulla riga di comando sia un
contesto applicativo. Se non è specificato, si presume che il file sia un eseguibile
.

Individuazione File
Se non viene specificato alcun percorso relativo o assoluto per un file, Open MPI cercherà prima
file cercando nelle directory specificate dal --il percorso opzione. Se non c'è --il percorso
opzione impostata o se il file non viene trovato in --il percorso posizione, quindi Open MPI cercherà
la variabile di ambiente PATH dell'utente come definita sui nodi di origine.

Se viene specificata una directory relativa, deve essere relativa alla directory di lavoro iniziale
determinato dallo specifico starter utilizzato. Ad esempio quando si utilizzano gli starter rsh o ssh,
la directory iniziale è $HOME per impostazione predefinita. Altri principianti possono impostare la directory iniziale su
la directory di lavoro corrente dall'invocazione di ompi-submit.

Corrente lavoro elenco
Il -dir opzione ompi-submit (e il suo sinonimo, -wd) consente all'utente di passare a an
directory arbitraria prima che il programma venga richiamato. Può essere utilizzato anche nell'applicazione
file di contesto per specificare directory di lavoro su nodi specifici e/o per specifici
applicazioni.

Se l' -dir l'opzione appare sia in un file di contesto che sulla riga di comando, il contesto
file directory sovrascriverà il valore della riga di comando.

Se l' -dir l'opzione è specificata, Open MPI tenterà di passare a quello specificato
directory su tutti i nodi remoti. Se questo fallisce, ompi-submit abortirà.

Se l' -dir opzione è non è un specificato, Open MPI invierà il nome della directory dove ompi-
inviare è stato richiamato su ciascuno dei nodi remoti. I nodi remoti proveranno a cambiare in
quella directory. Se non sono in grado (ad esempio, se la directory non esiste su quel nodo),
quindi Open MPI utilizzerà la directory predefinita determinata dallo starter.

Tutto il cambio di directory avviene prima che venga richiamato il programma dell'utente; non aspetta fino a quando
MPI_INIT è chiamato.

Standard I / O
Open MPI indirizza l'input standard UNIX a /dev/null su tutti i processi tranne il
MPI_COMM_WORLD processo di rango 0. Il processo di rango 0 MPI_COMM_WORLD eredita l'input standard
da ompi-submit. Nota: Il nodo che ha invocato ompi-submit non deve essere lo stesso del
nodo in cui risiede il processo di rango 0 MPI_COMM_WORLD. Open MPI gestisce il reindirizzamento di
ompi-submit's standard input per il processo di rango 0.

Open MPI dirige l'output standard UNIX e l'errore dai nodi remoti al nodo che ha invocato
ompi-submit e lo stampa sullo standard output/errore di ompi-submit. Processi locali
eredita lo standard output/errore di ompi-submit e trasferiscilo direttamente.

Pertanto è possibile reindirizzare l'I/O standard per le applicazioni Open MPI utilizzando il
tipica procedura di reindirizzamento della shell attiva ompi-submit.

% ompi-submit -np 2 mia_app < ​​mio_input > mio_output

Nota che in questo esempio esclusivamente il processo di rango 0 MPI_COMM_WORLD riceverà lo stream
da mio_input su std. Lo stdin su tutti gli altri nodi sarà legato a /dev/null.
Tuttavia, lo stdout di tutti i nodi verrà raccolto nel mio_output file.

Signal Propagazione
Quando orte-submit riceve un SIGTERM e SIGINT, tenterà di terminare l'intero lavoro di
inviando a tutti i processi nel lavoro un SIGTERM, aspettando un piccolo numero di secondi, quindi
inviando a tutti i processi nel lavoro un SIGKILL.

I segnali SIGUSR1 e SIGUSR2 ricevuti da orte-submit vengono propagati a tutti i processi nel
lavoro.

Si può attivare l'inoltro di SIGSTOP e SIGCONT al programma eseguito da ompi-submit
impostando il parametro MCA orte_forward_job_control su 1. Un segnale SIGTSTOP su ompi-
submit causerà quindi l'invio di un segnale SIGSTOP a tutti i programmi avviati da ompi-
invia e allo stesso modo un segnale SIGCONT a ompi-submit causerà un SIGCONT inviato.

Altri segnali non sono attualmente propagati da orte-submit.

Processo Terminazione / Signal Manovrabilità
Durante l'esecuzione di un'applicazione MPI, se un processo muore in modo anomalo (o in uscita
prima di invocare MPI_FINALIZZA, o morire a causa di un segnale), ompi-submit stamperà
un messaggio di errore e terminare il resto dell'applicazione MPI.

I gestori del segnale dell'utente dovrebbero probabilmente evitare di provare a ripulire lo stato MPI (Open MPI is
attualmente non sicuro per il segnale asincrono; vedere MPI_Init_thread(3) per i dettagli su
MPI_THREAD_MULTIPLE e sicurezza del filo). Ad esempio, se si verifica un errore di segmentazione in
MPI_SEND (forse perché è stato passato un buffer errato) e un gestore del segnale utente è
invocato, se questo gestore utente tenta di invocare MPI_FINALIZZA, Potrebbero succedere cose brutte
poiché Open MPI era già "in" MPI quando si è verificato l'errore. Da quando ompi-submit andrete a
nota che il processo è morto a causa di un segnale, probabilmente non è necessario (e più sicuro)
per consentire all'utente di ripulire solo lo stato non MPI.

Processo Ambiente
I processi nell'applicazione MPI ereditano il loro ambiente dal demone Open RTE su
il nodo su cui sono in esecuzione. L'ambiente è tipicamente ereditato dal
shell dell'utente. Sui nodi remoti, l'ambiente esatto è determinato dal modulo MCA di avvio
Usato. Il rsh il modulo di avvio, ad esempio, utilizza sia rsh/SSH per lanciare l'Open RTE
demone su nodi remoti, e in genere esegue uno o più file di configurazione della shell dell'utente
prima di avviare il demone Open RTE. Quando si eseguono applicazioni collegate dinamicamente che
richiedono il LD_LIBRARY_PATH variabile di ambiente da impostare, occorre prestare attenzione per garantire
che sia impostato correttamente all'avvio di Open MPI.

Vedere la sezione "Esecuzione remota" per maggiori dettagli.

Assistenza
Open MPI richiede che il PERCORSO la variabile d'ambiente deve essere impostata per trovare gli eseguibili sul telecomando
nodi (questo è in genere necessario solo in rsh- o SSHambienti basati su
gli ambienti batch/pianificati in genere copiano l'ambiente corrente nell'esecuzione di
lavori remoti, quindi se l'ambiente corrente ha PERCORSO e / o LD_LIBRARY_PATH impostato correttamente,
anche i nodi remoti lo avranno impostato correttamente). Se Open MPI è stato compilato con shared
supporto della biblioteca, potrebbe anche essere necessario avere il LD_LIBRARY_PATH variabile d'ambiente
impostato anche su nodi remoti (soprattutto per trovare le librerie condivise necessarie per eseguire user
applicazioni MPI).

Tuttavia, non è sempre desiderabile o possibile modificare i file di avvio della shell da impostare PERCORSO
e / o LD_LIBRARY_PATH. --prefisso l'opzione è fornita per alcune semplici configurazioni
dove questo non è possibile.

Il --prefisso l'opzione accetta un singolo argomento: la directory di base sul nodo remoto dove
MPI aperto è installato. Open MPI utilizzerà questa directory per impostare il telecomando PERCORSO e
LD_LIBRARY_PATH prima di eseguire qualsiasi applicazione Open MPI o utente. Questo permette di correre
Aprire i lavori MPI senza aver preconfigurato il PERCORSO e LD_LIBRARY_PATH sul telecomando
i nodi.

Open MPI aggiunge il nome di base del "bindir" del nodo corrente (la directory in cui Open MPI's
eseguibili sono installati) al prefisso e lo usa per impostare il PERCORSO sul nodo remoto.
Allo stesso modo, Open MPI aggiunge il nome di base della "libdir" del nodo corrente (la directory in cui
Le librerie di Open MPI sono installate) al prefisso e lo usa per impostare il LD_LIBRARY_PATH
sul nodo remoto. Per esempio:

Bindir locale: /local/node/directory/bin

libdir locale: /local/node/directory/lib64

Se viene utilizzata la seguente riga di comando:

% ompi-submit --prefix /remote/nodo/directory

Open MPI aggiungerà "/remote/node/directory/bin" al file PERCORSO e
"/remote/node/directory/lib64" in D_LIBRARY_PATH sul nodo remoto prima di tentare
eseguire qualsiasi cosa.

Il --prefisso opzione non è sufficiente se i percorsi di installazione sul nodo remoto sono
diverso dal nodo locale (ad esempio, se "/ lib" viene utilizzato sul nodo locale, ma "/lib64"è
utilizzato sul nodo remoto), o se i percorsi di installazione sono qualcosa di diverso da a
sottodirectory con un prefisso comune.

Nota che l'esecuzione ompi-submit tramite un percorso assoluto equivale a specificare
--prefisso senza l'ultima sottodirectory nel percorso assoluto per ompi-submit. For
esempio:

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

è equivalente

% ompi-submit --prefisso / Usr / local

esportato Ambiente Variabili
Tutte le variabili di ambiente denominate nella forma OMPI_* verranno esportate automaticamente
a nuovi processi sui nodi locali e remoti. Anche i parametri ambientali possono essere
impostato/inoltro ai nuovi processi utilizzando il parametro MCA lista_mca_base_env. -x
opzione a ompi-submit è stato deprecato, ma la sintassi del parametro MCA segue che
esempio precedente. Mentre la sintassi di -x opzione e il parametro MCA consente la definizione di
nuove variabili, si noti che il parser per queste opzioni non è attualmente molto sofisticato
- non comprende nemmeno i valori quotati. Si consiglia agli utenti di impostare le variabili nel
ambiente e utilizzare l'opzione per esportarli; non definirli.

Configurazione MCA parametri
Il -mc permette il passaggio di parametri a vari MCA (Modular Component
Architettura) moduli. I moduli MCA hanno un impatto diretto sui programmi MPI perché consentono
parametri sintonizzabili da impostare in fase di esecuzione (come quale driver del dispositivo di comunicazione BTL a
utilizzare, quali parametri passare a quel BTL, ecc.).

Il -mc switch accetta due argomenti: e . argomento in generale
specifica quale modulo MCA riceverà il valore. Ad esempio, il si usa "btl"
per selezionare quale BTL utilizzare per il trasporto di messaggi MPI. Il argomento è il
valore passato. Per esempio:

ompi-submit -mca btl tcp,self -np 1 foo
Dice a Open MPI di utilizzare i BTL "tcp" e "self" e di eseguire una singola copia di "foo" an
nodo allocato.

ompi-submit -mca btl self -np 1 foo
Dice a Open MPI di utilizzare il BTL "self" e di eseguire una singola copia di "foo" un allocato
nodo.

Il -mc l'interruttore può essere utilizzato più volte per specificare diversi e / o
argomenti. Se lo stesso è specificato più di una volta, il le s sono concatenate
con una virgola (",") che li separa.

Notare quello -mc switch è semplicemente una scorciatoia per impostare le variabili di ambiente. Il
lo stesso effetto può essere ottenuto impostando le corrispondenti variabili di ambiente prima
running ompi-submit. La forma delle variabili d'ambiente che Open MPI imposta è:

OMPI_MCA_ =

Così, la -mc switch sovrascrive qualsiasi variabile di ambiente impostata in precedenza. Il -mc
similmente sovrascrivono i parametri MCA impostati in $OPAL_PREFIX/etc/openmpi-mca-
params.conf o $HOME/.openmpi/mca-params.conf.

Sconosciuto gli argomenti sono ancora impostati come variabili d'ambiente -- non sono controllati (da
ompi-submit) per correttezza. Illegale o scorretto gli argomenti possono o non possono essere
segnalato -- dipende dal modulo MCA specifico.

Per trovare i tipi di componenti disponibili nell'architettura MCA o per trovare quelli disponibili
parametri per un componente specifico, utilizzare il ompi_info comando. Vedi il ompi_info(1) uomo
pagina per informazioni dettagliate sul comando.

corsa as radice
Il team di Open MPI sconsiglia vivamente l'esecuzione ompi-submit come utente root. MPI
le applicazioni dovrebbero essere eseguite come utenti regolari (non root).

Rispecchiando questo consiglio, ompi-submit rifiuterà di essere eseguito come root per impostazione predefinita. Per ignorare
questa impostazione predefinita, puoi aggiungere il --allow-esegui-come-root opzione per il ompi-submit riga di comando.

uscita status
Non esiste una definizione standard per cosa ompi-submit dovrebbe tornare come stato di uscita.
Dopo una lunga discussione, abbiamo optato per il seguente metodo per l'assegnazione del ompi-
inviare stato di uscita (nota: nella descrizione che segue, il lavoro "primario" è l'iniziale
domanda avviata da ompi-submit - tutti i lavori che vengono generati da quel lavoro sono designati
lavori “secondari”):

· se tutti i processi nel lavoro primario terminano normalmente con stato di uscita 0, restituiamo 0

· se uno o più processi nel lavoro primario terminano normalmente con un'uscita diversa da zero
status, restituiamo lo stato di uscita del processo con il rango MPI_COMM_WORLD più basso a
avere uno stato diverso da zero

· se tutti i processi nel lavoro primario normalmente terminano con stato di uscita 0 e uno o
più processi in un lavoro secondario normalmente terminano con uno stato di uscita diverso da zero, noi (a)
restituisce lo stato di uscita del processo con il rango MPI_COMM_WORLD più basso nel più basso
jobid per avere uno stato diverso da zero e (b) emettere un messaggio che riassume lo stato di uscita di
i lavori primari e tutti i secondari.

· se l'opzione della riga cmd --report-child-jobs-separately è impostata, restituiremo -solo- il
stato di uscita del lavoro principale. Qualsiasi stato di uscita diverso da zero nei lavori secondari sarà
riportato esclusivamente in una dichiarazione di stampa riassuntiva.

Per impostazione predefinita, OMPI registra e rileva che i processi MPI sono usciti con terminazione diversa da zero
stato. Questo non è generalmente considerato una "terminazione anormale" - cioè, OMPI non lo farà
interrompe un lavoro MPI se uno o più processi restituiscono uno stato diverso da zero. Invece, l'impostazione predefinita
comportamento riporta semplicemente il numero di processi che terminano con uno stato diverso da zero su
completamento del lavoro.

Tuttavia, in alcuni casi può essere desiderabile che il lavoro venga interrotto quando qualsiasi processo
termina con stato diverso da zero. Ad esempio, un lavoro non MPI potrebbe rilevare un risultato errato da
un calcolo e desidera interromperlo, ma non vuole generare un file core. O un lavoro MPI
potrebbe continuare oltre una chiamata a MPI_Finalize, ma indicare che tutti i processi dovrebbero interrompersi
a causa di alcuni risultati post-MPI.

Non è previsto che questa situazione si verificherà frequentemente. Tuttavia, nell'interesse
di servire la comunità più ampia, OMPI ora ha un mezzo per consentire agli utenti di dirigerlo
i lavori vengono interrotti all'uscita di qualsiasi processo con stato diverso da zero. Impostazione del parametro MCA
"orte_abort_on_non_zero_status" su 1 farà sì che OMPI abortisca tutti i processi una volta
processi
esce con stato diverso da zero.

Le interruzioni causate in questo modo verranno segnalate sulla console come "anomali"
terminazione", con il primo processo per uscire così identificato insieme al suo stato di uscita.

ESEMPI

Assicurati di vedere anche gli esempi nelle sezioni precedenti.

ompi-submit -np 4 -mca btl ib,tcp,self prog1
Esegui 4 copie di prog1 utilizzando i BTL "ib", "tcp" e "self" per il trasporto di MPI
messaggi.

ompi-submit -np 4 -mca btl tcp,sm,self
--mca btl_tcp_if_include eth0 prog1
Esegui 4 copie di prog1 utilizzando i BTL "tcp", "sm" e "self" per il trasporto di MPI
messaggi, con TCP che utilizza solo l'interfaccia eth0 per comunicare. Nota che altri BTL
hanno parametri if_include MCA simili.

RITORNO VALORE

ompi-submit restituisce 0 se tutti i processi sono stati avviati da ompi-submit esci dopo aver chiamato
MPI_FINALIZE. Viene restituito un valore diverso da zero se si è verificato un errore interno in ompi-submit,
o uno o più processi sono usciti prima di chiamare MPI_FINALIZE. Se un errore interno
si è verificato in ompi-submit, viene restituito il codice di errore corrispondente. Nel caso in cui uno
o più processi escono prima di chiamare MPI_FINALIZE, il valore di ritorno di MPI_COMM_WORLD
rango del processo che ompi-submit i primi avvisi sono morti prima di chiamare MPI_FINALIZE will
essere restituito. Nota che, in generale, questo sarà il primo processo che è morto ma non lo è
garantito che sia così.

Utilizzare orte-submit online utilizzando i servizi onworks.net