orterun - Online w chmurze

PROGRAM:

IMIĘ

orterun, mpirun, mpiexec - Wykonuj zadania szeregowe i równoległe w Open MPI. oshrun, shmemrun
- Wykonuj zadania szeregowe i równoległe w Open SHMEM.

Uwaga: mpiruna, mpiexec, orterun wszystkie są dla siebie synonimami oshrun,
shmemrun w przypadku zainstalowania Open SHMEM. Użycie dowolnej nazwy spowoduje to samo
zachowanie.

STRESZCZENIE

Model pojedynczego procesu i wielu danych (SPMD):

mpiruna [ opcje ] [ ]

Model wielu instrukcji i wielu danych (MIMD):

mpiruna [opcje_globalne]
[opcje_lokalne1] [ ] :
[opcje_lokalne2] [ ] :
...:
[opcje_lokalneN] [ ]

Zauważ, że w obu modelach invokowanie mpiruna poprzez bezwzględną nazwę ścieżki jest równoważne z
określając prefix opcja z A wartość odpowiadająca katalogowi, w którym mpiruna
rezyduje, minus jego ostatni podkatalog. Na przykład:

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

odpowiada

% mpirun – przedrostek / Usr / local

SZYBKI PODSUMOWANIE

Jeśli po prostu szukasz sposobu na uruchomienie aplikacji MPI, prawdopodobnie będziesz chciał użyć pliku
wiersz poleceń o następującej postaci:

% mpirun [ -np X ] [ --plik_hosta ]

Spowoduje to uruchomienie X kopii w bieżącym środowisku wykonawczym (jeśli działasz w środowisku
obsługiwany menedżer zasobów, Open MPI mpiruna zwykle automatycznie użyje
odpowiedni starter procesu menedżera zasobów, w przeciwieństwie do np. rsz or ssh,
które wymagają użycia pliku hosta lub domyślnie uruchomią wszystkie kopie X na serwerze
localhost), planowanie (domyślnie) w sposób okrężny według gniazda procesora. Zobacz resztę
na tej stronie, aby uzyskać więcej szczegółów.

Należy pamiętać, że mpirun automatycznie wiąże procesy od początku serii v1.8.
W przypadku braku dalszych dyrektyw stosowane są dwa wiążące wzorce:

Bind do rdzeń: gdy liczba procesów wynosi <= 2

Bind do gniazdo elektryczne: gdy liczba procesów jest > 2

Jeśli Twoja aplikacja korzysta z wątków, prawdopodobnie chcesz się upewnić, że albo tego nie robisz
w ogóle powiązany (przez określenie --bind-to none) lub powiązany z wieloma rdzeniami za pomocą opcji
odpowiedni poziom wiązania lub określona liczba elementów przetwarzających na wniosek
proces.

OPCJE

mpiruna wyśle ​​każdemu nazwę katalogu, w którym został wywołany w węźle lokalnym
zdalnych węzłów i spróbuj przejść do tego katalogu. Zobacz „Aktualna praca
Katalog” poniżej w celu uzyskania dalszych informacji.

Program wykonywalny. Jest to identyfikowane jako pierwszy nierozpoznany argument
do mpiruna.

Przekaż te argumenty czasu wykonania do każdego nowego procesu. To zawsze muszą być
ostatnie argumenty mpiruna. Jeśli używany jest plik kontekstowy aplikacji, będzie
ignorowane.

-h, --help
Wyświetl pomoc dla tego polecenia

-q, --cichy
Pomiń komunikaty informacyjne z orterun podczas wykonywania aplikacji.

-v, --gadatliwy
Bądź gadatliwy

-V, --wersja
Wydrukuj numer wersji. Jeśli nie zostaną podane żadne inne argumenty, to również spowoduje
orterun, aby wyjść.

-wyświetl mapę, --wyświetl-mapę
Wyświetl tabelę przedstawiającą zmapowaną lokalizację każdego procesu przed uruchomieniem.

-wyświetl-rozwoj-mapę, --display-devel-map
Wyświetl bardziej szczegółową tabelę pokazującą zmapowaną lokalizację każdego procesu wcześniej
do uruchomienia (zwykle interesujące dla programistów).

-przydział-wyświetlania, --alokacja wyświetlania
Wyświetl wykrytą alokację zasobów.

Użyj jednej z poniższych opcji, aby określić, na których hostach (węzłach) klastra ma działać.
Należy pamiętać, że począwszy od wersji 1.8 mpirun uruchomi demona na każdym hoście
w alokacji (z uwzględnieniem poniższych opcji) na samym początku
wykonania, niezależnie od tego, czy procesy aplikacji zostaną ostatecznie zmapowane, czy nie
tam wykonać. Ma to na celu umożliwienie gromadzenia informacji o topologii sprzętu z pliku
zdalne węzły, co pozwala nam mapować procesy na podstawie znanej topologii. Jest to jednak
zmiana w porównaniu z zachowaniem z poprzednich wersji, w których demony były uruchamiane dopiero po mapowaniu
został ukończony i dlatego wystąpił tylko w węzłach, w których faktycznie odbywałyby się procesy aplikacji
wykonywać.

-H, -gospodarz, --gospodarz
Lista hostów, na których można wywoływać procesy.

-plik hosta, --plik hosta
Podaj plik hosta do użycia.

-plik maszynowy, --plik maszynowy
Synonim dla -plik hosta.

-zestaw procesora, --zestaw procesora
Ogranicz uruchamiane procesy do określonego procesora logicznego w każdym węźle. Zauważ to
opcje oprawy będą nadal obowiązywać w określonej kopercie — np. możesz
wybierz powiązanie każdego procesu tylko z jednym procesorem w określonym zestawie procesorów.

Następujące opcje określają liczbę procesów do uruchomienia. Zauważ, że żaden z
opcje implikują określoną politykę wiążącą - np. żądanie N procesów dla każdego gniazda
nie oznacza, że ​​procesy zostaną powiązane z gniazdem.

-c, -n, --N, -np <#>
Uruchom tyle kopii programu na podanych węzłach. Ta opcja na to wskazuje
określony plik jest programem wykonywalnym, a nie kontekstem aplikacji. Jeśli nie
wartość jest podana dla liczby kopii do wykonania (tj. ani "-np" ani
jego synonimy znajdują się w wierszu poleceń), Open MPI zostanie wykonane automatycznie
kopię programu na każdym gnieździe procesu (opis pliku „process
slot"). Ta funkcja może być jednak używana tylko w modelu SPMD i powróci
w przeciwnym razie wystąpi błąd (bez rozpoczęcia wykonywania aplikacji).

—według mapy ppr:N:
Uruchom N-krotność liczby obiektów określonego typu w każdym węźle.

-npersocket, --npersocket <#persocket>
W każdym węźle uruchom tyle procesów pomnożonych przez liczbę gniazd procesorów
węzeł. The -npersocket opcja włącza również -połączenie z gniazdem opcja.
(przestarzałe na rzecz --map-by ppr:n:socket)

-nperwęzeł, --npernode <#pernode>
Na każdym węźle uruchom tyle procesów. (przestarzałe na rzecz --map-by
ppr:n:węzeł)

-pernoda, --pernode
W każdym węźle uruchom jeden proces - odpowiednik -nperwęzeł 1. (przestarzałe w
na korzyść --map-by ppr:1:node)

Aby zmapować procesy:

--mapa według
Mapuj do określonego obiektu, domyślnie gniazdo. Obsługiwane opcje obejmują gniazdo,
hwthread, rdzeń, L1cache, L2cache, L3cache, gniazdo, numa, tablica, węzeł, sekwencyjny,
odległość i pp. Każdy obiekt może zawierać modyfikatory poprzez dodanie : i any
kombinacja PE=n (powiąż n elementów przetwarzających z każdym procesem), SPAN (równoważenie obciążenia
procesy w ramach alokacji), OVERSUBSCRIBE (zezwól na więcej procesów w węźle
niż przetwarzanie elementów) i NOOVERSUBSCRIBE. Obejmuje to PPR, gdzie
wzorzec zostanie zakończony kolejnym dwukropkiem, aby oddzielić go od modyfikatorów.

-bycore, --przyrost
Mapuj procesy według rdzenia (przestarzałe na rzecz --map-by core)

-bygniazdko, --bygniazdko
Mapuj procesy według gniazda (przestarzałe na rzecz --map-by gniazdo)

-nolokalny, --nielokalny
Nie uruchamiaj żadnych kopii uruchomionej aplikacji na tym samym węźle co orterun
działanie. Ta opcja nadpisze listę hosta lokalnego za pomocą --gospodarz lub jakikolwiek inny
mechanizm określania hosta.

-brak nadmiernej subskrypcji, --nooversubskrybuj
Nie przesubskrybuj żadnych węzłów; błąd (bez uruchamiania jakichkolwiek procesów), jeśli
żądana liczba procesów spowodowałaby nadsubskrypcję. Ta opcja jest niejawna
ustawia „max_slots” równą wartości „slots” dla każdego węzła.

-bynode, --bynode
Uruchamianie procesów po jednym na węzeł, cyklicznie po węźle. Ten
rozkłada procesy równomiernie pomiędzy węzłami i przypisuje rangi MPI_COMM_WORLD w sposób okrągły
robin, sposób „przez węzeł”.

Aby uporządkować rangi procesów w MPI_COMM_WORLD:

--ranking
Ranking w sposób okrężny zgodnie z określonym obiektem, domyślnie otwór.
Obsługiwane opcje obejmują gniazdo, hwthread, rdzeń, L1cache, L2cache, L3cache, gniazdo,
num, tablica i węzeł.

Dla wiązania procesu:

--powiązać
Powiąż procesy z określonym obiektem, domyślnie core. Obsługiwane opcje obejmują
slot, hwthread, rdzeń, l1cache, l2cache, l3cache, gniazdo, numa, płyta i brak.

-cpus-na-proc, --cpus-na-proc <#perproc>
Powiąż każdy proces z określoną liczbą procesorów. (przestarzałe na rzecz --map-
przez :PE=n)

-cpus-na-rangę, --procesor-na-ranking <#perrank>
Alias ​​dla -cpus-na-proc. (przestarzałe na rzecz --map-by :PE=n)

-powiązanie z rdzeniem, --powiązanie z rdzeniem
Powiąż procesy z rdzeniami (przestarzałe na rzecz --bind-to core)

-połączenie z gniazdem, --połączenie z gniazdem
Powiąż procesy z gniazdami procesora (przestarzałe na rzecz --bind-to gniazdo)

-powiązanie z nikim, --powiązanie z nikim
Nie wiąż procesów (przestarzałe na rzecz --bind-to none)

-powiązania-raportów, --powiązania-raportów
Zgłoś wszelkie powiązania dla uruchomionych procesów.

-lista-slotów, --lista-slotów
Lista identyfikatorów procesorów, które mają być używane do wiązania procesów MPI. Określone powiązania
zostanie zastosowany do wszystkich procesów MPI. Zobacz wyjaśnienie poniżej dotyczące składni.

Dla plików rankingowych:

-rf, --plik rankingowy
Podaj plik rankingfile.

Aby zarządzać standardowymi wejściami/wyjściami:

-Nazwa pliku wyjściowego, --Nazwa pliku wyjściowego
Przekieruj stdout, stderr i stddiag wszystkich procesów do procesu unikalnego
wersja określonej nazwy pliku. Wszystkie katalogi w nazwie pliku będą
zostać automatycznie utworzone. Każdy plik wyjściowy będzie składał się z pliku nazwa.id, gdzie
id będzie rangą procesów w MPI_COMM_WORLD, wypełnioną po lewej stronie zerami dla
poprawna kolejność w wykazach.

-stdin, --stdin
Ranga MPI_COMM_WORLD procesu, który ma otrzymać standardowe wejście. Wartość domyślna to
forward stdin do rangi MPI_COMM_WORLD 0, ale tej opcji można użyć do przesyłania dalej
stdin do dowolnego procesu. Dopuszczalne jest również określenie Żaden, wskazując, że nie
procesy mają otrzymać stdin.

-tag-wyjście, --tag-wyjście
Oznacz każdą linię wyjścia jako stdout, stderr i stddiag za pomocą [praca,
MCW_ranking] wskazując identyfikator zadania procesu i rangę MPI_COMM_WORLD
proces, który wygenerował wynik, i kanał, który go wygenerował.

-znacznik czasu-wyjście, --znacznik czasu-wyjście
Znacznik czasu każdej linii wyjściowej na stdout, stderr i stddiag.

-xml, --xml
Podaj wszystkie dane wyjściowe do stdout, stderr i stddiag w formacie xml.

-xterm, --xterm
Wyświetl wyniki procesów zidentyfikowanych na podstawie ich rang MPI_COMM_WORLD
oddzielne okna Xterm. Rangi są określone jako lista oddzielonych przecinkami
zakresy, gdzie -1 oznacza wszystkie. Dla każdego zostanie utworzone osobne okno
określony proces. Uwaga: xterm zwykle zamyka okno po zakończeniu
procesu w nim zachodzącego. Jednak dodając znak „!” do końca listy
określonych rang, zostaną udostępnione odpowiednie opcje zapewniające zachowanie xterm
okno otwarte po proces się kończy, umożliwiając w ten sposób zobaczenie procesu'
wyjście. Każde okno xterm będzie następnie musiało zostać ręcznie zamknięte. Uwaga: In
w niektórych środowiskach xterm może wymagać, aby plik wykonywalny znajdował się na ścieżce użytkownika, lub
być określone w wartościach bezwzględnych lub względnych. W związku z tym konieczne może być określenie a
lokalny plik wykonywalny jako „./foo” zamiast po prostu „foo”. Jeśli xterm nie znajdzie pliku
wykonywalny, mpirun zawiesi się, ale nadal będzie poprawnie reagował na klawisze ctrl-c. Jeśli to
się stanie, sprawdź, czy plik wykonywalny został określony poprawnie i spróbuj
ponownie.

Aby zarządzać plikami i środowiskiem wykonawczym:

-ścieżka, --ścieżka
który zostanie użyty podczas próby zlokalizowania żądanych plików wykonywalnych. Ten
jest używany przed użyciem lokalnego ustawienia PATH.

prefix
Katalog z prefiksem, który będzie używany do ustawiania PATH i LD_LIBRARY_PATH na
zdalny węzeł przed wywołaniem Open MPI lub procesu docelowego. Zobacz „Zdalne
Wykonanie” poniżej.

--preload-binarny
Skopiuj określone pliki wykonywalne na komputery zdalne przed uruchomieniem zdalnym
procesy. Pliki wykonywalne zostaną skopiowane do katalogu sesji Open MPI i
zostaną usunięte po zakończeniu zadania.

--preload-pliki
Załaduj wstępnie listę plików rozdzielonych przecinkami do bieżącego katalogu roboczego pliku
zdalne maszyny, na których procesy zostaną uruchomione przed ich rozpoczęciem.

--preload-pliki-docelowy-katalog
Katalog docelowy, który ma być używany do wstępnego ładowania plików, jeśli jest inny niż bieżący
katalog roboczy. Domyślnie ścieżki bezwzględne i względne dostarczane przez
--preload-files są używane.

--katalog tmp
Ustaw katalog główny drzewa katalogów sesji tylko dla mpirun.

-wd
Synonim dla -wdir.

-wdir
Przejdź do katalogu przed wykonaniem programu użytkownika. Zobacz „Aktualne
Katalog roboczy” zawiera uwagi dotyczące ścieżek względnych. Uwaga: Jeśli -wdir opcja
pojawia się zarówno w wierszu poleceń, jak i w kontekście aplikacji, kontekst będzie
mieć pierwszeństwo przed wierszem poleceń. Tak więc, jeśli ścieżka do żądanego wdir to
różni się w węzłach zaplecza, należy ją określić jako ścieżkę bezwzględną
jest poprawny dla węzła zaplecza.

-x
Wyeksportuj określone zmienne środowiskowe do zdalnych węzłów przed wykonaniem
program. Dla każdego można określić tylko jedną zmienną środowiskową -x opcja. Istniejący
można określić zmienne środowiskowe lub określić nowe nazwy zmiennych
odpowiadające wartości. Na przykład:
% mpirun -x WYŚWIETLACZ -x OFILE=/tmp/out ...

Parser dla -x opcja nie jest zbyt wyrafinowana; nawet nie rozumie
cytowane wartości. Użytkownikom zaleca się ustawienie zmiennych w środowisku, a następnie ich użycie
-x aby je wyeksportować (nie zdefiniować).

Ustawianie parametrów MCA:

-gmca, --gmca
Przekaż globalne parametry MCA, które mają zastosowanie we wszystkich kontekstach. jest
Nazwa parametru; jest wartością parametru.

-mca, --mca
Wysyłaj argumenty do różnych modułów MCA. Zobacz sekcję „MCA” poniżej.

Do debugowania:

-odpluskwić, --odpluskwić
Wywołaj debuger na poziomie użytkownika wskazany przez orte_base_user_debugger MCA
parametr.

-debuger, --Debugger.
Sekwencja debugerów do wyszukania, kiedy --odpluskwić jest używany (tj. synonim dla
orte_base_user_debugger parametr MCA).

-telewizja, --telewizja
Uruchom procesy w debugerze TotalView. Przestarzała kompatybilność wsteczna
flaga. Synonim dla --odpluskwić.

Istnieją również inne opcje:

--allow-run-jako root
Dopuszczać mpiruna do uruchomienia po wykonaniu przez użytkownika root (mpiruna domyślnie przerywanie
po uruchomieniu jako użytkownik root).

-niedonoszony, --niedonoszony <#>
Ustaw maksymalną liczbę przerwanych procesów do wyświetlenia.

--aplikacja
Podaj plik aplikacji, ignorując wszystkie inne opcje wiersza poleceń.

-por, --kartoplik
Podaj plik kartograficzny.

--hetero
Wskazuje, że dostępnych jest wiele kontekstów aplikacji, które są kombinacją wersji 32/64-bitowej
pliki binarne.

-opuść-sesję-w załączeniu, --leave-session-dołączony
Nie odłączaj demonów OmpiRTE używanych przez tę aplikację. Umożliwia to wyświetlanie komunikatów o błędach
z demonów, jak również z bazowego środowiska (np
uruchom demona), aby został wyświetlony.

-ompi-serwer, --ompi-serwer <uri or plik>
Określ URI serwera Open MPI (lub mpirun, który ma być używany jako serwer),
nazwa pliku (określona jako plik:nazwa pliku), który zawiera te informacje, lub
PID (określony jako pid:#) mpiruna, który ma być używany jako
serwer. Serwer Open MPI służy do obsługi danych wielu aplikacji
wymianę za pomocą funkcji MPI-2 MPI_Publish_name i MPI_Lookup_name.

-raport-pid, --raport-pid
Wydrukuj PID mpiruna podczas uruchamiania. Kanał musi mieć znak „-” do ind
upewnij się, że pid ma być wyprowadzany na standardowe wyjście, znak „+” oznacza, że ​​pid ma być wyprowadzany
być wyjściem na stderr lub nazwą pliku, do którego ma zostać zapisany pid.

-raport-uri, --raport-uri
Wydrukuj URI mpiruna podczas uruchamiania. Kanał musi mieć znak „-” do ind
upewnij się, że identyfikator URI ma zostać wyprowadzony na standardowe wyjście, znak „+” oznacza, że ​​identyfikator URI ma zostać wypisany
zostać wypisany na stderr lub nazwę pliku, do którego ma zostać zapisany identyfikator URI.

-czekaj na serwer, --czekaj na serwer
Wstrzymaj mpirun przed uruchomieniem zadania do czasu wykrycia serwera ompi. to jest przydatne
w skryptach, w których ompi-server może zostać uruchomiony w tle, a następnie natychmiast
przez mpiruna polecenie, które chce się z nim połączyć. Mpirun zrobi pauzę do czasu
nawiązano kontakt z określonym serwerem ompi lub przekroczono czas oczekiwania serwera.

-czas oczekiwania na serwer, --czas oczekiwania serwera
Maksymalny czas (w sekundach) mpirun powinien czekać na serwer ompi
początek. Wartość domyślna to 10 sekund.

Poniższe opcje są przydatne dla programistów; na ogół nie są one przydatne dla większości
Użytkownicy ORTE i/lub MPI:

-d, --debug-devel
Włącz debugowanie OmpiRTE (warstwy wykonawczej w Open MPI). To nie jest
ogólnie przydatne dla większości użytkowników.

--debug-daemons
Włącz debugowanie wszelkich demonów OmpiRTE używanych przez tę aplikację.

--debug-daemons-file
Włącz debugowanie wszelkich demonów OmpiRTE używanych przez tę aplikację, przechowujących dane wyjściowe w
akta.

-agent-uruchamiający, --agent-uruchamiający
Nazwa pliku wykonywalnego, który ma być używany do uruchamiania procesów na zdalnych węzłach.
Wartość domyślna to „orted”. Opcji tej można używać do testowania nowych koncepcji demonów lub do
przekazać opcje z powrotem do demonów bez konieczności wyświetlania ich samemu mpirunowi. Dla
na przykład określenie agenta uruchamiania orted -mca odls_base_verbose 5 umożliwia
programista, aby poprosił orted o debugowanie danych wyjściowych bez bałaganu z samego mpiruna.

--noprzedrostek
Wyłącz automatyczne zachowanie --prefix

Na liście mogą znajdować się inne opcje mpiruna --help.

Środowisko Zmienne
MPIEXEC_TIMEOUT
Maksymalna liczba sekund, które mpiruna (mpiexec) będzie działać. Po tylu
sekundy, mpiruna przerwie rozpoczęte zadanie i zakończy działanie.

OPIS

Jedno wywołanie mpiruna uruchamia aplikację MPI działającą pod Open MPI. jeśli
aplikacja to pojedynczy proces i wiele danych (SPMD), na której można określić aplikację
dotychczasowy mpiruna wiersz poleceń.

Jeśli aplikacja zawiera wiele instrukcji, wiele danych (MIMD), składających się z wielu
programów, zestaw programów i argumentów można określić na jeden z dwóch sposobów: Rozszerzony
Argumenty wiersza poleceń i kontekst aplikacji.

Kontekst aplikacji opisuje zestaw programów MIMD, w tym wszystkie argumenty w a
osobny plik. Ten plik zasadniczo zawiera wiele mpiruna wiersze poleceń, mniej
samą nazwę polecenia. Możliwość określenia różnych opcji dla różnych
instancje programu to kolejny powód, aby używać kontekstu aplikacji.

Rozszerzone argumenty wiersza poleceń pozwalają na opis układu aplikacji na stronie
wiersz poleceń za pomocą dwukropków (:), aby oddzielić specyfikację programów i argumentów.
Niektóre opcje są ustawiane globalnie we wszystkich określonych programach (np. --hostfile), while
inne są specyficzne dla pojedynczego programu (np. -np).

Określanie Gospodarz Węzły
Węzły hosta można zidentyfikować na mpiruna wiersz poleceń z -gospodarz opcja lub w
plik hosta.

Na przykład,

mpirun -H aa,aa,bb ./a.out
uruchamia dwa procesy w węźle aa i jeden w węźle bb.

Lub rozważ plik hosta

% kot mój plik hosta
aa miejsca = 2
miejsca na bb = 2
miejsca cc = 2

Tutaj podajemy zarówno nazwy hostów (aa, bb i cc), jak i liczbę „slotów” dostępnych dla
każdy. Sloty wskazują, ile procesów może potencjalnie wykonać w węźle. Dla najlepszego
wydajność, liczbę gniazd można wybrać tak, aby odpowiadała liczbie rdzeni w węźle lub
liczba gniazd procesorów. Jeśli plik hosta nie zawiera informacji o gniazdach, a
przyjmuje się wartość domyślną 1. Podczas pracy w menedżerach zasobów (np. SLURM, Torque,
itp.), Open MPI uzyska zarówno nazwę hosta, jak i liczbę slotów bezpośrednio z pliku
menadżer zasobów.

mpirun -hostfile mójplik_hosta ./a.out
uruchomi dwa procesy na każdym z trzech węzłów.

mpirun -plik_hosta plik_hosta -host aa ./a.out
uruchomi dwa procesy, oba w węźle aa.

mpirun -hostfile mójplik_hosta -host dd ./a.out
nie znajdzie żadnych hostów do uruchomienia i przerwie z błędem. Oznacza to, że określony host dd
nie znajduje się w określonym pliku hosta.

Określanie Numer of Procesy
Jak właśnie widzieliśmy, liczbę uruchamianych procesów można ustawić za pomocą pliku hosta. Inny
istnieją mechanizmy.

Liczbę uruchomionych procesów można określić jako wielokrotność liczby węzłów lub
dostępne gniazda procesorowe. Na przykład,

mpirun -H aa,bb -npersocket 2 ./a.out
uruchamia procesy 0-3 w węźle aa i proces 4-7 w węźle bb, gdzie oba aa i bb to
węzły dwugniazdowe. The -npersocket opcja włącza również -połączenie z gniazdem opcja,
co jest omówione w dalszej części.

mpirun -H aa,bb -npernode 2 ./a.out
uruchamia procesy 0-1 w węźle aa i procesy 2-3 w węźle bb.

mpirun -H aa,bb -npernode 1 ./a.out
uruchamia jeden proces na węzeł hosta.

mpirun -H aa,bb -pernode ./a.out
jest taki sam jak -nperwęzeł 1.

Inną alternatywą jest określenie liczby procesów za pomocą -np opcja. Rozważać
teraz plik hosta

% kot mój plik hosta
aa miejsca = 4
miejsca na bb = 4
miejsca cc = 4

Teraz,

mpirun -hostfile mójplik_hosta -np 6 ./a.out
uruchomi procesy 0-3 w węźle aa i procesy 4-5 w węźle bb. Pozostałe
Sloty w pliku hosta nie będą używane, ponieważ plik -np opcja wskazywała, że ​​tylko 6
należy uruchomić procesy.

Mapowanie Procesy do Węzły: Korzystanie z Polityka
Powyższe przykłady ilustrują domyślne mapowanie procesów procesów na węzły. Ten
mapowanie można również kontrolować za pomocą różnych mpiruna opcje opisujące zasady mapowania.

Rozważ ten sam plik hosta, co powyżej, ponownie z -np 6:

węzeł aa węzeł bb węzeł cc

mpirun 0 1 2 3 4 5

mpirun --map-by węzeł 0 3 1 4 2 5

mpirun -nolokalny 0 1 2 3 4 5

--mapa według węzeł opcja zrównoważy obciążenie procesów na dostępnych węzłach,
numerowanie każdego procesu w sposób okrężny.

-nolokalny opcja zapobiega mapowaniu jakichkolwiek procesów na host lokalny (w this
węzeł sprawy aa). Chwila mpiruna zazwyczaj zużywa niewiele zasobów systemowych, -nolokalny może być
pomocne przy uruchamianiu bardzo dużych zadań, gdzie mpiruna może faktycznie trzeba użyć zauważalnego
ilości pamięci i/lub czasu przetwarzania.

Tak samo jak -np może określić mniej procesów niż jest slotów, może też przekroczyć subskrypcję
szczeliny. Na przykład z tym samym plikiem hosta:

mpirun -hostfile mójplik_hosta -np 14 ./a.out
uruchomi procesy 0-3 w węźle aa, 4-7 w bb i 8-11 w cc. Następnie doda
pozostałe dwa procesy do dowolnych węzłów, które wybierze.

Można także określić limity nadsubskrypcji. Na przykład z tym samym plikiem hosta:

mpirun -hostfile mójplik_hosta -np 14 -nooversubscribe ./a.out
spowoduje błąd od -brak nadmiernej subskrypcji zapobiega nadsubskrypcji.

Limity nadmiernej subskrypcji można również określić w samym pliku hosta:
% cat mój plik hosta
aa sloty=4 max_slots=4
bb max_slots=4
miejsca cc = 4

max_slots pole określa taki limit. Kiedy to nastąpi, automatach wartość domyślna to
limit. Teraz:

mpirun -hostfile mójplik_hosta -np 14 ./a.out
powoduje uruchomienie pierwszych 12 procesów jak poprzednio, ale pozostałe dwa
procesy zostaną wymuszone na węźle cc. Pozostałe dwa węzły są chronione przez
hostfile przed nadsubskrypcją przez to zadanie.

Korzystanie z --nooversubskrybuj opcja może być pomocna, ponieważ Open MPI obecnie nie działa
wartości „max_slots” z menedżera zasobów.

Oczywiście, -np może być również używany z -H or -gospodarz opcja. Na przykład,

mpirun -H aa,bb -np 8 ./a.out
uruchamia 8 procesów. Ponieważ określono tylko dwa hosty, po pierwszych dwóch
procesy są mapowane, jeden na aa, drugi na bb, pozostałe procesy mają nadsubskrypcję
określonych hostów.

A oto przykład MIMD:

mpirun -H aa -np 1 nazwa hosta: -H bb,cc -np 2 czas pracy
uruchomi działający proces 0 hosta w węźle aa i uruchomionych procesach 1 i 2
uptime odpowiednio w węzłach bb i cc.

Mapowanie, Zaszeregowanie, i Wiążący: Oh Mój!
Open MPI wykorzystuje trójfazową procedurę przydzielania lokalizacji i rang procesom:

mapowanie Przypisuje domyślną lokalizację każdemu procesowi

ranking Przypisuje każdemu procesowi wartość rangi MPI_COMM_WORLD

wiążący Ogranicza działanie każdego procesu na określonych procesorach

mapowanie krok służy do przypisania domyślnej lokalizacji do każdego procesu w oparciu o narzędzie mapujące
być zatrudnionym. Mapowanie według szczeliny, węzła i sekwencyjnie skutkuje przypisaniem
procesów do poziomu węzła. Natomiast mapowanie według obiektu pozwala osobie mapującej na przypisanie
proces do rzeczywistego obiektu w każdym węźle.

Uwaga: lokalizacja przypisana procesowi jest niezależna od miejsca, w którym będzie on powiązany – tzw
przypisanie jest używane wyłącznie jako dane wejściowe do algorytmu powiązania.

Odwzorowanie procesów procesowych na węzły można zdefiniować nie tylko za pomocą ogólnych zasad
ale także, jeśli to konieczne, przy użyciu dowolnych odwzorowań, których nie można opisać prostym
polityka. Można użyć „mapowania sekwencyjnego”, który odczytuje plik hosta linia po linii,
przypisywanie procesów do węzłów w dowolnej kolejności określonej w pliku hosta. Użyj -mca mapy
nast opcja. Na przykład, używając tego samego pliku hosta co poprzednio:

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

uruchomi trzy procesy, po jednym w każdym z węzłów, odpowiednio, aa, bb i cc. Gniazdo
liczby nie mają znaczenia; jeden proces jest uruchamiany w każdej linii w dowolnym węźle wymienionym na liście
Linia.

Innym sposobem określenia dowolnych mapowań jest użycie pliku rankingowego, który zawiera szczegółowe informacje
kontrolę również nad powiązaniem procesu. Pliki rankingowe omówiono poniżej.

Druga faza skupia się na ranking procesu w obrębie zadania MPI_COMM_WORLD.
Open MPI oddziela to od procedury mapowania, aby zapewnić większą elastyczność w
względne rozmieszczenie procesów MPI. Najlepiej można to zilustrować, rozważając poniższe
dwa przypadki, w których użyliśmy opcji —map-by ppr:2:socket:

węzeł aa węzeł bb

ranking według rdzenia 0 1 ! 2 3 4 5 ! 6 7

gniazdo rankingowe 0 2 ! 1 3 4 6 ! 5 7

gniazdo rankingowe: rozpiętość 0 4 ! 1 5 2 6 ! 3 7

Ranking według rdzenia i slotu zapewnia identyczny wynik – prosty postęp
MPI_COMM_WORLD plasuje się w każdym węźle. Ranking według gniazd to ranking okrężny
każdym węźle, aż wszystkim procesom zostanie przypisana ranga MCW, a następnie następuje przejście do
następny węzeł. Dodanie rozpiętość modyfikator dyrektywy rankingowej powoduje algorytm rankingowy
potraktować całą alokację jako całość – w ten sposób nadawane są stopnie MCW
przez wszystkie gniazda, a następnie zawróć na początek.

wiążący faza faktycznie wiąże każdy proces z danym zestawem procesorów. To może
poprawić wydajność, jeśli system operacyjny nie optymalnie umieszcza procesy. Dla
na przykład może nadsubskrybować niektóre gniazda procesorów wielordzeniowych, pozostawiając inne gniazda
bezczynny; może to prowadzić do niepotrzebnej rywalizacji procesów o wspólne zasoby. Albo to
może zbyt szeroko rozłożyć procesy; może to być nieoptymalne, jeśli wydajność aplikacji
jest wrażliwy na koszty komunikacji międzyprocesowej. Wiązanie może również utrzymać działanie
systemu przed nadmierną migracją procesów, niezależnie od tego, jak optymalnie te procesy przebiegają
zostały umieszczone na początek.

Procesory, które mają być użyte do wiązania, można zidentyfikować w kategoriach grup topologicznych
- np. powiązanie z l3cache spowoduje powiązanie każdego procesu ze wszystkimi procesorami w zasięgu
pojedyncza pamięć podręczna L3 w przypisanej im lokalizacji. Tak więc, jeśli proces jest przypisany przez
mapper do określonego gniazda, a następnie a -powiązać l3cache dyrektywa spowoduje, że proces będzie
powiązane z procesorami współdzielącymi pojedynczą pamięć podręczną L3 w tym gnieździe.

Aby pomóc zrównoważyć obciążenia, wiążąca dyrektywa używa metody okrężnej podczas wiązania
poziomy niższe niż stosowane w programie mapującym. Rozważmy na przykład przypadek, w którym zamapowano zadanie
do poziomu gniazda, a następnie przywiązany do rdzenia. Każde gniazdo będzie miało wiele rdzeni, więc if
do danego gniazda jest mapowanych wiele procesów, algorytm wiązania przypisze każdy z nich
proces zlokalizowany w gnieździe do unikalnego rdzenia w sposób okrężny.

Alternatywnie, procesy odwzorowane przez l2cache i następnie powiązane z gniazdem zostaną po prostu powiązane
do wszystkich procesorów w gnieździe, w którym się znajdują. W ten sposób użytkownicy mogą
sprawować szczegółową kontrolę nad względną lokalizacją rangi MCW i powiązaniem.

Wreszcie, --powiązania-raportów może służyć do raportowania powiązań.

Jako przykład rozważmy węzeł z dwoma gniazdami procesorów, z których każde zawiera cztery rdzenie. My
biegać mpiruna w -np 4 --powiązania-raportów oraz następujące opcje dodatkowe:

% mpirun ... --map-by core --bind-to core
[...] ... powiązanie dziecka [...,0] z procesorem 0001
[...] ... powiązanie dziecka [...,1] z procesorem 0002
[...] ... powiązanie dziecka [...,2] z procesorem 0004
[...] ... powiązanie dziecka [...,3] z procesorem 0008

% mpirun ... --mapa-by gniazdo --bind-to gniazdo
[...] ... wiązanie dziecka [...,0] z gniazdem 0 cpus 000f
[...] ... wiązanie dziecka [...,1] z gniazdem 1 procesora 00f0
[...] ... wiązanie dziecka [...,2] z gniazdem 0 cpus 000f
[...] ... wiązanie dziecka [...,3] z gniazdem 1 procesora 00f0

% mpirun ... --map-by core:PE=2 --bind-to core
[...] ... powiązanie dziecka [...,0] z procesorem 0003
[...] ... wiązanie dziecka [...,1] z cpus 000c
[...] ... powiązanie dziecka [...,2] z procesorem 0030
[...] ... wiązanie dziecka [...,3] z cpus 00c0

% mpirun ... --powiąż z żadnym

Tutaj, --powiązania-raportów pokazuje powiązanie każdego procesu jako maskę. W pierwszym przypadku,
procesy wiążą się z kolejnymi rdzeniami, jak wskazują maski 0001, 0002, 0004 i
0008. W drugim przypadku procesy wiążą się ze wszystkimi rdzeniami kolejnych gniazd, jak wskazano
przez maski 000f i 00f0. Procesy przebiegają przez gniazda procesorów w sposób okrężny.
robin fashion tyle razy, ile potrzeba. W trzecim przypadku maski pokazują nam, że 2
rdzenie zostały powiązane na proces. W czwartym przypadku wiązanie jest wyłączone i nie
zgłaszane są powiązania.

Obsługa powiązań procesów przez Open MPI zależy od bazowego systemu operacyjnego.
Dlatego niektóre opcje powiązania procesów mogą nie być dostępne w każdym systemie.

Powiązanie procesu można również ustawić za pomocą parametrów MCA. Ich użycie jest mniej wygodne niż
, że z mpiruna opcje. Z drugiej strony parametry MCA można ustawić nie tylko na
mpiruna wiersza poleceń, ale alternatywnie w pliku systemowym lub użytkownika mca-params.conf lub jako
zmienne środowiskowe, jak opisano w sekcji MCA poniżej. Niektóre przykłady obejmują:

Opcja mpirun Wartość klucza parametru MCA

--map-by core rmaps_base_mapping_policy core
--map-by gniazdo rmaps_base_mapping_policy gniazdo
--rank-by core rmaps_base_ranking_policy rdzeń
--bind-to core rdzeń hwloc_base_binding_policy
--bind-to gniazdo hwloc_base_binding_policy gniazdo
--bind-to none hwloc_base_binding_policy brak

Rankingi
Pliki rankingowe to pliki tekstowe zawierające szczegółowe informacje o sposobie poszczególnych procesów
powinny być mapowane na węzły i z którymi procesorami powinny być powiązane. Każda linia a
plik rankingowy określa lokalizację jednego procesu (w przypadku zadań MPI odnosi się do „rangi” procesu
do swojej rangi w MPI_COMM_WORLD). Ogólna postać każdej linii w pliku rankingowym to:

ranga = szczelina=

Na przykład:

$ cat mój plik rankingowy
ranga 0=aa slot=1:0-2
ranga 1=miejsce na bb=0:0,1
ranga 2 = miejsce na CC = 1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Oznacza to, że

Ranga 0 działa w węźle aa, powiązanym z gniazdem logicznym 1, rdzeniami 0-2.
Ranga 1 działa na węźle bb, powiązanym z gniazdem logicznym 0, rdzeniami 0 i 1.
Stopień 2 działa na węźle cc, powiązanym z rdzeniami logicznymi 1 i 2.

Do określenia można alternatywnie użyć plików rankingowych fizyczny lokalizacje procesorów. W tym przypadku,
składnia jest nieco inna. Gniazda nie są już rozpoznawane i numer gniazda
podany musi być numerem fizycznego PU, ponieważ większość systemów operacyjnych nie przypisuje unikalnego fizycznego
identyfikator do każdego rdzenia w węźle. Zatem prawidłowy fizyczny plik rankingowy wygląda mniej więcej tak
następujące brzmienie:

$ cat mój fizyczny plik rankingowy
ranga 0=aa slot=1
ranga 1=miejsce na BB=8
ranga 2 = miejsce na CC = 6

Oznacza to, że

Ranga 0 będzie działać na węźle aa, powiązanym z rdzeniem zawierającym fizyczny PU 1
Ranga 1 będzie działać na węźle bb, powiązanym z rdzeniem zawierającym fizyczny PU 8
Ranga 2 będzie działać na węźle cc, powiązanym z rdzeniem zawierającym fizyczne PU 6

Pliki rankingowe są traktowane jako logiczny domyślnie i parametr MCA
rmaps_rank_file_physical musi być ustawiony na 1, aby wskazać, że plik rankingowy ma być
uważane za fizyczny.

Nazwy hostów wymienione powyżej są „absolutne”, co oznacza, że ​​są to nazwy hostów, które można rozwiązać
określony. Jednak nazwy hostów można również określić jako „względne”, co oznacza, że ​​takie są
określone w odniesieniu do określonej zewnętrznie listy nazw hostów (np. przez mpirun's
--host argument, plik hosta lub harmonogram zadań).

Specyfikacja „względna” ma postać „+n ", gdzie X jest liczbą całkowitą określającą
X-ta nazwa hosta w zestawie wszystkich dostępnych nazw hostów, indeksowana od 0. Na przykład:

$ cat mój plik rankingowy
rank 0=+n0 slot=1:0-2
ranga 1=+n1 slot=0:0,1
ranga 2=+n2 slotów=1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Począwszy od Open MPI v1.7, wszystkie lokalizacje gniazd/gniazd rdzenia są określone jako logiczny
indeksy (wykorzystano serię Open MPI v1.6 fizyczny indeksy). Możesz skorzystać z narzędzi takich jak
„lstopo” HWLOC, aby znaleźć logiczne indeksy gniazd i rdzeni.

Zastosowanie Kontekst or Plik wykonywalny Programować?
Aby rozróżnić te dwie różne formy, mpiruna szuka w wierszu poleceń --aplikacja opcja.
Jeśli jest określony, przyjmuje się, że plik nazwany w wierszu poleceń jest plikiem an
kontekst aplikacji. Jeśli nie jest określony, przyjmuje się, że plik jest plikiem wykonywalnym
program.

Lokalizowanie Akta
Jeśli dla pliku nie określono ścieżki względnej ani bezwzględnej, Open MPI najpierw będzie szukać
plików, przeszukując katalogi określone przez --ścieżka opcja. Jeżeli nie ma --ścieżka
ustawiono opcję lub jeśli plik nie zostanie znaleziony w lokalizacji --ścieżka lokalizacji, następnie Open MPI rozpocznie wyszukiwanie
zmienna środowiskowa PATH użytkownika zdefiniowana w węzłach źródłowych.

Jeśli określono katalog względny, musi on być względny względem początkowego katalogu roboczego
zależy od konkretnego użytego startera. Na przykład, jeśli używasz starterów rsh lub ssh,
domyślnym katalogiem jest $HOME. Inni starterzy mogą ustawić katalog początkowy na
bieżący katalog roboczy z wywołania mpiruna.

Aktualny Pracujący Informator
-wdir opcja mpirun (i jej synonim, -wd) pozwala użytkownikowi na zmianę na dowolną
katalogu przed wywołaniem programu. Można go również używać w plikach kontekstowych aplikacji
aby określić katalogi robocze w określonych węzłach i/lub dla określonych aplikacji.

Jeśli -wdir opcja pojawia się zarówno w pliku kontekstu, jak i w wierszu poleceń, kontekst
katalog plików zastąpi wartość wiersza poleceń.

Jeśli -wdir określono opcję, Open MPI spróbuje zmienić ją na określoną
katalog na wszystkich zdalnych węzłach. Jeśli to się nie powiedzie, mpiruna przestanie.

Jeśli -wdir Jest opcja nie określony, Open MPI wyśle ​​nazwę katalogu gdzie mpiruna
został wywołany do każdego ze zdalnych węzłów. Węzły zdalne będą próbowały to zmienić
informator. Jeśli nie jest to możliwe (np. jeśli katalog nie istnieje w tym węźle), wówczas
Open MPI użyje domyślnego katalogu określonego przez starter.

Wszelkie zmiany katalogów mają miejsce przed wywołaniem programu użytkownika; nie czeka aż
MPI_INIT nazywa się.

Standardowa I / O
Open MPI kieruje standardowe wejście UNIX do /dev/null we wszystkich procesach z wyjątkiem
Proces MPI_COMM_WORLD rangi 0. Proces MPI_COMM_WORLD rangi 0 dziedziczy standardowe wejście
od mpiruna. Uwaga: Węzeł, który wywołał mpiruna nie musi być taki sam jak węzeł gdzie
rezyduje proces MPI_COMM_WORLD rangi 0. Open MPI obsługuje przekierowanie mpiruna's
standardowe wejście do procesu rangi 0.

Open MPI kieruje standardowe wyjście UNIX i błędy ze zdalnych węzłów do węzła, który wywołał
mpiruna i wypisuje go na standardowe wyjście/błąd mpiruna. Lokalne procesy dziedziczą
standardowe wyjście/błąd mpiruna i przenieś się bezpośrednio do niego.

W ten sposób możliwe jest przekierowanie standardowych wejść/wyjść dla aplikacji Open MPI za pomocą
typowa procedura przekierowania powłoki włączona mpiruna.

% mpirun -np 2 moja_aplikacja < moje_wejście > moje_wyjście

Zauważ, że w tym przykładzie tylko proces MPI_COMM_WORLD rangi 0 otrzyma strumień
od moje_wejście na stdin. Stdin na wszystkich pozostałych węzłach będzie powiązany z /dev/null.
Jednak standardowe wyjście ze wszystkich węzłów zostanie zebrane w pliku moje_wyjście plik.

Signal Propagacja
Kiedy orterun odbierze SIGTERM i SIGINT, spróbuje zakończyć całe zadanie
wysyłając następnie wszystkim procesom w zadaniu SIGTERM, czekając niewielką liczbę sekund
wysłanie wszystkim procesom w zadaniu SIGKILL.

Sygnały SIGUSR1 i SIGUSR2 odebrane przez orterun są propagowane do wszystkich procesów w sieci
praca.

Można włączyć przekazywanie SIGSTOP i SIGCONT do programu wykonywanego przez mpirun by
ustawienie parametru MCA orte_forward_job_control na 1. Sygnał SIGTSTOP do mpirun zostanie
następnie powoduje wysłanie sygnału SIGSTOP do wszystkich programów uruchomionych przez mpirun i
podobnie sygnał SIGCONT do mpirun spowoduje wysłanie SIGCONT.

Inne sygnały nie są obecnie propagowane przez orterun.

Przetwarzanie Zakończenie / Signal Prowadzenie
Jeśli podczas działania aplikacji MPI jakikolwiek proces zakończy się nieprawidłowo (albo zakończy działanie
przed wywołaniem MPI_FINALIZACJAlub śmierć w wyniku sygnału), mpiruna wydrukuje
komunikat o błędzie i zabij resztę aplikacji MPI.

Osoby obsługujące sygnały użytkownika powinny prawdopodobnie unikać prób czyszczenia stanu MPI (Open MPI to
obecnie nie jest bezpieczny dla sygnału asynchronicznego; Widzieć MPI_Init_thread(3) aby uzyskać szczegółowe informacje na temat
MPI_THREAD_MULTIPLE i bezpieczeństwo nici). Na przykład, jeśli wystąpi błąd segmentacji w
MPI_WYŚLIJ (być może dlatego, że przekazano zły bufor), a procedura obsługi sygnału użytkownika jest
wywołany, jeśli ten program obsługi użytkownika spróbuje wywołać MPI_FINALIZACJA, Mogą się zdarzyć złe rzeczy
ponieważ Open MPI był już „w” MPI, gdy wystąpił błąd. Od mpiruna zauważy
że proces umarł z powodu sygnału, prawdopodobnie nie jest to konieczne (i najbezpieczniejsze) dla
użytkownik, aby wyczyścić tylko stan inny niż MPI.

Przetwarzanie Środowisko
Procesy w aplikacji MPI dziedziczą swoje środowisko po demonie Open RTE
węzeł, na którym działają. Środowisko jest zazwyczaj dziedziczone z
powłoka użytkownika. W węzłach zdalnych dokładne środowisko jest określane przez moduł rozruchowy MCA
używany. ten rsz moduł uruchamiania, na przykład, używa jednego z nich rsz/ssh aby uruchomić Open RTE
demon na zdalnych węzłach i zazwyczaj wykonuje jeden lub więcej plików konfiguracyjnych powłoki użytkownika
przed uruchomieniem demona Open RTE. Podczas uruchamiania dynamicznie połączonych aplikacji, które
wymagają LD_LIBRARY_PATH zmienną środowiskową, którą należy ustawić, należy zachować ostrożność, aby to zapewnić
czy jest poprawnie ustawiony podczas uruchamiania Open MPI.

Aby uzyskać więcej informacji, zobacz sekcję „Zdalne wykonanie”.

Praca zdalna Egzekucja
Otwarty MPI wymaga, aby PATH zmienną środowiskową ustaw tak, aby znajdowała pliki wykonywalne na komputerze zdalnym
węzły (zwykle jest to konieczne tylko w rsz- lub sshśrodowiska oparte na --
środowiska wsadowe/zaplanowane zazwyczaj kopiują bieżące środowisko do wykonania
zadania zdalne, więc jeśli obecne środowisko tak ma PATH i / lub LD_LIBRARY_PATH ustawić prawidłowo,
zdalne węzły również będą miały to ustawione poprawnie). Jeśli Open MPI został skompilowany z shared
wsparcia bibliotecznego, konieczne może być również posiadanie LD_LIBRARY_PATH zmienna środowiskowa
ustawić także na zdalnych węzłach (szczególnie w celu znalezienia bibliotek współdzielonych wymaganych do uruchomienia user
aplikacje MPI).

Jednak nie zawsze jest pożądane lub możliwe edytowanie plików startowych powłoki w celu ustawienia PATH
i / lub LD_LIBRARY_PATH, prefix Opcja jest dostępna dla niektórych prostych konfiguracji
gdzie nie jest to możliwe.

prefix opcja przyjmuje pojedynczy argument: katalog bazowy na zdalnym węźle, gdzie
Otwarty MPI jest zainstalowany. Open MPI użyje tego katalogu do ustawienia pilota PATH i
LD_LIBRARY_PATH przed uruchomieniem jakichkolwiek aplikacji Open MPI lub aplikacji użytkownika. To pozwala biegać
Otwieraj zadania MPI bez wstępnej konfiguracji PATH i LD_LIBRARY_PATH na pilocie
węzły

Open MPI dodaje nazwę bazową „bindir” bieżącego węzła (katalog, w którym znajdują się pliki Open MPI
pliki wykonywalne są zainstalowane) do prefiksu i używa go do ustawienia PATH na zdalnym węźle.
Podobnie Open MPI dodaje nazwę bazową „libdir” bieżącego węzła (katalog, w którym
Instalowane są biblioteki Open MPI) do przedrostka i używa go do ustawienia LD_LIBRARY_PATH
na zdalnym węźle. Na przykład:

Lokalny bindir: /local/node/directory/bin

Lokalny katalog libdir: /local/node/directory/lib64

Jeśli używany jest następujący wiersz poleceń:

% mpirun --prefix /remote/węzeł/katalog

Open MPI doda „/remote/node/directory/bin” do pliku PATH i
„/remote/node/directory/lib64” do D_LIBRARY_PATH w zdalnym węźle przed próbą
wykonać cokolwiek.

prefix opcja nie jest wystarczająca, jeśli ścieżki instalacji na zdalnym węźle są takie
inny niż węzeł lokalny (np. jeśli „/ lib„ jest używane w węźle lokalnym, ale „/lib64"jest
używany w zdalnym węźle) lub jeśli ścieżki instalacji są inne niż a
podkatalog pod wspólnym przedrostkiem.

Zwróć uwagę, że wykonywanie mpiruna przez bezwzględną nazwę ścieżki jest równoznaczne z określeniem prefix
bez ostatniego podkatalogu w bezwzględnej nazwie ścieżki do mpiruna. Na przykład:

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

odpowiada

% mpirun – przedrostek / Usr / local

eksportowane Środowisko Zmienne
Wszystkie zmienne środowiskowe nazwane w postaci OMPI_* zostaną automatycznie wyeksportowane
do nowych procesów na węzłach lokalnych i zdalnych. Parametry środowiskowe również mogą być
ustawiane/przekazywane do nowych procesów przy użyciu parametru MCA mca_base_env_list, -x
opcja do mpiruna została wycofana, ale składnia parametru MCA jest zgodna z poprzednią
przykład. Podczas gdy składnia -x opcja i parametr MCA pozwalają na definicję nowego
zmiennych, zwróć uwagę, że parser tych opcji nie jest obecnie zbyt wyrafinowany -
nie rozumie nawet cytowanych wartości. Użytkownikom zaleca się ustawienie zmiennych w pliku
środowiska i skorzystać z możliwości ich eksportu; nie definiować ich.

Oprawa MCA parametry
-mca przełącznik umożliwia przekazywanie parametrów do różnych MCA (Modular Component
Architektura) moduły. Moduły MCA mają bezpośredni wpływ na programy MPI, ponieważ na to pozwalają
dostrajalne parametry do ustawienia w czasie wykonywania (takie jak sterownik urządzenia komunikacyjnego BTL do
użyć, jakie parametry przekazać do tego BTL itp.).

-mca switch przyjmuje dwa argumenty: i , ogólnie rzecz biorąc
określa, który moduł MCA otrzyma wartość. Na przykład używane jest słowo „btl”.
aby wybrać, który BTL będzie używany do przesyłania komunikatów MPI. The argumentem jest
wartość, która jest przekazywana. Na przykład:

mpirun -mca btl tcp, self -np 1 foo
Nakazuje Open MPI używanie znaczników BTL „tcp” i „self” oraz uruchamianie pojedynczej kopii pliku „foo”
przydzielony węzeł.

mpirun -mca btl self -np 1 foo
Nakazuje Open MPI użycie „self” BTL i uruchomienie pojedynczej kopii „foo” przydzielonej
węzeł.

-mca przełącznik może być używany wiele razy, aby określić różne i / lub
argumenty. Jeśli to samo jest określony więcej niż raz, są połączone
oddzielając je przecinkiem („”,”).

Zauważ, że -mca switch to po prostu skrót do ustawiania zmiennych środowiskowych. ten
ten sam efekt można uzyskać, ustawiając odpowiednie zmienne środowiskowe przed
bieganie mpiruna. Postać zmiennych środowiskowych ustawianych przez Open MPI to:

OMPI_MCA_ =

W ten sposób, -mca przełącznik zastępuje wszelkie wcześniej ustawione zmienne środowiskowe. The -mca
ustawienia w podobny sposób zastępują parametry MCA ustawione w pliku $OPAL_PREFIX/etc/openmpi-mca-
params.conf lub plik $HOME/.openmpi/mca-params.conf.

Autor nieznany argumenty są nadal ustawione jako zmienne środowiskowe - nie są sprawdzane (przez
mpiruna) dla poprawności. Nielegalne lub nieprawidłowe argumenty mogą, ale nie muszą być
zgłoszone — zależy to od konkretnego modułu MCA.

Aby znaleźć dostępne typy komponentów w architekturze MCA lub znaleźć dostępne
parametry dla określonego komponentu, użyj informacja_ompi Komenda. Zobacz informacja_ompi(1) mężczyzna
stronę, aby uzyskać szczegółowe informacje na temat polecenia.

Bieganie as korzeń
Zespół Open MPI zdecydowanie odradza wykonanie mpiruna jako użytkownik root. MPI
aplikacje powinny być uruchamiane jako zwykli użytkownicy (inni niż root).

Odzwierciedlając tę ​​​​radę, mpirun domyślnie odmówi uruchomienia jako root. Aby to zastąpić
domyślnie, możesz dodać --allow-run-jako root opcja do mpiruna wiersz poleceń.

Wyjście status
Nie ma standardowej definicji czego mpiruna powinien powrócić jako status wyjścia. Po
po obszernej dyskusji, zdecydowaliśmy się na następującą metodę przypisywania mpiruna wyjście
status (uwaga: w poniższym opisie pracą „podstawową” jest aplikacja początkowa
rozpoczęte przez mpiruna — wszystkie zadania utworzone przez to zadanie są oznaczone jako „drugorzędne”
Oferty pracy):

· jeśli wszystkie procesy w zadaniu podstawowym zwykle kończą się kodem wyjścia 0, zwracamy 0

· jeśli jeden lub więcej procesów w zadaniu podstawowym zwykle kończy się niezerowym wyjściem
status, zwracamy status wyjścia procesu z najniższą rangą MPI_COMM_WORLD
mają status niezerowy

· jeśli wszystkie procesy w zadaniu podstawowym zwykle kończą się statusem wyjścia 0 i jednym lub
więcej procesów w zadaniu dodatkowym zwykle kończy się niezerowym statusem wyjścia, (a)
zwróć status wyjścia procesu z najniższą pozycją MPI_COMM_WORLD w najniższej
jobid, aby miał status niezerowy i (b) wyświetli komunikat podsumowujący status wyjścia
praca podstawowa i wszystkie dodatkowe.

· jeśli ustawiona jest opcja wiersza cmd --report-child-jobs-separately, zwrócimy -tylko-
status wyjścia zadania głównego. Każdy niezerowy status wyjścia w zadaniach dodatkowych będzie
zgłaszane wyłącznie w zbiorczym zestawieniu drukowanym.

Domyślnie OMPI rejestruje i odnotowuje, że procesy MPI zostały zakończone z niezerowym zakończeniem
status. Generalnie nie jest to uważane za „nienormalne zakończenie” – tj. OMPI tego nie zrobi
przerwać zadanie MPI, jeśli jeden lub więcej procesów zwróci status niezerowy. Zamiast tego domyślnie
zachowanie po prostu raportuje liczbę procesów kończących się statusem niezerowym
zakończenie pracy.

Jednak w niektórych przypadkach pożądane może być przerwanie zadania po każdym procesie
kończy się statusem niezerowym. Na przykład zadanie inne niż MPI może wykryć zły wynik
obliczenia i chce je przerwać, ale nie chce wygenerować pliku podstawowego. Albo praca w MPI
może kontynuować po wywołaniu MPI_Finalize, ale wskazuje, że wszystkie procesy powinny zostać przerwane
z powodu niektórych wyników po MPI.

Nie przewiduje się, aby taka sytuacja występowała często. Jednak w interesie
służenia szerszej społeczności, OMPI dysponuje teraz środkami umożliwiającymi użytkownikom kierowanie nią
zadania zostaną przerwane po wyjściu dowolnego procesu z niezerowym statusem. Ustawianie parametru MCA
„orte_abort_on_non_zero_status” na 1 spowoduje, że OMPI przerwie wszystkie procesy, gdy
wygląda tak
kończy się ze statusem niezerowym.

Zakończenia spowodowane w ten sposób będą zgłaszane na konsoli jako „nieprawidłowe
zakończenie”, z identyfikacją pierwszego procesu, który zakończy proces, wraz ze statusem wyjścia.

PRZYKŁADY

Koniecznie zapoznaj się także z przykładami w powyższych sekcjach.

mpirun -np 4 -mca btl ib, tcp, self prog1
Uruchom 4 kopie prog1, używając BTL „ib”, „tcp” i „self” do transportu MPI
wiadomości.

mpirun -np 4 -mca btl tcp, sm, self
--mca btl_tcp_if_include eth0 prog1
Uruchom 4 kopie prog1, używając BTL „tcp”, „sm” i „self” do transportu MPI
wiadomości, przy czym protokół TCP używa do komunikacji tylko interfejsu eth0. Zauważ, że inne BTL
mają podobne parametry if_include MCA.

POWRÓT WARTOŚĆ

mpiruna zwraca 0, jeśli wszystkie procesy rozpoczęły się przez mpiruna wyjdź po wywołaniu MPI_FINALIZE. A
Wartość różna od zera jest zwracana, jeśli w mpirun wystąpił błąd wewnętrzny lub jeden lub więcej
procesy zakończyły się przed wywołaniem MPI_FINALIZE. Jeśli w mpirunie wystąpił błąd wewnętrzny,
zwracany jest odpowiedni kod błędu. W przypadku zakończenia jednego lub większej liczby procesów
przed wywołaniem MPI_FINALIZE zwracana wartość rangi MPI_COMM_WORLD procesu
że mpiruna pierwsze powiadomienia zmarły przed wywołaniem MPI_FINALIZE zostaną zwrócone. Zauważ, że
ogólnie rzecz biorąc, będzie to pierwszy proces, który umarł, ale nie ma gwarancji, że tak się stanie.

Użyj orterun online korzystając z usług onworks.net