mpiexec.openmpi - En ligne dans le Cloud

PROGRAMME:

Nom

orterun, mpirun, mpiexec - Exécuter des travaux en série et en parallèle dans Open MPI. oshrun, shmemrun
- Exécuter des travaux en série et en parallèle dans Open SHMEM.

Remarque : mpirun, mpiexec et outerun sont tous synonymes les uns des autres ainsi que oshrun,
shmemrun au cas où Open SHMEM est installé. L'utilisation de l'un des noms produira le même
comportement.

SYNOPSIS

Modèle de données multiples à processus unique (SPMD) :

mpirun [options] [ ]

Modèle de données multiples à instructions multiples (MIMD) :

mpirun [ options_globales ]
[ options_locales1 ] [ ] :
[ options_locales2 ] [ ] :
...:
[ options_localesN ] [ ]

Notez que dans les deux modèles, l'invocation mpirun via un nom de chemin absolu équivaut à
spécifiant le --préfixe option avec un valeur équivalente au répertoire où mpirun
réside, moins son dernier sous-répertoire. Par exemple:

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

équivaut à

% mpirun --préfixe / Usr / local

RAPIDE RÉSUMÉ

Si vous cherchez simplement à exécuter une application MPI, vous voudrez probablement utiliser un
ligne de commande de la forme suivante :

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

Cela exécutera X copies de dans votre environnement d'exécution actuel (si exécuté sous
un gestionnaire de ressources pris en charge, Open MPI's mpirun utilisera généralement automatiquement le
démarreur de processus de gestionnaire de ressources correspondant, par opposition à, par exemple, rsh or ssh,
qui nécessitent l'utilisation d'un fichier hôte, ou exécuteront par défaut toutes les copies X sur le
localhost), la planification (par défaut) de manière circulaire par slot CPU. Voir le reste de
cette page pour plus de détails.

Veuillez noter que mpirun lie automatiquement les processus dès le début de la série v1.8.
Deux modèles de liaison sont utilisés en l'absence de toute autre directive :

Lier à coeur: lorsque le nombre de processus est <= 2

Lier à prise: lorsque le nombre de processus est > 2

Si votre application utilise des threads, vous voudrez probablement vous assurer que vous n'êtes pas
lié du tout (en spécifiant --bind-to none), ou lié à plusieurs cœurs à l'aide d'un
niveau de liaison approprié ou nombre spécifique d'éléments de traitement par demande
processus.

OPTIONS

mpirun enverra le nom du répertoire où il a été invoqué sur le nœud local à chaque
des nœuds distants et essayez de passer à ce répertoire. Voir le "Travail actuel
Annuaire" ci-dessous pour plus de détails.

L'exécutable du programme. Ceci est identifié comme le premier argument non reconnu
à mpirun.

Transmettez ces arguments d'exécution à chaque nouveau processus. Ceux-ci doivent toujours être les
derniers arguments à mpirun. Si un fichier de contexte d'application est utilisé, sera
ignoré.

-h, --Aidez-moi
Afficher l'aide de cette commande

-q, --silencieux
Supprimer les messages d'information d'orterun pendant l'exécution de l'application.

-v, --verbeux
Soyez verbeux

-V, --version
Imprimer le numéro de version. Si aucun autre argument n'est fourni, cela entraînera également
outerun pour sortir.

-afficher-carte, --display-map
Affichez un tableau indiquant l'emplacement mappé de chaque processus avant le lancement.

-display-devel-map, --display-devel-map
Afficher un tableau plus détaillé montrant l'emplacement mappé de chaque processus avant
à lancer (généralement d'intérêt pour les développeurs).

-affichage-allocation, --affichage-allocation
Affichez l'allocation de ressources détectée.

Utilisez l'une des options suivantes pour spécifier les hôtes (nœuds) du cluster sur lesquels s'exécuter.
Notez qu'à partir du début de la version v1.8, mpirun lancera un démon sur chaque hôte
dans l'allocation (telle que modifiée par les options suivantes) au tout début de
l'exécution, que les processus d'application soient ou non mappés sur
y exécuter. Ceci est fait pour permettre la collecte d'informations de topologie matérielle à partir du
nœuds distants, nous permettant ainsi de mapper les processus par rapport à une topologie connue. Cependant, c'est un
changement par rapport au comportement des versions précédentes où les démons n'étaient lancés qu'après le mappage
était terminée, et ne s'est donc produite que sur les nœuds où les processus d'application seraient réellement
être en train d'exécuter.

-H, -hôte, --hôte
Liste des hôtes sur lesquels appeler des processus.

-fichier hôte, --fichierhôte
Fournissez un fichier hôte à utiliser.

-fichiermachine, --fichiermachine
synonyme de -fichier hôte.

-ensemble de processeurs, --ensemble-cpu
Limitez les processus lancés aux processeurs logiques spécifiés sur chaque nœud. Noter que
les options de reliure s'appliqueront toujours dans l'enveloppe spécifiée - par exemple, vous pouvez
choisir de lier chaque processus à un seul processeur dans l'ensemble de processeurs spécifié.

Les options suivantes spécifient le nombre de processus à lancer. Notez qu'aucun des
les options impliquent une politique de liaison particulière - par exemple, demander N processus pour chaque socket
n'implique pas que les processus seront liés au socket.

-c, -n, --n, -np <#>
Exécutez ce nombre de copies du programme sur les nœuds donnés. Cette option indique que
le fichier spécifié est un programme exécutable et non un contexte d'application. Sinon
valeur est fournie pour le nombre de copies à exécuter (c'est-à-dire, ni le "-np" ni
ses synonymes sont fournis sur la ligne de commande), Open MPI s'exécutera automatiquement
une copie du programme sur chaque slot de processus (voir ci-dessous pour la description d'un "processus
slot"). Cette fonctionnalité, cependant, ne peut être utilisée que dans le modèle SPMD et renverra
une erreur (sans lancer l'exécution de l'application) sinon.

—carte par ppr:N:
Lancer N fois le nombre d'objets du type spécifié sur chaque nœud.

-npersocket, --npersocket <#persocket>
Sur chaque nœud, lancez ce nombre de processus multiplié par le nombre de sockets de processeur sur
le nœud. Les -npersocket l'option active également le -lier-à-socket option.
(déprécié en faveur de --map-by ppr:n:socket)

-npernode, --npernode <#pernode>
Sur chaque nœud, lancez ce nombre de processus. (déprécié en faveur de --map-by
ppr:n:noeud)

-pernœud, --pernode
Sur chaque nœud, lancez un processus - équivalent à -npernode 1. (obsolète dans
faveur de --map-by ppr:1:node)

Pour mapper des processus :

--map-par
Mapper sur l'objet spécifié, par défaut douille. Les options prises en charge incluent la fente,
hwthread, core, L1cache, L2cache, L3cache, socket, numa, board, node, séquentiel,
distance, et ppr. Tout objet peut inclure des modificateurs en ajoutant un : et tout
combinaison de PE=n (lier n éléments de traitement à chaque proc), SPAN (équilibre de charge
les processus à travers l'allocation), OVERSUBSCRIBE (autoriser plus de processus sur un nœud
que des éléments de traitement), et NOOVERSUBSCRIBE. Cela inclut PPR, où le
pattern se terminerait par un autre deux-points pour le séparer des modificateurs.

-bycore, --bycore
Mapper les processus par cœur (déprécié au profit de --map-by core)

-par socket, --parsocket
Mapper les processus par socket (déprécié en faveur de --map-by socket)

-pas de local, --nolocal
N'exécutez aucune copie de l'application lancée sur le même nœud que orterun est
fonctionnement. Cette option remplacera la liste de l'hôte local avec --hôte ou tout autre
mécanisme de spécification de l'hôte.

-pas de surabonnement, --nooversubscribe
Ne sursouscrivez aucun nœud ; erreur (sans démarrer aucun processus) si le
nombre de processus demandé entraînerait un surabonnement. Cette option implicitement
définit "max_slots" égal à la valeur "slots" pour chaque nœud.

-bynode, --bynode
Lancer les processus un par nœud, en effectuant un cycle par nœud de manière circulaire. Cette
répartit les processus uniformément entre les nœuds et attribue les rangs MPI_COMM_WORLD dans un tour-
robin, de manière "par nœud".

Pour ordonner les rangs des processus dans MPI_COMM_WORLD :

--classement par
Classement à tour de rôle en fonction de l'objet spécifié, par défaut fente.
Les options prises en charge incluent slot, hwthread, core, L1cache, L2cache, L3cache, socket,
numa, board et node.

Pour la liaison de processus :

--lier à
Lier les processus à l'objet spécifié, par défaut core. Les options prises en charge incluent
slot, hwthread, core, l1cache, l2cache, l3cache, socket, numa, board et aucun.

-processeur-par-proc, --cpus-par-proc <#perproc>
Liez chaque processus au nombre spécifié de processeurs. (déprécié en faveur de --map-
par :PE=n)

-processeur-par-rang, --cpus-par-rang <#perrank>
Alias ​​pour -processeur-par-proc. (déprécié en faveur de --map-by :PE=n)

-lié au noyau, --bind-to-cœur
Lier les processus aux cœurs (déprécié en faveur de --bind-to core)

-lier-à-socket, --lier-à-socket
Lier les processus aux sockets du processeur (déprécié en faveur de --bind-to socket)

-lier-à-aucun, --bind-to-none
Ne pas lier les processus (déprécié en faveur de --bind-to none)

-rapport-liaisons, --liaisons-de-rapport
Signalez toutes les liaisons pour les processus lancés.

-liste-slot, --liste-emplacement
Liste des ID de processeur à utiliser pour lier les processus MPI. Les liaisons spécifiées
sera appliqué à tous les processus MPI. Voir l'explication ci-dessous pour la syntaxe.

Pour les fichiers de classement :

-rf, --classement
Fournissez un fichier de classement.

Pour gérer les E/S standard :

-nom-fichier-sortie, --put-filename
Rediriger la sortie stdout, stderr et stddiag de tous les processus vers un processus unique
version du nom de fichier spécifié. Tous les répertoires du nom de fichier seront
automatiquement être créé. Chaque fichier de sortie se composera de filename.id, où le
id sera le rang des processus dans MPI_COMM_WORLD, rempli à gauche de zéros pour
ordre correct dans les listes.

-stdin, --stdin
Le rang MPI_COMM_WORLD du processus qui doit recevoir stdin. La valeur par défaut est de
transmettre stdin à MPI_COMM_WORLD rang 0, mais cette option peut être utilisée pour transmettre
stdin à n'importe quel processus. Il est également acceptable de préciser aucun, indiquant que non
les processus doivent recevoir stdin.

-tag-sortie, --tag-sortie
Marquez chaque ligne de sortie sur stdout, stderr et stddiag avec [Jobid,
MCW_rank] indiquant le jobid du processus et le rang MPI_COMM_WORLD du
processus qui a généré la sortie, et le canal qui l'a généré.

-horodatage-sortie, --horodatage-sortie
Horodatage de chaque ligne de sortie sur stdout, stderr et stddiag.

-xml, --xml
Fournissez toutes les sorties à stdout, stderr et stddiag au format xml.

-xterm, --xterm
Afficher la sortie des processus identifiés par leurs rangs MPI_COMM_WORLD dans
fenêtres xterm séparées. Les rangs sont spécifiés sous la forme d'une liste séparée par des virgules de
plages, avec un -1 indiquant tout. Une fenêtre distincte sera créée pour chaque
processus spécifié. Remarque : xterm terminera normalement la fenêtre lors de la résiliation
du processus qui s'y déroule. Cependant, en ajoutant un "!" à la fin de la liste
des rangs spécifiés, les options appropriées seront fournies pour garantir que xterm conserve
la fenêtre ouverte après le processus se termine, vous permettant ainsi de voir le processus'
sortir. Chaque fenêtre xterm devra ensuite être fermée manuellement. Remarque : In
certains environnements, xterm peut exiger que l'exécutable soit dans le chemin de l'utilisateur, ou
être spécifié en termes absolus ou relatifs. Ainsi, il peut être nécessaire de spécifier un
exécutable local en tant que "./foo" au lieu de simplement "foo". Si xterm ne parvient pas à trouver le
exécutable, mpirun se bloquera, mais répondra toujours correctement à un ctrl-c. Si ce
se produit, veuillez vérifier que l'exécutable est spécifié correctement et essayez
nouveau.

Pour gérer les fichiers et l'environnement d'exécution :

-chemin, --chemin
qui sera utilisé lors de la tentative de localisation des exécutables demandés. Cette
est utilisé avant d'utiliser le paramètre PATH local.

--préfixe
Répertoire de préfixe qui sera utilisé pour définir le PATH et LD_LIBRARY_PATH sur le
nœud distant avant d'appeler Open MPI ou le processus cible. Voir la "Télécommande
Exécution", ci-dessous.

--preload-binaire
Copiez le ou les exécutables spécifiés sur des machines distantes avant de démarrer à distance
processus. Les exécutables seront copiés dans le répertoire de session Open MPI et
sera supprimé à la fin du travail.

--preload-files
Précharger la liste de fichiers séparés par des virgules dans le répertoire de travail actuel du
des machines distantes sur lesquelles les processus seront lancés avant de démarrer ces processus.

--preload-files-dest-dir
Le répertoire de destination à utiliser pour les fichiers de préchargement, s'il est différent du répertoire actuel
directeur de travail. Par défaut, les chemins absolus et relatifs fournis par
--preload-files sont utilisés.

--tmpdir
Définissez la racine de l'arborescence des répertoires de session pour mpirun uniquement.

-wd
synonyme de -wdir.

-wdir
Passer au répertoire avant l'exécution du programme utilisateur. Voir le "Actuel
Répertoire de travail" pour des notes sur les chemins relatifs. Remarque : Si la -wdir option
apparaît à la fois sur la ligne de commande et dans un contexte d'application, le contexte sera
ont priorité sur la ligne de commande. Ainsi, si le chemin vers le wdir souhaité est
différent sur les nœuds principaux, alors il doit être spécifié comme un chemin absolu qui
est correct pour le nœud principal.

-x
Exportez les variables d'environnement spécifiées vers les nœuds distants avant d'exécuter le
programme. Une seule variable d'environnement peut être spécifiée par -x option. Existant
les variables d'environnement peuvent être spécifiées ou de nouveaux noms de variables spécifiés avec
valeurs correspondantes. Par exemple:
% mpirun -x AFFICHAGE -x OFILE=/tmp/out ...

L'analyseur pour le -x l'option n'est pas très sophistiquée; il ne comprend même pas
valeurs citées. Il est conseillé aux utilisateurs de définir des variables dans l'environnement, puis d'utiliser
-x pour les exporter (pas les définir).

Réglage des paramètres MCA :

-gmca, --gmca
Transmettez les paramètres MCA globaux applicables à tous les contextes. est le
le nom du paramètre; est la valeur du paramètre.

-mca, --mca
Envoyez des arguments à divers modules MCA. Voir la section « MCA » ci-dessous.

Pour le débogage :

-déboguer, --déboguer
Appelez le débogueur de niveau utilisateur indiqué par le orte_base_user_debugger MCA
paramètre.

-débogueur, --débogueur
Séquence de débogueurs à rechercher quand --déboguer est utilisé (c'est-à-dire un synonyme de
orte_base_user_debugger paramètre MCA).

-la télé, --la télé
Lancez les processus sous le débogueur TotalView. Rétrocompatibilité obsolète
drapeau. synonyme de --déboguer.

Il y a aussi d'autres options :

--allow-run-as-root
Autoriser mpirun à exécuter lorsqu'il est exécuté par l'utilisateur root (mpirun par défaut à abandonner
lorsqu'il est lancé en tant qu'utilisateur root).

-avorté, --avorté <#>
Définissez le nombre maximal de processus abandonnés à afficher.

--application
Fournissez un fichier d'application, en ignorant toutes les autres options de ligne de commande.

-cf, --cartofile
Fournir un fichier de cartographie.

--hétéro
Indique que plusieurs app_contexts sont fournis qui sont un mélange de 32/64 bits
binaires.

-quitter-session-attaché, --laisser-session-attachée
Ne détachez pas les démons OmpiRTE utilisés par cette application. Cela permet des messages d'erreur
des démons ainsi que de l'environnement sous-jacent (par exemple, en cas d'échec de
lancer un démon) à afficher.

-ompi-serveur, --ompi-serveur <uri or fichier>
Spécifiez l'URI du serveur Open MPI (ou le mpirun à utiliser comme serveur) ,
le nom du fichier (spécifié comme file:filename) qui contient ces informations, ou le
PID (spécifié comme pid:#) du mpirun à utiliser comme
le serveur. Le serveur Open MPI est utilisé pour prendre en charge les données multi-applications
échange via les fonctions MPI-2 MPI_Publish_name et MPI_Lookup_name.

-rapport-pid, --rapport-pid
Imprimez le PID de mpirun au démarrage. Le canal doit être soit un '-' à indi
cate que le pid doit être sorti sur stdout, un '+' pour indiquer que le pid doit
être sorti vers stderr, ou un nom de fichier sur lequel le pid doit être écrit.

-rapport-uri, --report-uri
Imprimez l'URI de mpirun au démarrage. Le canal doit être soit un '-' à indi
cate que l'URI doit être sorti sur stdout, un '+' pour indiquer que l'URI doit être
être sorti vers stderr, ou un nom de fichier sur lequel l'URI doit être écrit.

-attendre-le-serveur, --attendre-le-serveur
Suspendez mpirun avant de lancer le travail jusqu'à ce que ompi-server soit détecté. C'est utile
dans les scripts où ompi-server peut être démarré en arrière-plan, suivi immédiatement
par un mpirun commande qui souhaite s'y connecter. Mpirun fera une pause jusqu'à ce que l'un ou l'autre
le serveur ompi spécifié est contacté ou le temps d'attente du serveur est dépassé.

-serveur-temps d'attente, --server-temps d'attente
La durée maximale (en secondes) pendant laquelle mpirun doit attendre que le serveur ompi
début. La valeur par défaut est de 10 secondes.

Les options suivantes sont utiles pour les développeurs ; ils ne sont généralement pas utiles à la plupart
Utilisateurs ORTE et/ou MPI :

-d, --debug-développement
Activer le débogage de l'OmpiRTE (la couche d'exécution dans Open MPI). Ce n'est pas
généralement utile pour la plupart des utilisateurs.

--debug-démons
Activez le débogage de tous les démons OmpiRTE utilisés par cette application.

--debug-daemons-fichier
Activer le débogage de tous les démons OmpiRTE utilisés par cette application, en stockant la sortie dans
fichiers.

-agent-de-lancement, --agent-de-lancement
Nom de l'exécutable à utiliser pour démarrer les processus sur les nœuds distants.
La valeur par défaut est "orted". Cette option peut être utilisée pour tester de nouveaux concepts de démons, ou pour
transmettre les options aux démons sans que mpirun lui-même les voie. Pour
exemple, spécifier un agent de lancement de orted -mca odls_base_verbose 5 permet le
développeur de demander à orted de déboguer la sortie sans encombrement de mpirun lui-même.

--pas de préfixe
Désactiver le comportement automatique --prefix

Il peut y avoir d'autres options répertoriées avec mpirun --Aidez-moi.

Environnement Variables
MPIEXEC_TIMEOUT
Le nombre maximum de secondes qui mpirun (mpiexec) s'exécutera. Après tant de
secondes, mpirun abandonnera le travail lancé et quittera.

DESCRIPTION

Une invocation de mpirun démarre une application MPI s'exécutant sous Open MPI. Si la
l'application est un processus unique de données multiples (SPMD), l'application peut être spécifiée sur
le mpirun ligne de commande.

Si l'application est de multiples données d'instructions (MIMD), comprenant plusieurs
programmes, l'ensemble des programmes et des arguments peut être spécifié de l'une des deux manières suivantes :
Arguments de ligne de commande et contexte d'application.

Un contexte d'application décrit l'ensemble de programmes MIMD, y compris tous les arguments d'un
fichier séparé. Ce fichier contient essentiellement plusieurs mpirun lignes de commande, moins le
le nom de la commande lui-même. La possibilité de spécifier différentes options pour différents
instanciations d'un programme est une autre raison d'utiliser un contexte d'application.

Les arguments de ligne de commande étendus permettent la description de la mise en page de l'application sur le
ligne de commande en utilisant les deux points (:) pour séparer la spécification des programmes et des arguments.
Certaines options sont définies globalement dans tous les programmes spécifiés (par exemple --hostfile), tandis que
d'autres sont spécifiques à un seul programme (par exemple -np).

Spécification Hôte Nodes
Les nœuds hôtes peuvent être identifiés sur le mpirun ligne de commande avec le -hôte option ou dans un
fichier hôte.

Par exemple,

mpirun -H aa,aa,bb ./a.out
lance deux processus sur le nœud aa et un sur bb.

Ou, considérez le fichier host

% chat myhostfile
aa emplacements=2
emplacements bb=2
emplacements cc=2

Ici, nous listons à la fois les noms d'hôtes (aa, bb et cc) mais aussi le nombre de "slots" pour
chaque. Les slots indiquent combien de processus peuvent potentiellement s'exécuter sur un nœud. Pour le meilleur
performances, le nombre de slots peut être choisi pour être le nombre de cœurs sur le nœud ou
le nombre de sockets de processeur. Si le fichier hôte ne fournit pas d'informations sur les emplacements, un
la valeur par défaut 1 est supposée. Lors de l'exécution sous des gestionnaires de ressources (par exemple, SLURM, Torque,
etc.), Open MPI obtiendra à la fois les noms d'hôtes et le nombre de slots directement à partir du
gestionnaire de ressources.

mpirun -hostfile monhostfile ./a.out
lancera deux processus sur chacun des trois nœuds.

mpirun -hostfile monhostfile -host aa ./a.out
lancera deux processus, tous deux sur le nœud aa.

mpirun -hostfile monhostfile -host dd ./a.out
ne trouvera aucun hôte sur lequel s'exécuter et abandonnera avec une erreur. C'est-à-dire que l'hôte spécifié dd
n'est pas dans le fichier hôte spécifié.

Spécification Numéro of Processus
Comme nous venons de le voir, le nombre de processus à exécuter peut être défini à l'aide du fichier host. Autre
des mécanismes existent.

Le nombre de processus lancés peut être spécifié comme un multiple du nombre de nœuds ou
sockets de processeur disponibles. Par exemple,

mpirun -H aa,bb -npersocket 2 ./a.out
lance les processus 0-3 sur le nœud aa et le processus 4-7 sur le nœud bb, où aa et bb sont tous les deux
nœuds à double socket. Les -npersocket l'option active également le -lier-à-socket option,
qui est discuté dans une section ultérieure.

mpirun -H aa,bb -npernode 2 ./a.out
lance les processus 0-1 sur le nœud aa et les processus 2-3 sur le nœud bb.

mpirun -H aa,bb -npernode 1 ./a.out
lance un processus par nœud hôte.

mpirun -H aa,bb -pernode ./a.out
est la même que -npernode 1.

Une autre alternative est de spécifier le nombre de processus avec le -np option. Envisager
maintenant le fichier host

% chat myhostfile
aa emplacements=4
emplacements bb=4
emplacements cc=4

Maintenant,

mpirun -hostfile monhostfile -np 6 ./a.out
lancera les processus 0-3 sur le nœud aa et les processus 4-5 sur le nœud bb. Le reste
les emplacements dans le fichier hôte ne seront pas utilisés car le -np option indiquait que seulement 6
les processus devraient être lancés.

Cartographie Processus à noeuds: En utilisant Politiques internes
Les exemples ci-dessus illustrent le mappage par défaut des processus de processus aux nœuds. Cette
la cartographie peut également être contrôlée avec divers mpirun options qui décrivent les stratégies de mappage.

Considérez le même fichier hôte que ci-dessus, encore une fois avec -np 6:

nœud aa nœud bb nœud cc

mpirun 0 1 2 3 4 5

mpirun --map-by nœud 0 3 1 4 2 5

mpirun-nolocal 0 1 2 3 4 5

Votre --map-par nœud L'option équilibrera la charge des processus sur les nœuds disponibles,
numéroter chaque processus de manière circulaire.

Votre -pas de local L'option empêche tout processus d'être mappé sur l'hôte local (dans ce
nœud de cas aa). Tandis que mpirun consomme généralement peu de ressources système, -pas de local peuvent être
utile pour lancer de très gros travaux où mpirun peut en fait avoir besoin d'utiliser notable
quantités de mémoire et/ou de temps de traitement.

De même que -np peut spécifier moins de processus qu'il n'y a de slots, il peut également sursouscrire
les fentes. Par exemple, avec le même fichier hôte :

mpirun -hostfile monhostfile -np 14 ./a.out
lancera les processus 0-3 sur le nœud aa, 4-7 sur bb et 8-11 sur cc. Il ajoutera ensuite le
les deux processus restants vers les nœuds qu'il choisit.

On peut également spécifier des limites au surabonnement. Par exemple, avec le même fichier hôte :

mpirun -hostfile monhostfile -np 14 -nooversubscribe ./a.out
produira une erreur car -pas de surabonnement empêche le surabonnement.

Les limites de surabonnement peuvent également être spécifiées dans le fichier hôte lui-même :
% cat monfichierhôte
aa emplacements = 4 max_slots = 4
bb max_slots = 4
emplacements cc=4

Votre max_slots champ spécifie une telle limite. Quand c'est le cas, le fentes la valeur par défaut est la
limite. Maintenant:

mpirun -hostfile monhostfile -np 14 ./a.out
provoque le lancement des 12 premiers processus comme avant, mais les deux autres
les processus seront forcés sur le nœud cc. Les deux autres nœuds sont protégés par le
hostfile contre la sursouscription par ce travail.

Le --nooversubscribe L'option peut être utile car Open MPI n'obtient actuellement pas
valeurs "max_slots" du gestionnaire de ressources.

Bien sûr, -np peut également être utilisé avec le -H or -hôte option. Par example,

mpirun -H aa,bb -np 8 ./a.out
lance 8 processus. Étant donné que seuls deux hôtes sont spécifiés, après les deux premiers
les processus sont mappés, un sur aa et un sur bb, les processus restants sursouscrivent
les hôtes spécifiés.

Et voici un exemple MIMD :

mpirun -H aa -np 1 nom d'hôte : -H bb,cc -np 2 disponibilité
lancera le processus 0 en cours d'exécution nom d'hôte sur le nœud aa et les processus 1 et 2 en cours d'exécution
Stabilité sur les nœuds bb et cc, respectivement.

Cartographie, Classement, et Reliure: Oh Mon!
Open MPI utilise une procédure en trois phases pour attribuer les emplacements et les rangs des processus :

cartographie Attribue un emplacement par défaut à chaque processus

classement Attribue une valeur de classement MPI_COMM_WORLD à chaque processus

propriétés de liant Contraint chaque processus à s'exécuter sur des processeurs spécifiques

Votre cartographie étape est utilisée pour attribuer un emplacement par défaut à chaque processus en fonction du mappeur
étant employé. Le mappage par emplacement, nœud et séquentiellement entraîne l'affectation du
processus au niveau du nœud. En revanche, le mappage par objet permet au mappeur d'attribuer
le processus à un objet réel sur chaque nœud.

Remarque : l'emplacement attribué au processus est indépendant de l'endroit où il sera lié - le
l'affectation est utilisée uniquement comme entrée de l'algorithme de liaison.

Le mappage des processus de processus aux nœuds peut être défini non seulement avec des politiques générales
mais aussi, si nécessaire, en utilisant des mappages arbitraires qui ne peuvent être décrits par un simple
politique. On peut utiliser le "sequential mapper", qui lit le fichier hôte ligne par ligne,
affecter des processus aux nœuds dans l'ordre spécifié par le fichier hôte. Utilisez le -mca rmaps
suivants option. Par exemple, en utilisant le même fichier hôte qu'avant :

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

lancera trois processus, un sur chacun des nœuds aa, bb et cc, respectivement. La fente
les comptes n'ont pas d'importance ; un processus est lancé par ligne sur n'importe quel nœud répertorié sur le
ligne.

Une autre façon de spécifier des mappages arbitraires consiste à utiliser un fichier de classement, qui vous donne des détails
contrôle également sur la liaison de processus. Les fichiers de classement sont discutés ci-dessous.

La deuxième phase se concentre sur la classement du processus dans le MPI_COMM_WORLD du travail.
Open MPI sépare cela de la procédure de mappage pour permettre plus de flexibilité dans le
placement relatif des processus MPI. Ceci est mieux illustré en considérant ce qui suit
deux cas où nous avons utilisé l'option —map-by ppr:2:socket :

nœud aa nœud bb

rang par noyau 0 1 ! 2 3 4 5 ! 6 7

prise rang par 0 2 ! 1 3 4 6 ! 5 7

prise rang par:span 0 4 ! 1 5 2 6 ! 3 7

Le classement par cœur et par slot donne le même résultat - une simple progression de
MPI_COMM_WORLD se classe sur chaque nœud. Le classement par socket effectue un classement à tour de rôle au sein
chaque nœud jusqu'à ce que tous les processus aient reçu un rang MCW, puis progresse vers le
nœud suivant. Ajout du envergure le modificateur à la directive de classement provoque l'algorithme de classement
traiter l'intégralité de l'allocation comme une seule entité - ainsi, les rangs MCW sont attribués
sur toutes les prises avant de revenir au début.

Votre propriétés de liant phase lie en fait chaque processus à un ensemble donné de processeurs. Ceci peut
améliorer les performances si le système d'exploitation place les processus de manière sous-optimale. Pour
Par exemple, il peut sursouscrire certains sockets de processeur multicœur, laissant d'autres sockets
inactif; cela peut conduire les processus à se disputer inutilement des ressources communes. Ou, il
pourrait étendre les processus trop largement ; cela peut être sous-optimal si les performances de l'application
est sensible aux coûts de communication interprocessus. La reliure peut également garder le fonctionnement
système de migration excessive des processus, quelle que soit l'optimalité de ces processus
ont été placés pour commencer.

Les processeurs à utiliser pour la liaison peuvent être identifiés en termes de groupements topologiques
- par exemple, la liaison à un l3cache liera chaque processus à tous les processeurs dans le cadre de
un seul cache L3 dans leur emplacement assigné. Ainsi, si un processus est assigné par le
mappeur à un certain socket, puis un -lier à l3cache directive entraînera le processus
lié aux processeurs qui partagent un seul cache L3 dans ce socket.

Pour aider à équilibrer les charges, la directive de liaison utilise une méthode circulaire lors de la liaison à
niveaux inférieurs à ceux utilisés dans le mappeur. Par exemple, considérons le cas où un travail est mappé
au niveau du socket, puis lié au noyau. Chaque socket aura plusieurs cœurs, donc si
plusieurs processus sont mappés sur un socket donné, l'algorithme de liaison affectera chacun
processus situé sur un socket à un noyau unique d'une manière circulaire.

Alternativement, les processus mappés par l2cache puis liés à la socket seront simplement liés
à tous les processeurs du socket où ils se trouvent. De cette manière, les utilisateurs peuvent
exercer un contrôle détaillé sur l'emplacement et la liaison du rang MCW relatif.

Enfin, --liaisons-de-rapport peut être utilisé pour signaler les liaisons.

À titre d'exemple, considérons un nœud avec deux sockets de processeur, chacun comprenant quatre cœurs. Nous
courir mpirun avec -np 4 --liaisons-de-rapport et les options supplémentaires suivantes :

% mpirun ... --map-by core --bind-to core
[...] ... liaison enfant [...,0] au processeur 0001
[...] ... liaison enfant [...,1] au processeur 0002
[...] ... liaison enfant [...,2] au processeur 0004
[...] ... liaison enfant [...,3] au processeur 0008

% mpirun ... --map-by socket --bind-to socket
[...] ... liaison enfant [...,0] au socket 0 CPU 000f
[...] ... liaison de l'enfant [...,1] au processeur socket 1 00f0
[...] ... liaison enfant [...,2] au socket 0 CPU 000f
[...] ... liaison de l'enfant [...,3] au processeur socket 1 00f0

% mpirun ... --map-by core:PE=2 --bind-to core
[...] ... liaison enfant [...,0] au processeur 0003
[...] ... liaison enfant [...,1] au processeur 000c
[...] ... liaison enfant [...,2] au processeur 0030
[...] ... liaison enfant [...,3] au processeur 00c0

% mpirun ... --bind-to none

Ici, --liaisons-de-rapport montre la liaison de chaque processus sous forme de masque. Dans le premier cas,
les processus se lient à des noyaux successifs comme indiqué par les masques 0001, 0002, 0004, et
0008. Dans le second cas, les processus se lient à tous les cœurs sur les sockets successifs comme indiqué
par les masques 000f et 00f0. Les processus parcourent les sockets du processeur en boucle.
robin fashion autant de fois que nécessaire. Dans le troisième cas, les masques nous montrent que 2
les noyaux ont été liés par processus. Dans le quatrième cas, la liaison est désactivée et aucun
les liaisons sont signalées.

La prise en charge par Open MPI de la liaison de processus dépend du système d'exploitation sous-jacent.
Par conséquent, certaines options de liaison de processus peuvent ne pas être disponibles sur tous les systèmes.

La liaison de processus peut également être définie avec les paramètres MCA. Leur utilisation est moins pratique que
de mpirun option. D'autre part, les paramètres MCA peuvent être réglés non seulement sur le
mpirun ligne de commande, mais alternativement dans un fichier système ou utilisateur mca-params.conf ou en tant que
variables d'environnement, comme décrit dans la section MCA ci-dessous. Voici quelques exemples :

option mpirun valeur de la clé du paramètre MCA

--map-by noyau rmaps_base_mapping_policy noyau
--map-by socket rmaps_base_mapping_policy socket
--rang-par noyau rmaps_base_ranking_policy noyau
--bind-to noyau hwloc_base_binding_policy noyau
--bind-to socket socket hwloc_base_binding_policy
--bind-to aucun hwloc_base_binding_policy aucun

Fichiers de classement
Les fichiers de classement sont des fichiers texte qui spécifient des informations détaillées sur la façon dont les processus individuels
doivent être mappés sur des nœuds et à quel(s) processeur(s) ils doivent être liés. Chaque ligne d'un
rankfile spécifie l'emplacement d'un processus (pour les travaux MPI, le "rang" du processus fait référence
à son rang dans MPI_COMM_WORLD). La forme générale de chaque ligne du fichier de classement est :

rang = emplacement =

Par exemple :

$ cat mon fichier de classement
rang 0=aa slot=1:0-2
rang 1=bb slot=0:0,1
rang 2=cc slot=1-2
$ mpirun -H aa,bb,cc,dd -rf monfichierderang ./a.out

Signifie que

Le rang 0 s'exécute sur le nœud aa, lié au socket logique 1, les cœurs 0-2.
Le rang 1 s'exécute sur le nœud bb, lié au socket logique 0, aux cœurs 0 et 1.
Le rang 2 s'exécute sur le nœud cc, lié aux cœurs logiques 1 et 2.

Les fichiers de classement peuvent également être utilisés pour spécifier Physique emplacements des processeurs. Dans ce cas,
la syntaxe est quelque peu différente. Les sockets ne sont plus reconnus et le numéro d'emplacement
donné doit être le numéro de l'unité centrale physique car la plupart des systèmes d'exploitation n'attribuent pas de physique unique
identifiant à chaque cœur du nœud. Ainsi, un fichier de classement physique approprié ressemble à quelque chose comme
ce qui suit:

$ cat monfichierderangphysique
rang 0=aa emplacement=1
rang 1=bb slot=8
rang 2 = emplacement cc = 6

Cela signifie que

Le rang 0 s'exécutera sur le nœud aa, lié au noyau qui contient le PU physique 1
Le rang 1 s'exécutera sur le nœud bb, lié au noyau qui contient le PU physique 8
Le rang 2 s'exécutera sur le nœud cc, lié au noyau qui contient le PU physique 6

Les fichiers de classement sont traités comme logique par défaut, et le paramètre MCA
rmaps_rank_file_physical doit être défini sur 1 pour indiquer que le fichier de classement doit être
considéré comme Physique.

Les noms d'hôtes répertoriés ci-dessus sont « absolus », ce qui signifie que les noms d'hôtes réels résolvables sont
spécifié. Cependant, les noms d'hôte peuvent également être spécifiés comme « relatifs », ce qui signifie qu'ils sont
spécifié par rapport à une liste externe de noms d'hôtes (par exemple, par mpirun's
--host, un fichier hôte ou un planificateur de travaux).

La spécification "relative" est de la forme "+n ", où X est un entier spécifiant le
Xème nom d'hôte dans l'ensemble de tous les noms d'hôte disponibles, indexé à partir de 0. Par exemple :

$ cat mon fichier de classement
rank 0=+n0 slot=1:0-2
rang 1=+n1 emplacement=0:0,1
rang 2=+n2 emplacement=1-2
$ mpirun -H aa,bb,cc,dd -rf monfichierderang ./a.out

À partir de Open MPI v1.7, tous les emplacements de socket/noyau sont spécifiés comme logique
index (la série Open MPI v1.6 utilisée Physique index). Vous pouvez utiliser des outils tels que
"lstopo" de HWLOC pour trouver les index logiques des sockets et des cœurs.

Application Contexte or Exécutable Programme?
Pour distinguer les deux formes différentes, mpirun cherche sur la ligne de commande pour --application option.
S'il est spécifié, le fichier nommé sur la ligne de commande est supposé être un
contexte applicatif. S'il n'est pas spécifié, le fichier est supposé être un exécutable
.

Localisation Fichiers
Si aucun chemin relatif ou absolu n'est spécifié pour un fichier, Open MPI recherchera d'abord
fichiers en recherchant les répertoires spécifiés par le --chemin option. Si il n'y a pas --chemin
jeu d'options ou si le fichier n'est pas trouvé au --chemin emplacement, puis Open MPI recherchera
la variable d'environnement PATH de l'utilisateur telle que définie sur le(s) nœud(s) source(s).

Si un répertoire relatif est spécifié, il doit être relatif au répertoire de travail initial
déterminé par le démarreur spécifique utilisé. Par exemple, lors de l'utilisation des démarreurs rsh ou ssh,
le répertoire initial est $HOME par défaut. D'autres débutants peuvent définir le répertoire initial sur
le répertoire de travail courant depuis l'invocation de mpirun.

Courant Working : un espace de travail commun Annuaire
Votre -wdir option mpirun (et son synonyme, -wd) permet à l'utilisateur de passer à un arbitraire
répertoire avant l'appel du programme. Il peut également être utilisé dans les fichiers de contexte d'application
pour spécifier des répertoires de travail sur des nœuds spécifiques et/ou pour des applications spécifiques.

Si la -wdir apparaît à la fois dans un fichier de contexte et sur la ligne de commande, le contexte
répertoire de fichiers remplacera la valeur de la ligne de commande.

Si la -wdir est spécifiée, Open MPI tentera de passer à l'option spécifiée
répertoire sur tous les nœuds distants. Si cela échoue, mpirun va avorter.

Si la -wdir option est pas spécifié, Open MPI enverra le nom du répertoire où mpirun
a été invoqué sur chacun des nœuds distants. Les nœuds distants essaieront de changer pour cela
annuaire. S'ils sont incapables (par exemple, si le répertoire n'existe pas sur ce nœud), alors
Open MPI utilisera le répertoire par défaut déterminé par le démarreur.

Tout changement de répertoire se produit avant que le programme de l'utilisateur ne soit appelé ; il n'attend pas
MPI_INIT est appelé.

Standard I / O
Open MPI dirige l'entrée standard UNIX vers /dev/null sur tous les processus sauf le
Processus MPI_COMM_WORLD de rang 0. Le processus MPI_COMM_WORLD de rang 0 hérite de l'entrée standard
de mpirun. Remarque : Le nœud qui a invoqué mpirun n'a pas besoin d'être le même que le nœud où
le processus MPI_COMM_WORLD de rang 0 réside. Open MPI gère la redirection de mpirun's
entrée standard au processus de rang 0.

Open MPI dirige la sortie standard UNIX et l'erreur des nœuds distants vers le nœud qui a appelé
mpirun et l'imprime sur la sortie/erreur standard de mpirun. Les processus locaux héritent de la
sortie standard/erreur de mpirun et y transférer directement.

Ainsi, il est possible de rediriger les E/S standard pour les applications Open MPI en utilisant le
procédure de redirection de shell typique sur mpirun.

% mpirun -np 2 mon_app < ​​mon_entrée > ma_sortie

Notez que dans cet exemple uniquement le processus MPI_COMM_WORLD de rang 0 recevra le flux
de mon_entrée sur stdin. Le stdin sur tous les autres nœuds sera lié à /dev/null.
Cependant, la sortie standard de tous les nœuds sera collectée dans le ma_sortie fichier.

Signal Propagation
Lorsque orterun reçoit un SIGTERM et un SIGINT, il tentera de tuer l'ensemble du travail en
envoyer à tous les processus du travail un SIGTERM, attendre un petit nombre de secondes, puis
envoyer un SIGKILL à tous les processus du travail.

Les signaux SIGUSR1 et SIGUSR2 reçus par orterun sont propagés à tous les processus du
d'emplois.

On peut activer le renvoi de SIGSTOP et SIGCONT au programme exécuté par mpirun par
en définissant le paramètre MCA orte_forward_job_control sur 1. Un signal SIGTSTOP envoyé à mpirun
puis provoque l'envoi d'un signal SIGSTOP à tous les programmes démarrés par mpirun et
de même, un signal SIGCONT à mpirun provoquera l'envoi d'un SIGCONT.

Les autres signaux ne sont actuellement pas propagés par orterun.

Processus Résiliation / Signal Maniabilité
Pendant l'exécution d'une application MPI, si un processus meurt anormalement (soit en quittant
avant d'invoquer MPI_FINALISER, ou mourir à la suite d'un signal), mpirun imprimera
un message d'erreur et tuez le reste de l'application MPI.

Les gestionnaires de signaux utilisateur devraient probablement éviter d'essayer de nettoyer l'état MPI (Open MPI est
actuellement pas asynchrone-sécurisé ; voir MPI_Init_thread(3) pour plus de détails sur
MPI_THREAD_MULTIPLE et la sécurité du fil). Par exemple, si un défaut de segmentation se produit dans
MPI_SEND (peut-être parce qu'un mauvais tampon a été transmis) et un gestionnaire de signal utilisateur est
invoqué, si ce gestionnaire d'utilisateur tente d'invoquer MPI_FINALISER, de mauvaises choses pourraient arriver
puisque Open MPI était déjà "dans" MPI lorsque l'erreur s'est produite. Depuis mpirun remarquerez
que le processus est mort à cause d'un signal, il n'est probablement pas nécessaire (et le plus sûr) pour le
à l'utilisateur de nettoyer uniquement l'état non-MPI.

Processus Environnement
Les processus de l'application MPI héritent de leur environnement du démon Open RTE lors
le nœud sur lequel ils s'exécutent. L'environnement est généralement hérité de la
shell de l'utilisateur. Sur les nœuds distants, l'environnement exact est déterminé par le module MCA de démarrage
utilisé. Les rsh le module de lancement, par exemple, utilise soit rsh/ssh pour lancer l'Open RTE
démon sur les nœuds distants et exécute généralement un ou plusieurs fichiers de configuration du shell de l'utilisateur
avant de lancer le démon Open RTE. Lors de l'exécution d'applications liées dynamiquement qui
exiger le LD_LIBRARY_PATH variable d'environnement à définir, il faut prendre soin de s'assurer
qu'il est correctement défini lors du démarrage d'Open MPI.

Voir la section "Exécution à distance" pour plus de détails.

Remote Internationaux
Open MPI requiert que le PATH variable d'environnement être définie pour trouver des exécutables à distance
nœuds (cela n'est généralement nécessaire que dans rsh- ou ssh-environnements basés --
les environnements batch/planifiés copient généralement l'environnement actuel vers l'exécution de
tâches distantes, donc si l'environnement actuel a PATH et/ou LD_LIBRARY_PATH bien réglé,
les nœuds distants l'auront également configuré correctement). Si Open MPI a été compilé avec partagé
support de la bibliothèque, il peut également être nécessaire d'avoir le LD_LIBRARY_PATH variable d'environnement
défini sur les nœuds distants également (en particulier pour trouver les bibliothèques partagées requises pour exécuter l'utilisateur
applications MPI).

Cependant, il n'est pas toujours souhaitable ou possible de modifier les fichiers de démarrage du shell pour définir PATH
et/ou LD_LIBRARY_PATHL’ --préfixe option est fournie pour certaines configurations simples
où cela n'est pas possible.

Votre --préfixe L'option prend un seul argument : le répertoire de base sur le nœud distant où
Open MPI est installé. Open MPI utilisera ce répertoire pour définir la télécommande PATH et
LD_LIBRARY_PATH avant d'exécuter toute application Open MPI ou utilisateur. Cela permet de courir
Ouvrir des jobs MPI sans avoir préconfiguré le PATH et LD_LIBRARY_PATH sur la télécommande
nœuds.

Open MPI ajoute le nom de base du "bindir" du nœud actuel (le répertoire où Open MPI
exécutables sont installés) au préfixe et l'utilise pour définir le PATH sur le nœud distant.
De même, Open MPI ajoute le nom de base du "libdir" du nœud actuel (le répertoire où
Les bibliothèques Open MPI sont installées) au préfixe et l'utilise pour définir le LD_LIBRARY_PATH
sur le nœud distant. Par exemple:

Bindir local : /local/node/directory/bin

Répertoire de bibliothèque local : /local/node/directory/lib64

Si la ligne de commande suivante est utilisée :

% mpirun --prefix /distant/nœud/répertoire

Open MPI ajoutera "/remote/node/directory/bin" au PATH et
"/remote/node/directory/lib64" au D_LIBRARY_PATH sur le nœud distant avant de tenter
d'exécuter quoi que ce soit.

Votre --préfixe L'option n'est pas suffisante si les chemins d'installation sur le nœud distant sont
différent du nœud local (par exemple, si "/ lib" est utilisé sur le nœud local, mais "/lib64" est
utilisé sur le nœud distant), ou si les chemins d'installation sont autre chose qu'un
sous-répertoire sous un préfixe commun.

Notez que l'exécution mpirun via un chemin d'accès absolu équivaut à spécifier --préfixe
sans le dernier sous-répertoire dans le chemin absolu vers mpirun. Par exemple:

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

équivaut à

% mpirun --préfixe / Usr / local

Exporté Environnement Variables
Toutes les variables d'environnement nommées sous la forme OMPI_* seront automatiquement exportées
à de nouveaux processus sur les nœuds locaux et distants. Les paramètres environnementaux peuvent également être
défini/transmis aux nouveaux processus à l'aide du paramètre MCA mca_base_env_listL’ -x
Option de mpirun a été déprécié, mais la syntaxe du paramètre MCA suit celle antérieure
Exemple. Alors que la syntaxe du -x option et MCA param permet la définition de nouveaux
variables, notez que l'analyseur de ces options n'est actuellement pas très sophistiqué -
il ne comprend même pas les valeurs citées. Il est conseillé aux utilisateurs de définir des variables dans le
environnement et utilisez l'option pour les exporter ; de ne pas les définir.

Paramètres MCA Paramètres
Votre -mca switch permet le passage de paramètres à divers MCA (Modular Component
modules d'architecture). Les modules MCA ont un impact direct sur les programmes MPI car ils permettent
paramètres réglables à définir au moment de l'exécution (tels que le pilote de périphérique de communication BTL à
utiliser, quels paramètres passer à ce BTL, etc.).

Votre -mca switch prend deux arguments : et L’ argumentation en général
spécifie quel module MCA recevra la valeur. Par exemple, le "btl" est utilisé
pour sélectionner la BTL à utiliser pour le transport des messages MPI. Les l'argument est le
valeur qui est passée. Par exemple:

mpirun -mca btl tcp, self -np 1 foo
Indique à Open MPI d'utiliser les BTL "tcp" et "self" et d'exécuter une seule copie de "foo" an
nœud alloué.

mpirun -mca btl self -np 1 foo
Indique à Open MPI d'utiliser la BTL "self" et d'exécuter une seule copie de "foo" un alloué
nœud.

Votre -mca le commutateur peut être utilisé plusieurs fois pour spécifier différents et/ou
arguments. Si le même est spécifié plus d'une fois, le s sont concaténés
avec une virgule (",") les séparant.

Notez que le -mca switch est simplement un raccourci pour définir des variables d'environnement. Les
le même effet peut être obtenu en définissant les variables d'environnement correspondantes avant
Running mpirun. La forme des variables d'environnement définies par Open MPI est :

OMPI_MCA_ =

Ainsi, le -mca switch remplace toutes les variables d'environnement précédemment définies. Les -mca
les paramètres remplacent de la même manière les paramètres MCA définis dans $OPAL_PREFIX/etc/openmpi-mca-
params.conf ou $HOME/.openmpi/mca-params.conf.

Inconnu les arguments sont toujours définis comme variable d'environnement -- ils ne sont pas vérifiés (par
mpirun) pour l'exactitude. Illégal ou incorrect les arguments peuvent être ou non
signalé -- cela dépend du module MCA spécifique.

Pour trouver les types de composants disponibles sous l'architecture MCA, ou pour trouver les
paramètres pour un composant spécifique, utilisez le ompi_info commander. Voir le ompi_info(1) man
page pour des informations détaillées sur la commande.

Fonctionnement as racine
L'équipe Open MPI déconseille fortement d'exécuter mpirun en tant qu'utilisateur root. MPI
les applications doivent être exécutées en tant qu'utilisateurs normaux (non root).

Reflétant ce conseil, mpirun refusera de s'exécuter en tant que root par défaut. Pour outrepasser cela
par défaut, vous pouvez ajouter le --allow-run-as-root option à la mpirun ligne de commande.

Sortie statuts
Il n'y a pas de définition standard de ce que mpirun devrait revenir comme état de sortie. Après
longue discussion, nous avons opté pour la méthode suivante pour attribuer les mpirun sortie
statut (remarque : dans la description suivante, le poste « principal » est la candidature initiale
démarré par mpirun - tous les travaux générés par ce travail sont désignés "secondaires"
travaux):

· si tous les processus du travail principal se terminent normalement avec le statut de sortie 0, nous renvoyons 0

· si un ou plusieurs processus du travail principal se terminent normalement avec une sortie différente de zéro
status, nous retournons l'état de sortie du processus avec le rang MPI_COMM_WORLD le plus bas à
avoir un statut non nul

· si tous les processus du travail principal se terminent normalement avec le statut de sortie 0, et un ou
plus de processus dans un travail secondaire se terminent normalement avec un état de sortie différent de zéro, nous (a)
retourner l'état de sortie du processus avec le rang MPI_COMM_WORLD le plus bas dans le plus bas
jobid pour avoir un état différent de zéro, et (b) afficher un message résumant l'état de sortie de
les emplois primaires et tous les emplois secondaires.

· si l'option de ligne de commande --report-child-jobs-separately est définie, nous renverrons -seulement- le
état de sortie du travail principal. Tout statut de sortie différent de zéro dans les tâches secondaires sera
rapportés uniquement dans un relevé récapitulatif imprimé.

Par défaut, l'OMPI enregistre et note que les processus MPI se sont terminés avec une terminaison non nulle
statut. Ceci n'est généralement pas considéré comme une "résiliation anormale" - c'est-à-dire que l'OMPI ne
abandonner un travail MPI si un ou plusieurs processus renvoient un état différent de zéro. Au lieu de cela, la valeur par défaut
le comportement rapporte simplement le nombre de processus se terminant avec un statut différent de zéro lors de
l'achèvement du travail.

Cependant, dans certains cas, il peut être souhaitable d'interrompre le travail lorsqu'un processus
se termine avec un statut différent de zéro. Par exemple, un travail non-MPI peut détecter un mauvais résultat de
un calcul et souhaite abandonner, mais ne veut pas générer de fichier core. Ou un emploi MPI
peut continuer après un appel à MPI_Finalize, mais indiquer que tous les processus doivent abandonner
en raison de certains résultats post-MPI.

Il n'est pas prévu que cette situation se reproduise fréquemment. Cependant, dans l'intérêt
de servir la communauté au sens large, l'OMPI dispose désormais d'un moyen pour permettre aux utilisateurs de diriger cette
les travaux soient abandonnés lors de la sortie de tout processus avec un statut différent de zéro. Réglage du paramètre MCA
"orte_abort_on_non_zero_status" à 1 obligera l'OMPI à abandonner tous les processus une fois
processus
sorties avec un statut différent de zéro.

Les résiliations causées de cette manière seront signalées sur la console comme un "
terminaison", avec le premier processus à sortir ainsi identifié avec son état de sortie.

EXEMPLES

Assurez-vous également de voir les exemples dans les sections ci-dessus.

mpirun -np 4 -mca btl ib, tcp, self prog1
Exécutez 4 copies de prog1 en utilisant les BTL "ib", "tcp" et "self" pour le transport de MPI
des messages.

mpirun -np 4 -mca btl tcp, sm, soi
--mca btl_tcp_if_include eth0 prog1
Exécuter 4 copies de prog1 en utilisant les BTL « tcp », « sm » et « self » pour le transport de MPI
messages, TCP utilisant uniquement l'interface eth0 pour communiquer. Notez que d'autres BTL
ont des paramètres MCA if_include similaires.

RETOUR VALEURE

mpirun renvoie 0 si tous les processus démarrés par mpirun quitter après avoir appelé MPI_FINALIZE. UNE
une valeur non nulle est renvoyée si une erreur interne s'est produite dans mpirun, ou une ou plusieurs
les processus se sont terminés avant d'appeler MPI_FINALIZE. Si une erreur interne s'est produite dans mpirun,
le code d'erreur correspondant est renvoyé. Dans le cas où un ou plusieurs processus se terminent
avant d'appeler MPI_FINALIZE, la valeur de retour du rang MPI_COMM_WORLD du processus
qui mpirun les premiers avis morts avant d'appeler MPI_FINALIZE seront renvoyés. Noter que,
en général, ce sera le premier processus qui est mort, mais il n'est pas garanti qu'il en soit ainsi.

Utilisez mpiexec.openmpi en ligne à l'aide des services onworks.net