mpiexec.openmpi - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

orterun, mpirun, mpiexec - виконувати послідовні та паралельні завдання в Open MPI. ошрун, шмемрун
- Виконуйте послідовні та паралельні завдання в Open SHMEM.

Примітка: мпірун, mpiexec та ортерун є синонімами один для одного, а також ошрун,
shmemrun у разі встановлення Open SHMEM. Використання будь-якого з назв призведе до того ж
поведінка.

СИНТАКСИС

Модель одного процесу з кількома даними (SPMD):

мпірун [ варіанти ] [ ]

Модель з кількома інструкціями і багатьма даними (MIMD):

мпірун [ глобальні_параметри ]
[локальні_опції1] [ ] :
[локальні_опції2] [ ] :
... :
[локальні_параметриN] [ ]

Зауважте, що в обох моделях виклик мпірун через ім'я абсолютного шляху еквівалентно
із зазначенням --префікс варіант з a значення, еквівалентне каталогу де мпірун
знаходиться, мінус його останній підкаталог. Наприклад:

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

еквівалентна

% мпірун --префікс / usr / local

QUICK РЕЗЮМЕ

Якщо ви просто шукаєте, як запустити програму MPI, ви, ймовірно, захочете використовувати a
командний рядок такого вигляду:

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

Це запустить X копій у вашому поточному середовищі виконання (якщо працює під
підтримуваний менеджер ресурсів Open MPI мпірун зазвичай автоматично використовує
відповідний запуск процесу менеджера ресурсів, на відміну від, наприклад, рш or SSH,
які вимагають використання файлу хосту або за замовчуванням запускатимуть усі копії X на файлі
localhost), планування (за замовчуванням) у цикловому порядку за слотом ЦП. Дивіться решту
цю сторінку для більш детальної інформації.

Зауважте, що mpirun автоматично пов’язує процеси на початку серії v1.8.
За відсутності будь-яких подальших директив використовуються два шаблони зв'язування:

Bind до серцевина: коли кількість процесів <= 2

Bind до гніздо: коли кількість процесів > 2

Якщо ваша програма використовує потоки, то ви, ймовірно, хочете переконатися, що це не так
пов’язаний взагалі (за допомогою параметра --bind-to none) або прив’язаний до кількох ядер за допомогою an
відповідний рівень зв'язування або конкретна кількість елементів обробки для кожної програми
процесу.

ВАРІАНТИ

мпірун надішле кожному з них назву каталогу, де його було викликано на локальному вузлі
віддалених вузлів і спробуйте перейти до цього каталогу. Дивіться розділ «Поточна робота
Каталог» нижче для отримання додаткової інформації.

Виконуваний файл програми. Це визначено як перший невизнаний аргумент
до мпіруна.

Передавайте ці аргументи часу виконання кожному новому процесу. Це завжди має бути
останні аргументи до мпірун. Якщо використовується файл контексту програми, буде
ігнорується.

-h, --допомога
Відобразити довідку для цієї команди

-q, --спокійно
Придушення інформаційних повідомлень від orterun під час виконання програми.

-v, -багатослівний
Будьте багатослівними

-V, -- версія
Роздрукувати номер версії. Якщо інші аргументи не наведені, це також спричинить
orterun для виходу.

-дисплей-карта, --дисплей-карта
Перед запуском відобразіть таблицю із зазначенням розташування кожного процесу.

-display-devel-map, --display-devel-map
Відобразіть більш детальну таблицю, що показує відображене розташування кожного попереднього процесу
для запуску (зазвичай цікавий для розробників).

-дисплей-розподіл, --дисплей-розподіл
Відобразити виявлений розподіл ресурсів.

Використовуйте один із наведених нижче параметрів, щоб указати, на яких хостах (вузлах) кластера працювати.
Зауважте, що з початку випуску v1.8, mpirun запускатиме демон на кожному хості
у виділенні (з зміненим наступними параметрами) на самому початку
виконання, незалежно від того, чи будуть зрештою зіставлені процеси програми
виконати там. Це зроблено, щоб дозволити збір інформації про топологію апаратного забезпечення з
віддалені вузли, що дозволяє нам відображати процеси з відомою топологією. Однак це a
змінити поведінку в попередніх випусках, де демони запускалися лише після відображення
було завершено, і, таким чином, відбувалося лише на вузлах, де фактично відбувалися б процеси програми
виконуватись.

-H, -господар, --господар
Список хостів, на яких можна викликати процеси.

-файл хосту, --файл хоста
Надайте файл хоста для використання.

- машинний файл, --machinefile
Синонім до -файл хосту.

-набір процесора, --набір процесора
Обмежити запущені процеси вказаним логічним процесором на кожному вузлі. Зауважте, що
параметри зв'язування все одно застосовуватимуться в межах зазначеного конверта - наприклад, ви можете
вибрати прив’язувати кожен процес лише до одного процесора в межах зазначеного набору процесорів.

Наступні параметри вказують кількість процесів для запуску. Зауважте, що жодна з
параметри передбачають особливу політику зв'язування - наприклад, запит N процесів для кожного сокета
не означає, що процеси будуть прив'язані до сокета.

-c, -n, --н, -наприклад <#>
Запустіть таку кількість копій програми на заданих вузлах. Цей параметр вказує на це
зазначений файл є виконуваною програмою, а не контекстом програми. Якщо ні
значення надається для кількості копій для виконання (тобто ні "-np", ні
його синоніми надаються в командному рядку), Open MPI буде виконуватися автоматично
копію програми в кожному слоті процесу (опис «процесу
слот"). Однак ця функція може використовуватися лише в моделі SPMD і повернеться
помилка (без початку виконання програми) інакше.

— карта-по ppr:N:
Запустіть N-кратну кількість об’єктів зазначеного типу на кожному вузлі.

-npersocket, --npersocket <#persocket>
На кожному вузлі запустіть цей процес у багато разів більше, ніж кількість процесорних сокетів
вузол. The -npersocket опція також включає -прив'язка до розетки варіант.
(не підтримується на користь --map-by ppr:n:socket)

-npernode, --npernode <#pernode>
На кожному вузлі запустіть стільки процесів. (не підтримується на користь --map-by
ppr:n:вузол)

-пернода, --первузла
На кожному вузлі запустіть один процес - еквівалент -npernode 1. (не підтримується в
на користь --map-by ppr:1:node)

Щоб відобразити процеси:

--mapa-by
Зіставте з вказаним об’єктом, за замовчуванням розетка. Підтримувані варіанти включають слот,
hwthread, core, L1cache, L2cache, L3cache, socket, numa, board, node, sequential,
відстань, і ппр. Будь-який об’єкт може включати модифікатори, додаючи : і any
комбінація PE=n (прив’язувати n елементів обробки до кожного процесу), SPAN (баланс навантаження
процесів у межах розподілу), ПЕРЕПРИПИСКУ (дозволити більше процесів на вузлі
ніж елементи обробки), і НЕ ПІДПИСАТИСЯ. Сюди входить PPR, де
шаблон закінчується іншим двокрапкою, щоб відокремити його від модифікаторів.

- bycore, -- bycore
Відображати процеси за ядром (застаріло на користь --map-by core)

-бісокет, --bysocket
Відображати процеси за сокетом (застаріло на користь --map-by socket)

-нолокальний, --нолокальний
Не запускайте жодних копій запущеної програми на тому самому вузлі, що й orterun
біг. Ця опція замінить список локального хоста з --господар або будь-який інший
механізм специфікації хоста.

-не передплачувати, --не перепідписуватися
Не перевищуйте підписку на жодні вузли; помилка (без запуску будь-яких процесів), якщо
запитувана кількість процесів призведе до надмірної підписки. Цей варіант неявно
встановлює "max_slots" рівним значенню "slots" для кожного вузла.

-байвузол, --bynode
Запуск обробляє по одному на вузол, циклічно за вузлом. Це
рівномірно розподіляє процеси між вузлами та призначає ранги MPI_COMM_WORLD у раунді
Робін, «по вузлу».

Щоб упорядкувати ранги процесів у MPI_COMM_WORLD:

--по рангу
Ранжування в цикловому порядку відповідно до вказаного об’єкта, за замовчуванням слот.
Підтримувані параметри включають слот, hwthread, core, L1cache, L2cache, L3cache, socket,
numa, board і node.

Для зв'язування процесу:

--зв'язувати з
Прив’язувати процеси до вказаного об’єкта, за замовчуванням ядро. Підтримувані параметри включають
слот, hwthread, core, l1cache, l2cache, l3cache, socket, numa, board і немає.

-cpus-per-proc, --cpus-per-proc <#perproc>
Прив’язуйте кожен процес до вказаної кількості процесорів. (не підтримується на користь --map-
за :PE=n)

-cpus-per-rank, --cpus-per-rank <#perrank>
Псевдонім для -cpus-per-proc. (не підтримується на користь --map-by :PE=n)

-прив'язування до ядра, --прив'язування до ядра
Прив’язування процесів до ядер (застаріло на користь --bind-to core)

-прив'язка до розетки, --прив'язка до сокета
Прив’язувати процеси до процесорних сокетів (застаріло на користь --bind-to socket)

-прив'язувати до жодного, --прив'язувати до-нічого
Не прив'язувати процеси (застаріло на користь --bind-to none)

-звіти-прив'язки, --прив'язки до звітів
Повідомте про будь-які прив’язки для запущених процесів.

- слот-список, --список слотів
Список ідентифікаторів процесорів, які будуть використовуватися для зв’язування процесів MPI. Зазначені прив'язки
буде застосовано до всіх процесів MPI. Дивіться пояснення нижче щодо синтаксису.

Для ранг-файлів:

-рф, -- рейтинговий файл
Надайте файл ранг-файлу.

Щоб керувати стандартним вводом-виводом:

-ім'я вихідного файлу, --назва вихідного файлу
Переспрямуйте stdout, stderr і stddiag всіх процесів на унікальний процес
версію вказаного імені файлу. Будь-які каталоги в імені файлу будуть
створюватися автоматично. Кожен вихідний файл складатиметься з filename.id, де
id буде ранг процесів у MPI_COMM_WORLD, заповнений ліворуч нулями для
правильне впорядкування в списках.

-stdin, --stdin
Ранг MPI_COMM_WORLD процесу, який має отримати stdin. За замовчуванням – до
переадресувати stdin до MPI_COMM_WORLD рангу 0, але цей параметр можна використовувати для пересилання
stdin до будь-якого процесу. Також прийнятно вказувати ніхто, вказуючи, що ні
процеси повинні отримувати stdin.

-тег-виведення, --тег-виведення
Позначте кожен рядок виводу до stdout, stderr і stddiag [робота,
MCW_rank] що вказує на ідентифікатор завдання процесу та ранг MPI_COMM_WORLD
процес, який генерував вихід, і канал, який його генерував.

-помітка часу, --помітка часу
Позначте час кожного рядка виводу до stdout, stderr і stddiag.

-xml, --xml
Надайте весь вихід у stdout, stderr і stddiag у форматі xml.

-xterm, --xterm
Відобразити вихідні дані процесів, визначених їхнім рейтингом MPI_COMM_WORLD
окремі вікна xterm. Розряди вказуються у вигляді списку, розділених комами
діапазонів, з -1, що вказує на всі. Для кожного буде створено окреме вікно
зазначений процес. Примітка: xterm зазвичай закриває вікно після завершення
процесу, що проходить в ньому. Однак, додавши "!" до кінця списку
зазначених рангів будуть надані відповідні параметри, щоб забезпечити збереження xterm
вікно відчинене після процес завершується, що дозволяє вам побачити процес"
вихід. Кожне вікно xterm згодом потрібно буде закрити вручну. Примітка: In
У деяких середовищах xterm може вимагати, щоб виконуваний файл був на шляху користувача, або
вказувати в абсолютному або відносному вираженні. Таким чином, може знадобитися вказати a
локальний виконуваний файл як "./foo" замість просто "foo". Якщо xterm не вдається знайти
виконуваний файл, mpirun зависне, але все одно правильно реагуватиме на ctrl-c. Якщо це
перевірте, чи правильно вказано виконуваний файл, і спробуйте
знову.

Щоб керувати файлами та середовищем виконання:

-доріжка, --шлях
який буде використовуватися під час спроби знайти потрібні виконувані файли. Це
використовується перед використанням локального параметра PATH.

--префікс
Каталог префіксів, який буде використовуватися для встановлення PATH та LD_LIBRARY_PATH на
віддалений вузол перед викликом Open MPI або цільового процесу. Дивіться розділ «Дистанційний
Розділ "Виконання" нижче.

--preload-двійковий
Скопіюйте вказані виконувані файли на віддалені машини, перш ніж запускати їх
процесів. Виконувані файли будуть скопійовані до каталогу сесії Open MPI і
буде видалено після завершення роботи.

--preload-files
Попередньо завантажте список файлів, розділених комами, до поточного робочого каталогу
віддалені машини, де процеси будуть запущені до запуску цих процесів.

--preload-files-dest-dir
Каталог призначення, який буде використовуватися для попереднього завантаження файлів, якщо він відрізняється від поточного
робочий каталог. За замовчуванням абсолютний і відносний шляхи надаються
--preload-files використовуються.

--tmpdir
Встановіть корінь для дерева каталогів сеансу лише для mpirun.

-wd
Синонім до -wdir.

-wdir
Перейдіть до каталогу перед виконанням програми користувача. Дивіться розділ «Поточний
Робочий каталог» для приміток щодо відносних шляхів. Примітка: Якщо -wdir варіант
з’являється як у командному рядку, так і в контексті програми, контекст буде
мати пріоритет над командним рядком. Таким чином, якщо шлях до потрібного wdir є
різні на серверних вузлах, то його потрібно вказати як абсолютний шлях, який
правильний для серверного вузла.

-x
Експортуйте вказані змінні середовища на віддалені вузли перед виконанням
програма. Для кожного можна вказати лише одну змінну середовища -x варіант. Існуючий
можна вказати змінні середовища або вказати нові імена змінних
відповідні значення. Наприклад:
% mpirun -x DISPLAY -x OFILE=/tmp/out ...

Парсер для -x варіант не дуже вишуканий; це навіть не розуміє
цитовані значення. Користувачам рекомендується встановлювати змінні в середовищі, а потім використовувати
-x експортувати (не визначати) їх.

Налаштування параметрів MCA:

-gmca, --gmca
Передайте глобальні параметри MCA, які застосовні до всіх контекстів. є
ім'я параметра; є значенням параметра.

-mca, --mca
Надсилайте аргументи в різні модулі MCA. Дивіться розділ "MCA" нижче.

Для налагодження:

-відлагоджувати, --відлагоджувати
Викличте налагоджувач рівня користувача, зазначений orte_base_user_debugger MCA
параметр.

-відладчик, --налагоджувач
Послідовність налагоджувачів для пошуку коли --відлагоджувати використовується (тобто синонім для
orte_base_user_debugger параметр MCA).

-телевізор, --телебачення
Запустіть процеси під налагоджувачем TotalView. Не підтримується зворотна сумісність
прапор. Синонім до --відлагоджувати.

Є також інші варіанти:

--allow-run-as-root
Дозволити мпірун виконуватися, коли виконується користувачем root (мпірун за замовчуванням переривання
при запуску як користувач root).

- перервано, --перервано <#>
Встановіть максимальну кількість перерваних процесів для відображення.

-- додаток
Надайте файл програми, ігноруючи всі інші параметри командного рядка.

-ср, --картофайл
Надайте файл картографії.

--гетеро
Вказує на те, що надається декілька контекстів app_contexts, які є сумішшю 32/64-біт
двійкові файли.

-відпустка-сесія-додається, --leave-session-attached
Не від’єднуйте демони OmpiRTE, які використовуються цією програмою. Це дозволяє відображати повідомлення про помилки
від демонів, а також від базового середовища (наприклад, якщо не вдається
запустити демон) для виведення.

-ompi-сервер, --ompi-сервер <uri or файл>
Вкажіть URI сервера Open MPI (або mpirun, який буде використовуватися як сервер),
ім'я файлу (вказано як file:filename), що містить цю інформацію, або
PID (зазначений як pid:#) mpirun, який буде використовуватися як
сервер. Open MPI-сервер використовується для підтримки даних кількох програм
обмінюватися за допомогою функцій MPI-2 MPI_Publish_name та MPI_Lookup_name.

-звіт-під, --report-pid
Роздрукуйте PID mpirun під час запуску. Канал має бути від "-" до indi
Зазначте, що pid має бути виведений у стандартний вихід, '+', щоб вказати, що pid має бути
бути виведено до stderr або імені файлу, до якого буде записано pid.

-звіт-урі, --report-uri
Роздрукуйте URI mpirun під час запуску. Канал має бути від "-" до indi
зазначити, що URI має бути виведений у стандартний вихід, '+', щоб вказати, що URI має бути
бути виведено до stderr або імені файлу, в який має бути записаний URI.

-сервер очікування, --очікування сервера
Призупиніть mpirun перед запуском завдання, поки не буде виявлено ompi-сервер. Це корисно
у сценаріях, де ompi-сервер можна запустити у фоновому режимі, слід негайно
від мпірун команду, яка бажає підключитися до неї. Мпірун зупиниться до будь-якого
встановлено контакт із зазначеним ompi-сервером або перевищено час очікування сервера.

-сервер-час очікування, --сервер-час очікування
Максимальна кількість часу (у секундах), протягом якого mpirun має чекати ompi-сервер
почати. За замовчуванням – 10 секунд.

Наступні параметри корисні для розробників; вони, як правило, не корисні для більшості
Користувачі ORTE та/або MPI:

-d, --debug-devel
Увімкнути налагодження OmpiRTE (рівень часу виконання в Open MPI). Це не
загалом корисний для більшості користувачів.

--debug-демони
Увімкнути налагодження будь-яких демонів OmpiRTE, які використовуються цією програмою.

--debug-daemons-file
Увімкнути налагодження будь-яких демонів OmpiRTE, які використовуються цією програмою, зберігаючи вихідні дані
файли.

-запуск-агент, --агент запуску
Ім’я виконуваного файлу, який буде використовуватися для запуску процесів на віддалених вузлах.
За замовчуванням — «ортоване». Цей параметр можна використовувати для тестування нових концепцій демона або для
передавати параметри назад демонам, не маючи, щоб сам mpirun їх побачив. Для
Наприклад, вказівка ​​агента запуску orted -mca odls_base_verbose 5 дозволяє
розробнику, щоб попросити orted про вихід налагодження без безладу від самого mpirun.

--непрефікс
Вимкніть автоматичну поведінку --prefix

Можуть бути перераховані інші варіанти мпірун --допомога.

Навколишнє середовище Змінні
MPIEXEC_TIMEOUT
Максимальна кількість секунд мпірун (mpiexec) буде працювати. Після цього багато
секунд, мпірун перерве запущене завдання та вийде.

ОПИС

Один виклик мпірун запускає програму MPI, що працює під відкритим MPI. Якщо
додаток є одним процесом з кількома даними (SPMD), додаток можна вказати на
мпірун command line.

Якщо додатком є ​​множинні інструкції з множинними даними (MIMD), що складається з кількох
програм, набір програм і аргумент можна вказати одним із двох способів: Розширений
Аргументи командного рядка та контекст програми.

Контекст програми описує набір програм MIMD, включаючи всі аргументи в a
окремий файл. Цей файл по суті містить кілька мпірун командних рядків, за винятком
сама назва команди. Можливість вказувати різні варіанти для різних
екземпляри програми є ще однією причиною використання контексту програми.

Розширені аргументи командного рядка дозволяють описати макет програми на
командний рядок за допомогою двокрапки (:) для розділення специфікації програм і аргументів.
Деякі параметри глобально встановлюються для всіх зазначених програм (наприклад, --hostfile), while
інші специфічні для однієї програми (наприклад, -np).

Уточнення Господар Nodes
Вузли хоста можна ідентифікувати на мпірун командний рядок за допомогою -господар варіант або в а
файл хосту.

Наприклад,

mpirun -H aa,aa,bb ./a.out
запускає два процеси на вузлі aa і один на bb.

Або розглянемо файл хоста

% cat myhostfile
aa слоти=2
bb слоти=2
cc слотів=2

Тут ми перераховуємо імена хостів (aa, bb і cc), а також кількість "слотів" для
кожен. Слоти вказують, скільки процесів потенційно може виконуватися на вузлі. На краще
продуктивності, кількість слотів може бути обрана як кількість ядер на вузлі або
кількість процесорних сокетів. Якщо файл хоста не надає інформацію про слоти, a
за замовчуванням приймається 1. Під час роботи з менеджерами ресурсів (наприклад, SLURM, Torque,
тощо), Open MPI отримає як імена хостів, так і кількість слотів безпосередньо з
менеджер ресурсів.

mpirun -hostfile myhostfile ./a.out
запустить два процеси на кожному з трьох вузлів.

mpirun -hostfile myhostfile -host aa ./a.out
запустить два процеси, обидва на вузлі aa.

mpirun -hostfile myhostfile -host dd ./a.out
не знайде хостів для запуску та перерве з помилкою. Тобто вказаний хост dd
не знаходиться у вказаному файлі хосту.

Уточнення Номер of процеси
Як ми щойно бачили, кількість процесів для запуску можна встановити за допомогою файлу хоста. Інший
механізми існують.

Кількість запущених процесів можна вказати як кратне кількості вузлів або
доступні процесорні гнізда. Наприклад,

mpirun -H aa,bb -npersocket 2 ./a.out
запускає процеси 0-3 на вузлі aa і процеси 4-7 на вузлі bb, де aa і bb обидва
подвійні сокетні вузли. The -npersocket опція також включає -прив'язка до розетки варіант
який обговорюється в наступному розділі.

mpirun -H aa,bb -npernode 2 ./a.out
запускає процеси 0-1 на вузлі aa і процеси 2-3 на вузлі bb.

mpirun -H aa,bb -npernode 1 ./a.out
запускає один процес на вузол хоста.

mpirun -H aa,bb -pernode ./a.out
те саме, що -npernode 1.

Інший варіант — вказати кількість процесів за допомогою -наприклад варіант. Розглянемо
тепер файл хоста

% cat myhostfile
aa слоти=4
bb слоти=4
cc слотів=4

тепер,

mpirun -hostfile myhostfile -np 6 ./a.out
запустить процеси 0-3 на вузлі aa і процеси 4-5 на вузлі bb. Нагадування
слоти у файлі хосту не використовуватимуться, оскільки -наприклад варіант вказав, що тільки 6
слід запустити процеси.

Карт процеси до Вузли: використання Політики
Наведені вище приклади ілюструють відображення процесів за замовчуванням до вузлів. Це
мапування також можна керувати за допомогою різних мпірун параметри, які описують політику відображення.

Розглянемо той самий файл хосту, як і вище, знову ж таки з -наприклад 6:

вузол aa вузол bb вузол cc

mpirun 0 1 2 3 4 5

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

mpirun -nolocal 0 1 2 3 4 5

Команда --mapa-by вузол параметр балансує навантаження процесів на доступних вузлах,
нумерація кожного процесу круговою системою.

Команда -нолокальний Опція запобігає відображенню будь-яких процесів на локальному хості (у цьому
вузол відмінка аа). Хоча мпірун зазвичай споживає мало системних ресурсів, -нолокальний може бути
корисно для запуску дуже великих завдань, де мпірун можливо, насправді знадобиться використовувати помітний
обсяг пам'яті та/або час обробки.

Коли -наприклад може вказати менше процесів, ніж є слотів, він також може переписати
слоти. Наприклад, з тим самим файлом хосту:

mpirun -hostfile myhostfile -np 14 ./a.out
запустить процеси 0-3 на вузлі aa, 4-7 на bb і 8-11 на cc. Потім він додасть
решта двох процесів до тих вузлів, які він вибере.

Також можна вказати ліміти на перепідписку. Наприклад, з тим самим файлом хосту:

mpirun -hostfile myhostfile -np 14 -nooversubscribe ./a.out
видасть помилку, оскільки -не передплачувати запобігає надмірній підписці.

Обмеження на надмірну підписку також можна вказати в самому файлі хосту:
% cat myhostfile
aa слоти=4 max_slots=4
bb max_slots=4
cc слотів=4

Команда max_slots поле визначає таку межу. Коли це станеться, ігрові автомати значення за замовчуванням дорівнює
ліміт. зараз:

mpirun -hostfile myhostfile -np 14 ./a.out
спричиняє запуск перших 12 процесів, як і раніше, але два решти
процеси будуть примусово переміщені на вузол cc. Два інших вузла захищені
hostfile проти перевищення підписки цим завданням.

Використання --не перепідписуватися Опція може бути корисною, оскільки Open MPI наразі не отримує
значення "max_slots" з менеджера ресурсів.

Звичайно, -наприклад також можна використовувати з -H or -господар варіант. Наприклад,

mpirun -H aa,bb -np 8 ./a.out
запускає 8 процесів. Оскільки вказано лише два хости, після перших двох
процеси відображаються, один на aa і один на bb, інші процеси переповнюються
зазначені хости.

А ось приклад MIMD:

mpirun -H aa -np 1 ім'я хоста: -H bb,cc -np 2 час безперервної роботи
запустить процес 0 ім'я хоста на вузлі aa і процесах 1 і 2 кожен запущений
час безвідмовної роботи на вузлах bb і cc відповідно.

Зіставлення, рейтинг, та Прив'язка: Oh Мій!
Open MPI використовує трифазну процедуру для присвоєння місцеположень і рангів процесу:

відображення Кожному процесу призначає розташування за замовчуванням

ранжування Призначає значення рангу MPI_COMM_WORLD кожному процесу

обов'язковий Обмежує виконання кожного процесу на певних процесорах

Команда відображення step використовується для призначення розташування за замовчуванням кожному процесу на основі картографа
будучи працевлаштованим. Відображення за слотом, вузлом і послідовно призводить до призначення
процесів до рівня вузла. На відміну від цього, відображення за об’єктом дозволяє картографу призначати
процес до фактичного об'єкта на кожному вузлі.

Примітка: Розташування, призначене процесу, не залежить від того, де він буде прив'язаний -
присвоєння використовується виключно як вхідні дані для алгоритму прив’язки.

Відображення процесів процесів до вузлів можна визначити не тільки за допомогою загальних політик
але також, якщо необхідно, з використанням довільних відображень, які неможливо описати простим
політика. Можна використовувати «послідовний маппер», який читає файл хоста рядок за рядком,
призначення процесів вузлам у будь-якому порядку, визначеному файлом хоста. Використовувати -mca rmaps
далі варіант. Наприклад, використовуючи той самий файл хосту, що й раніше:

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

запустить три процеси, по одному на кожному з вузлів aa, bb і cc відповідно. Слот
кількість не має значення; один процес запускається на рядок на будь-якому вузлі, зазначеному в списку
лінія.

Інший спосіб вказати довільні відображення - це файл ранг, який надає вам детальну інформацію
також контроль за прив'язкою процесу. Файли рангів обговорюються нижче.

Другий етап фокусується на ранжування процесу в MPI_COMM_WORLD завдання.
Open MPI відокремлює це від процедури відображення, щоб забезпечити більшу гнучкість у
відносне розміщення процесів MPI. Це найкраще проілюструвати, зважаючи на наступне
два випадки, коли ми використовували параметр —map-by ppr:2:socket:

вузол aa вузол bb

ранг за ядром 0 1 ! 2 3 4 5 ! 6 7

ранг за сокетом 0 2 ! 1 3 4 6 ! 5 7

rank-by socket:span 0 4 ! 1 5 2 6! 3 7

Ранжування за ядром і слотами дає ідентичний результат - просте прогресування
MPI_COMM_WORLD займає місце в кожному вузлі. Ранжування за сокетом виконує круговий рейтинг
кожного вузла, доки всім процесам не буде присвоєно ранг MCW, а потім переходить до
наступний вузол. Додавання span модифікатор директиви ранжирування викликає алгоритм ранжирування
розглядати весь розподіл як єдину сутність - таким чином, призначаються ранги MCW
через усі розетки, перш ніж повернутися до початку.

Команда обов'язковий Фаза фактично пов'язує кожен процес із заданим набором процесорів. Це може
покращити продуктивність, якщо операційна система розміщує процеси неоптимально. Для
наприклад, він може переписати деякі багатоядерні гнізда процесора, залишаючи інші гнізда
простою; це може призвести до того, що процеси без потреби боротимуться за загальні ресурси. Або це
може поширити процеси занадто широко; це може бути неоптимальним, якщо продуктивність програми
є чутливим до витрат на міжпроцесний зв'язок. Прив’язка також може зберегти дію
системи від мігруючих процесів надмірно, незалежно від того, наскільки ці процеси оптимальні
були розміщені для початку.

Процесори, які будуть використовуватися для зв’язування, можна ідентифікувати з точки зору топологічних груп
- наприклад, прив'язка до l3cache буде прив'язувати кожен процес до всіх процесорів у межах
один кеш-пам'ять L3 в межах призначеного їм розташування. Таким чином, якщо процес призначений
відображати на певний сокет, потім a -зв'язувати з l3cache директива спричинить процес
прив’язаний до процесорів, які спільно використовують один кеш L3 в цьому сокеті.

Щоб допомогти збалансувати навантаження, директива зв’язування використовує цикловий метод під час прив’язки до
рівні нижчі, ніж використовуються в картографі. Наприклад, розглянемо випадок, коли відображено роботу
до рівня гнізда, а потім прив’язаний до ядра. Кожен сокет матиме кілька ядер, тому якщо
кілька процесів відображаються на заданий сокет, алгоритм прив’язки призначає кожен
процес, розташований у сокеті до унікального ядра по круговому порядку.

Крім того, процеси, відображені l2cache, а потім прив’язані до сокету, будуть просто прив’язані
до всіх процесорів у сокеті, де вони розташовані. Таким чином користувачі можуть
здійснювати детальний контроль над відносним розташуванням MCW-рангу та прив'язкою.

Нарешті, --прив'язки до звітів можна використовувати для звітування про прив’язки.

Як приклад розглянемо вузол з двома процесорними сокетами, кожен з яких містить чотири ядра. ми
пробіг мпірун з -наприклад 4 --прив'язки до звітів і наступні додаткові опції:

% mpirun ... --map-by core --bind-to core
[...] ... прив’язування дитини [...,0] до процесора 0001
[...] ... прив’язування дитини [...,1] до процесора 0002
[...] ... прив’язування дитини [...,2] до процесора 0004
[...] ... прив’язування дитини [...,3] до процесора 0008

% mpirun ... --map-by socket --bind-to socket
[...] ... прив'язування дитини [...,0] до сокету 0 cpus 000f
[...] ... прив'язування дитини [...,1] до сокета 1 процесора 00f0
[...] ... прив'язування дитини [...,2] до сокету 0 cpus 000f
[...] ... прив'язування дитини [...,3] до сокета 1 процесора 00f0

% mpirun ... --map-by core:PE=2 --bind-to core
[...] ... прив’язування дитини [...,0] до процесора 0003
[...] ... прив'язування дитини [...,1] до процесора 000c
[...] ... прив’язування дитини [...,2] до процесора 0030
[...] ... прив'язування дитини [...,3] до процесора 00c0

% mpirun ... --bind-to none

Тут, --прив'язки до звітів показує зв’язування кожного процесу як маску. У першому випадку,
процеси зв’язуються з послідовними ядрами, як зазначено масками 0001, 0002, 0004 і
0008. У другому випадку процеси прив'язуються до всіх ядер на послідовних сокетах, як зазначено
за масками 000f і 00f0. Процес циклічно проходить через гнізда процесора.
Робін моди стільки разів, скільки потрібно. У третьому випадку маски показують нам, що 2
ядра були зв'язані для кожного процесу. У четвертому випадку прив'язка відключена і немає
повідомляється про прив’язки.

Підтримка Open MPI для прив’язки процесів залежить від базової операційної системи.
Тому певні параметри прив’язки процесу можуть бути доступні не в кожній системі.

Прив’язка процесу також може бути встановлена ​​за допомогою параметрів MCA. Їх використання менш зручне, ніж
у мпірун варіанти. З іншого боку, параметри MCA можна встановлювати не тільки на
мпірун командному рядку, але в якості альтернативи в системному або користувачем файлі mca-params.conf або як
змінні середовища, як описано в розділі MCA нижче. Деякі приклади включають:

значення ключа параметра MCA параметра mpirun

--map-by core ядро ​​rmaps_base_mapping_policy
--map-by socket rmaps_base_mapping_policy сокет
--rank-by core ядро ​​rmaps_base_ranking_policy
--bind-to core hwloc_base_binding_policy ядро
--bind-to socket hwloc_base_binding_policy сокет
--bind-to none hwloc_base_binding_policy немає

Ранг-файли
Файли рангів – це текстові файли, які вказують детальну інформацію про те, як окремі процеси
повинні бути зіставлені з вузлами і до якого(их) процесора(ів) вони мають бути прив’язані. Кожен рядок a
rankfile вказує місце розташування одного процесу (для завдань MPI посилається «ранг» процесу
до свого рангу в MPI_COMM_WORLD). Загальна форма кожного рядка в рейтинговому списку:

звання = слот=

Наприклад:

$ cat myrankfile
ранг 0=aa слот=1:0-2
ранг 1=bb слот=0:0,1
ранг 2=cc слот=1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Значить, що

Ранг 0 працює на вузлі aa, прив’язаний до логічного сокета 1, ядра 0-2.
Ранг 1 працює на вузлі bb, прив’язаний до логічного сокета 0, ядра 0 і 1.
Ранг 2 працює на вузлі cc, прив’язаному до логічних ядер 1 і 2.

Для вказівки також можна використовувати файли рангів фізичний розташування процесора. В цьому випадку,
синтаксис дещо інший. Розетки більше не розпізнаються, а номер слота
має бути вказаний номер фізичного PU, оскільки більшість ОС не призначають унікального фізичного
ідентифікатор кожного ядра у вузлі. Таким чином, правильний фізичний ранг-файл виглядає приблизно так
наступні:

$ cat myphysicalrankfile
ранг 0=aa слот=1
ранг 1=bb слот=8
ранг 2=cc слот=6

Це означає, що

Ранг 0 працюватиме на вузлі aa, прив’язаному до ядра, яке містить фізичний PU 1
Ранг 1 працюватиме на вузлі bb, прив’язаному до ядра, яке містить фізичний PU 8
Ранг 2 працюватиме на вузлі cc, прив’язаному до ядра, яке містить фізичний PU 6

Ранг-файли розглядаються як логічний за замовчуванням і параметр MCA
rmaps_rank_file_physical має бути встановлено в 1, щоб вказати, що файл ранг має бути
розглядається як фізичний.

Наведені вище імена хостів є «абсолютними», що означає фактичні імена хостів, які можна розв’язувати
вказано. Однак імена хостів також можна вказати як «відносні», тобто вони є
зазначений щодо зовнішнього списку імен хостів (наприклад, за допомогою mpirun's
-- аргумент хоста, файл хоста або планувальник завдань).

«Відносна» специфікація має вигляд «+n ", де X - ціле число, що вказує
X-те ім'я хосту в наборі всіх доступних імен хостів, індексованих з 0. Наприклад:

$ cat myrankfile
rank 0=+n0 slot=1:0-2
ранг 1=+n1 слот=0:0,1
ранг 2=+n2 слот=1-2
$ mpirun -H aa,bb,cc,dd -rf myrankfile ./a.out

Починаючи з Open MPI версії 1.7, усі місця розташування роз'ємів/ядра вказуються як логічний
індекси (використовується серія Open MPI v1.6 фізичний індекси). Ви можете використовувати такі інструменти, як
HWLOC "lstopo" для пошуку логічних індексів сокетів і ядер.

додаток Контекст or Виконуваний Програма?
Щоб розрізнити дві різні форми, мпірун шукає в командному рядку -- додаток варіант.
Якщо вказано, то файл, названий у командному рядку, вважається файлом
контекст програми. Якщо він не вказано, то вважається, що файл є виконуваним
програми.

Знаходження Файли
Якщо для файлу не вказано відносний або абсолютний шлях, Open MPI спочатку шукатиме
файлів шляхом пошуку в каталогах, визначених файлом --шлях варіант. Якщо немає --шлях
встановлено параметри або якщо файл не знайдено в --шлях розташування, тоді Open MPI здійснить пошук
змінна середовища PATH користувача, визначена на вихідному вузлі.

Якщо вказано відносний каталог, він повинен бути відносно початкового робочого каталогу
визначається за допомогою конкретного стартера. Наприклад, при використанні запусків rsh або ssh,
початковий каталог — $HOME за замовчуванням. Інші початківці можуть встановити початковий каталог на
поточний робочий каталог із виклику мпірун.

Поточний Робочий Каталог
Команда -wdir параметр mpirun (і його синонім, -wd) дозволяє користувачеві змінити на довільний
каталог перед запуском програми. Його також можна використовувати в контекстних файлах програми
щоб вказати робочі каталоги на певних вузлах та/або для конкретних програм.

Якщо -wdir Параметр відображається як у файлі контексту, так і в командному рядку, контекст
каталог файлів замінить значення командного рядка.

Якщо -wdir якщо вказано параметр, Open MPI спробує змінити на вказаний
каталог на всіх віддалених вузлах. Якщо це не вдасться, мпірун перерве.

Якщо -wdir опція НЕ вказано, Open MPI надішле ім’я каталогу куди мпірун
був викликаний на кожному з віддалених вузлів. Віддалені вузли спробують змінити це
каталог. Якщо вони не можуть (наприклад, якщо каталог не існує на цьому вузлі), то
Відкритий MPI використовуватиме каталог за замовчуванням, визначений запуском.

Усі зміни каталогу відбуваються до того, як буде запущена програма користувача; воно не чекає, поки
MPI_INIT це називається.

стандарт I / O
Open MPI спрямовує стандартний вхід UNIX до /dev/null для всіх процесів, крім
Процес MPI_COMM_WORLD ранг 0. Процес MPI_COMM_WORLD рангу 0 успадковує стандартний вхід
від мпірун. Примітка: Вузол, який викликав мпірун не обов’язково збігається з вузлом де
знаходиться процес MPI_COMM_WORLD рангу 0. Open MPI обробляє перенаправлення мпірун's
стандартний вхід для процесу рангу 0.

Open MPI спрямовує стандартний вихід UNIX і помилки з віддалених вузлів на вузол, який викликав
мпірун і друкує його на стандартному виводі/помилку мпірун. Місцеві процеси успадковують
стандартний вихід/помилка мпірун і передати до нього безпосередньо.

Таким чином, можна перенаправляти стандартний ввод-вивод для Open MPI-додатків за допомогою
типова процедура перенаправлення оболонки ввімкнена мпірун.

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

Зверніть увагу, що в цьому прикладі тільки процес MPI_COMM_WORLD рангу 0 отримає потік
від мій_вхід на stdin. stdin на всіх інших вузлах буде прив'язаний до /dev/null.
Однак стандартний вихід з усіх вузлів буде зібрано в файл мій_вихід файлу.

Сигнал Розмноження
Коли orterun отримує SIGTERM і SIGINT, він намагатиметься вбити всю роботу
надсилання всіх процесів у завдання SIGTERM, чекаючи невелику кількість секунд, потім
надсилання всіх процесів у завдання SIGKILL.

Сигнали SIGUSR1 і SIGUSR2, отримані orterun, поширюються на всі процеси в
роботу.

Можна включити пересилання SIGSTOP і SIGCONT до програми, що виконується mpirun, за допомогою
встановлення для параметра MCA orte_forward_job_control значення 1. Сигнал SIGTSTOP для mpirun
потім спричинити надсилання сигналу SIGSTOP до всіх програм, запущених mpirun і
так само сигнал SIGCONT до mpirun спричинить надсилання SIGCONT.

Інші сигнали наразі не поширюються за допомогою orterun.

Процес Припинення / Сигнал Обробка
Під час виконання програми MPI, якщо будь-який процес загине ненормально (або завершується
перед викликом MPI_FINALIZEабо смерть в результаті сигналу), мпірун роздрукуватиме
повідомлення про помилку та закрити решту програми MPI.

Обробникам сигналів користувача, ймовірно, слід уникати спроб очищення стану MPI (Open MPI є
наразі не безпечний для асинхронного сигналу; побачити MPI_Init_thread(3) для детальної інформації про
MPI_THREAD_MULTIPLE і безпека ниток). Наприклад, якщо виникла помилка сегментації в
MPI_SEND (можливо, тому, що був переданий поганий буфер) і обробник сигналу користувача
викликається, якщо цей обробник користувача намагається викликати MPI_FINALIZE, Погані речі можуть статися
оскільки Open MPI вже був "в" MPI, коли сталася помилка. Так як мпірун помітить
що процес загинув через сигнал, це, ймовірно, не потрібно (і найбезпечніше) для
користувач очищає лише стан, що не є MPI.

Процес Навколишнє середовище
Процеси в додатку MPI успадковують своє середовище від демона Open RTE
вузол, на якому вони працюють. Середовище, як правило, успадковується від
оболонка користувача. На віддалених вузлах точне середовище визначається модулем MCA завантаження
використовується. Файл рш модуль запуску, наприклад, використовує будь-який рш/SSH щоб запустити Open RTE
демон на віддалених вузлах і зазвичай виконує один або кілька файлів налаштування оболонки користувача
перед запуском демона Open RTE. При запуску динамічно пов’язаних програм, які
вимагають LD_LIBRARY_PATH змінна середовища, яку потрібно встановити, необхідно подбати про забезпечення
щоб він правильно налаштований під час завантаження Open MPI.

Додаткову інформацію див. у розділі «Віддалене виконання».

віддалений Виконання
Відкритий MPI вимагає, щоб PATH змінна середовища бути встановлена ​​для пошуку виконуваних файлів на віддаленому
вузли (зазвичай це необхідно лише в рш- або SSH-на основі середовища --
пакетні/заплановані середовища зазвичай копіюють поточне середовище для виконання
віддалені робочі місця, тому якщо поточне середовище є PATH та / або LD_LIBRARY_PATH правильно встановити,
на віддалених вузлах також буде правильно налаштовано). Якщо Open MPI був скомпільований із спільним
підтримка бібліотеки, також може знадобитися мати LD_LIBRARY_PATH змінна оточення
також на віддалених вузлах (особливо для пошуку спільних бібліотек, необхідних для запуску користувача
програми MPI).

Однак не завжди бажано або можливо редагувати файли запуску оболонки для встановлення PATH
та / або LD_LIBRARY_PATH, --префікс доступна опція для деяких простих конфігурацій
де це неможливо.

Команда --префікс параметр приймає один аргумент: базовий каталог на віддаленому вузлі де
Встановлено відкритий MPI. Open MPI використовуватиме цей каталог для налаштування пульта PATH та
LD_LIBRARY_PATH перед запуском будь-якої програми Open MPI або користувача. Це дозволяє бігати
Відкривайте завдання MPI без попереднього налаштування PATH та LD_LIBRARY_PATH на пульті дистанційного керування
вузли.

Open MPI додає базову назву поточного вузла "bindir" (каталог, де Open MPI
встановлені виконувані файли) до префікса і використовує його для встановлення PATH на віддаленому вузлі.
Аналогічно, Open MPI додає базову назву поточного вузла "libdir" (каталог, де
Відкриті бібліотеки MPI встановлені) на префікс і використовує його для встановлення LD_LIBRARY_PATH
на віддаленому вузлі. Наприклад:

Локальний каталог: /local/node/directory/bin

Локальний libdir: /local/node/directory/lib64

Якщо використовується такий командний рядок:

% mpirun --префікс /віддалений/вузол/каталог

Відкритий MPI додасть "/remote/node/directory/bin" до файлу PATH та
"/remote/node/directory/lib64" до D_LIBRARY_PATH на віддаленому вузлі перед спробою
виконувати будь-що.

Команда --префікс параметра недостатньо, якщо шляхи встановлення на віддаленому вузлі є
відрізняється від локального вузла (наприклад, якщо "/ lib" використовується на локальному вузлі, але "/lib64"is
використовується на віддаленому вузлі), або якщо шляхи інсталяції є чимось іншим, ніж a
підкаталог під загальним префіксом.

Зверніть увагу, що виконання мпірун через абсолютний шлях еквівалентно вказівці --префікс
без останнього підкаталогу в абсолютному імені шляху до мпірун, Наприклад:

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

еквівалентна

% мпірун --префікс / usr / local

Експортується Навколишнє середовище Змінні
Усі змінні середовища, названі у формі OMPI_*, будуть автоматично експортовані
до нових процесів на локальних і віддалених вузлах. Параметри навколишнього середовища також можуть бути
встановлюється/пересилається до нових процесів за допомогою параметра MCA mca_base_env_list, -x
варіант до мпірун не підтримується, але синтаксис параметра MCA відповідає попередньому
приклад. У той час як синтаксис -x параметр і параметр MCA дозволяють визначити new
змінних, зауважте, що синтаксичний аналізатор для цих параметрів наразі не дуже складний -
він навіть не розуміє цитованих значень. Користувачам рекомендується встановлювати змінні в
середовище та використовувати можливість їх експорту; не визначати їх.

Установка MCA параметри
Команда -mca Перемикач дозволяє передавати параметри в різні MCA (модульний компонент
Архітектура) модулі. Модулі MCA мають безпосередній вплив на програми MPI, оскільки дозволяють
настроювані параметри, які встановлюються під час виконання (наприклад, до якого драйвера пристрою зв’язку BTL
використовувати, які параметри передати цьому BTL тощо).

Команда -mca switch приймає два аргументи: та , аргумент загалом
вказує, який модуль MCA отримає значення. Наприклад, використовується "btl".
щоб вибрати, який BTL використовуватиметься для транспортування повідомлень MPI. The аргументом є
значення, яке передається. Наприклад:

mpirun -mca btl tcp,self -np 1 foo
Вказує Open MPI використовувати BTL "tcp" і "self", а також запустити одну копію "foo" і
виділений вузол.

mpirun -mca btl self -np 1 foo
Вказує Open MPI використовувати «власний» BTL і запустити одну копію «foo» і виділений
вузол.

Команда -mca Перемикач можна використовувати кілька разів, щоб указати різні та / або
аргументи. Якщо те саме вказано більше одного разу, s з'єднані
з комою (","), що відокремлює їх.

Зауважте, що -mca switch - це просто ярлик для встановлення змінних середовища. The
такого ж ефекту можна досягти, встановивши перед цим відповідні змінні середовища
біг мпірун. Форма змінних середовища, які встановлює Open MPI:

OMPI_MCA_ =

Таким чином, -mca switch замінює будь-які раніше встановлені змінні середовища. The -mca
налаштування аналогічним чином замінюють параметри MCA, встановлені в $OPAL_PREFIX/etc/openmpi-mca-
params.conf або файл $HOME/.openmpi/mca-params.conf.

Невідомий Аргументи все ще встановлюються як змінні середовища - вони не перевіряються (за
мпірун) для правильності. Незаконно або неправильно аргументи можуть бути, а можуть і не бути
повідомляється -- це залежить від конкретного модуля MCA.

Щоб знайти доступні типи компонентів в архітектурі MCA або знайти доступні
параметри для конкретного компонента, використовуйте ompi_info команда. Див ompi_info(1) людина
сторінку для детальної інформації про команду.

Робота as корінь
Команда Open MPI настійно не радить виконувати мпірун як користувач root. MPI
програми слід запускати як звичайні користувачі (без root).

Враховуючи цю пораду, mpirun відмовиться запускати як root за замовчуванням. Щоб скасувати це
за замовчуванням, ви можете додати --allow-run-as-root варіант для мпірун command line.

вихід статус
Немає стандартного визначення чого мпірун має повернутися як статус виходу. Після
Під час значного обговорення ми зупинилися на наступному методі присвоєння мпірун вихід
статус (примітка: у наступному описі "основне" завдання є початковою заявкою
розпочато mpirun - усі вакансії, створені цим завданням, позначаються як "вторинні"
вакансія):

· якщо всі процеси основного завдання зазвичай завершуються зі статусом виходу 0, ми повертаємо 0

· якщо один або кілька процесів у головній роботі зазвичай закінчуються ненульовим виходом
status, ми повертаємо статус завершення процесу з найнижчим рангом MPI_COMM_WORLD
мають ненульовий статус

· якщо всі процеси основного завдання зазвичай завершуються зі статусом виходу 0, а один або
більше процесів у вторинній роботі зазвичай завершуються з ненульовим статусом завершення, ми (a)
повернути статус завершення процесу з найнижчим рангом MPI_COMM_WORLD у найнижчому
jobid мати ненульовий статус, і (b) вивести повідомлення, що підсумовує статус завершення
основні та всі другорядні роботи.

· якщо встановлений параметр рядка cmd --report-child-jobs-separately, ми повернемо -only-
статус виходу з основної роботи. Будь-який ненульовий статус виходу на другорядних роботах буде
повідомляється виключно у зведеній друкованій заяві.

За замовчуванням OMPI записує та зазначає, що процеси MPI завершилися з ненульовим завершенням
статус. Це, як правило, не вважається «аномальним припиненням», тобто OMPI не буде
перервати завдання MPI, якщо один або кілька процесів повертають ненульовий статус. Натомість за замовчуванням
поведінка просто повідомляє про кількість процесів, які закінчуються з відмінним від нуля статусом
завершення роботи.

Однак у деяких випадках може бути бажано перервати роботу під час будь-якого процесу
закінчується з ненульовим статусом. Наприклад, завдання без MPI може виявити поганий результат
обчислення і хоче припинити, але не хоче створювати основний файл. Або роботу MPI
може продовжити після виклику MPI_Finalize, але вказує, що всі процеси повинні припинитися
через деякий результат після MPI.

Не очікується, що така ситуація буде відбуватися часто. Проте в інтересах
Обслуговуючи широку спільноту, OMPI тепер має засоби, які дозволяють користувачам керувати цим
завдання припиняються після завершення будь-якого процесу з відмінним від нуля статусом. Встановлення параметра MCA
"orte_abort_on_non_zero_status" до 1 змусить OMPI перервати всі процеси один раз
процес
виходи з ненульовим статусом.

Припинення, викликані таким чином, буде повідомлено на консолі як «ненормальне
завершення", із першим процесом, який завершив роботу, разом із його статусом завершення.

ПРИКЛАДИ

Обов’язково перегляньте приклади у наведених вище розділах.

mpirun -np 4 -mca btl ib,tcp,self prog1
Запустіть 4 копії prog1, використовуючи BTL "ib", "tcp" і "self" для транспортування MPI
повідомлення

mpirun -np 4 -mca btl tcp,sm,self
--mca btl_tcp_if_include eth0 prog1
Запустіть 4 копії prog1, використовуючи BTL "tcp", "sm" і "self" для транспортування MPI
повідомлення, при цьому TCP використовує лише інтерфейс eth0 для спілкування. Зверніть увагу, що інші BTL
мають подібні параметри if_include MCA.

ПОВЕРНЕННЯ VALUE

мпірун повертає 0, якщо всі процеси, запущені з мпірун вийти після виклику MPI_FINALIZE. А
Ненульове значення повертається, якщо в mpirun сталася внутрішня помилка, або одна чи більше
процесів було завершено перед викликом MPI_FINALIZE. Якщо в mpirun сталася внутрішня помилка,
повертається відповідний код помилки. У разі завершення одного або кількох процесів
перед викликом MPI_FINALIZE повертається значення рангу MPI_COMM_WORLD процесу
Що мпірун будуть повернені перші сповіщення, які виникли перед викликом MPI_FINALIZE. Зауважте, що
загалом, це буде перший процес, який загинув, але не гарантовано.

Використовуйте mpiexec.openmpi онлайн за допомогою служб onworks.net