"Мне ANSYS ошибку выдаёт" или мини-гайд по диагностике проблем с MPI

Мотивация и дисклеймер

На днях ковырялся с нашим виндовым кластером, пытаясь возобновить работоспособность флюента через планировщик, и теперь, победив проблему, решил написать немного о наболевшем. Вообще проблемы с работой различных MPI-служб в рамках техподдержки приходится решать довольно часто, и не на все вопросы удаётся найти ответы в интернетах. В свете этих обстоятельств представляю вашему вниманию небольшой гайд по решению различных проблем, связанных с MPI. Отмечу, что всё сказанное ниже относится исключительно к работе ПО ANSYS, главным образом - к CFX и Fluent, т.к. эти продукты лучше всего параллелятся. Более общее толкование упоминаемых терминов легко найти в той же википедии. Здесь также не будут затронуты тонкости параллельной работы различных приложений, т.к. статья замышляется как шпаргалка при устранении неисправностей.

Три часто задаваемых вопроса

1) MPI - что за непонятная, обидная аббревиатура, и для чего это вообще нужно?

MPI = Message Passing Interface (интерфейс передачи сообщений) - это средство общения между различными процессами во время решения задачи. Необходимость в MPI возникает только тогда, когда распараллеливание выполнения задачи происходит между процессами (не путать с распараллеливанием на потоки). В CFX и Fluent возможен только такой вариант, тогда как прочностные и электромагнитные продукты по дефолту параллелятся на потоки в рамках одного процесса, а несколько процессов рождается при активации некоторой "галочки", содержащей в названии слово "distribute" или что-то подобное. При возникновении сомнений способ распараллеливания легко проверить, заглянув в диспетчер задач (в Винде ctrl + shift + esc) и сосчитав процессы:

В данном случае виден один управляющий процесс fl1700 и четыре дочерних процесса fl_mpi1700. По загрузке ЦП можно понять, заняты ли процессы делом или просто занимают/ждут лицензии. Аналогичным образом можно отобразить процессы в Линуксе командой top/atop/htop.

2) Когда нужно устанавливать MPI отдельно с дистрибутива ANSYS?

Только тогда, когда вы собираетесь распараллеливать решение задачи между несколькими машинами по сети. В этом случае MPI должен встать в качестве службы. В противном случае устанавливать MPI не только не нужно, т.к. нужные библиотеки копируются в директорию установки (ANSYS Inc\vXXX\commonfiles\MPI), но и иногда вредно. Подтверждающий пример приведу ниже.

3) Какой MPI выбирать?

Человечеству известны несколько различных реализаций MPI, часть из которых имеет общие корни. Применительно к ANSYS это Platform MPI, Intel MPI, MS MPI (для виндовых кластеров) и Open MPI (Линукс). 

На мой взгляд, выбирать нужно тот вариант, который работает, и только так. Ощутимой разницы в производительности на своей практике я никогда не видел, хотя допускаю опровергающие мою точку зрения частные случаи. По дефолту Fluent, CFX и Mechanical используют pcmpi, и если всё работает, то не надо ничего ковырять.

В определённых случаях на определённых системах может требоваться определённая реализация. Например, для распределённых (на нескольких машинах) вычислений через виндовый планировщик можно использовать только msmpi, на линуксовых кластерах часто по умолчанию настроен Open MPI, поэтому бывает удобнее использовать его. Также переходить на другой MPI бывает необходимо из-за несовместимости с железом - об этом ниже.

Замечание 1. С наименованиями Platform MPI без бутылки не разберёшься, поэтому на всякий случай привожу эволюцию названия в хронологическом порядке: HP MPI > Platform MPI > IBM Platform MPI. То есть это примерно одно и то же, но называться может по-разному. Сокращается обычно как hpmpi или pcmpi.

Замечание 2. Когда нужно противопоставить MS (Microsoft) MPI другим реализациям, может использоваться название Microsoft HPC, более старое CCP или совсем старое CCS (да, в CFX до сих пор не переименовали).

При каких симптомах нужно копать в сторону MPI

1) Сообщение об ошибке содержит упоминание mpi, rank и affinity.

2) Fluent зависает или падает без объяснения причин сразу после запуска.

3) CFX падает или виснет после того, как в логе появляется слово "Solver" в рамочке.

4) Любой другой солвер падает или зависает на первой итерации.

Где взять дополнительную информацию, если стандартный лог решателя не содержит ничего полезного

В первую очередь нужно смотреть стандартные потоки вывода и ошибок (STDOUT и STDERR). Например, при вылете решателя CFX может ничего не написать в .out, при этом полезная для диагностики информация может содержаться в окне консоли, которое запускается вместе с солвером. Если запуск происходит через планировщик, то STDOUT и STDERR обычно перенаправляются в соответствующие файлы в рабочей директории. При ручном запуске через командную строку вывод также можно перенаправить в файл, например: cfx5solve -def myCase.def -par-local -part 4 >> output.txt 2>&1.

Также имеет смысл посмотреть лог ошибок приложений в журнале событий операционной системы.

Каковы основные причины вылета или зависания, и что при этом "крутить"

Когда приложение бездействует или вообще не отвечает, беда, скорее всего, или с фаерволлом, или с учётными данными для выбранной реализации MPI. В Линуксе к списку возможных причин добавляется неправильно настроенный беспарольный доступо по ssh. Фаерволл и ssh могут портить кровь только при расчёте на нескольких машинах, либо в рамках одной машины, но через планировщик. Необходимость ввода учётных данных может проявиться даже при расчёте на локальной машине. Решения здесь очевидные:

1) Чтобы исключить фаерволл - попробовать его временно отключить. Если помогло, то настроить исключения для всех нужных процессов (солвера, mpirun, mpiexec и т.д.). Проще всего посмотреть в логе, что именно он блокировал. На правильном кластере таких проблем возникать не должно, т.к. исключения для mpi-служб настраиваются автоматически системой управления кластером.

2) Чтобы проверить ssh, нужно попробовать залогиниться с каждого узла на каждый из других и убедиться, что при этом не требуется пароль. При большом количестве узлов для такой проверки целесообразно написать скрипт. Возможно, существуют и более удобные готовые инструменты, но я таких не встречал. При выявлении проблем между определёнными узлами нужно повторно сгенерировать ключи, скопировать публичные части и т.д.

3) Для проверки учётных данных удобнее всего запустить тот же флюент с нужной версией MPI в интерактивном режиме и проверить, появится ли окно для ввода пароля. Если появится, то пароль можно просто ввести и сохранить. Если нет, то пароль может быть введён неправильно, и тогда его нужно попробовать обнулить и ввести заново. Это можно сделать очень полезной флюентовской утилитой. Для её вызова нужно открыть Fluent Launcher, в нём - вкладку Environment, далее в поле Other Environment Variables щёлкнуть правой кнопкой и выбрать пункт Start Fluent Diagnostics. Появится вот такое окно, в котором помимо очистки учётных данных для разных реализаций MPI есть ещё множество полезных функций:

Когда приложение вылетает, нужно проверить следующие моменты:

1) Переменные окружения, связанные со службами MPI, а также переменную Path на всех узлах. Приведу два примера из своей практики.

Пример номер раз. Пользователь на локальной машине последовательно установил версии ANSYS с 14й по 16ю, каждый раз устанавливая Platform MPI в качестве отдельной службы:

В результате не работают более старые версии CFX. Почему так происходит? Из-за несовместимости версий CFX и Platform MPI. Несовместимость в результате установки MPI как службы возникает из-за появления переменной MPI_ROOT, которая указывает на последнюю установленную версию службы. А эта версия MPI, например, используется CFX'ом начиная только с 16й версии. Решение - удалить переменную. Если нужно обеспечить работоспособность нескольких очень старых и очень новых версий CFX на одном кластере, то можно перед запуском CFX в рамках сессии перезаписать в переменную нужный путь.

Пример номер два - случай с нашим виндовым кластером. Запускаем флюент через планировщик, и после появления Job'а всё висит, при этом в stderr пишется несколько десятков Мб текса в секунду. Убиваем Job, потом убиваем gui и хост-процесс флюента (cx1700 и fl1700). Причём быстро, пока лог не разросся до нечитаемых размеров. Смотрим в лог, видим повторяющийся тысячи раз текст:

User credentials needed to launch processes:
account (domain\user) [HPC\vdk]: password: 
Unable to manage jobs using credentials with a blank password.
Please enter another account.

То есть нам намекают на отсутствие сохранённого пароля для mpiexec (основной исполняемый файл MS MPI, аналог у Platform - mpirun). Чешем голову, запускаем разные тесты MPI, пробуем CFX - всё работает. Чистим учётные данные через Cluster Manager или командой cluscfg delcreds, вводим заново - не помогает. Чешем голову сильнее. Идём на узлы, пробуем запустить что-нибудь локально (например,  mpiexec notepad). И на узлах с нас спрашивают пароль! Так быть не должно, поскольку голова хранит наш пароль, и эта информация передаётся вычислительным узлам. Пробуем сохранить пароль на узлах, запускаем Fluent. Новая ошибка:

Fatal protocol error: check version between Mpiexec.exe, Msmpi.dll, and Smpd.exe.

Чешем всё остальное. Начинаем думать, тот ли это mpiexec, который нам нужен? Запускаем clusrun where mpiexec, чтобы понять, откуда он запускается. Видим, что на голове выдаётся правильная директория (...Program Files\Microsoft HPC Pack 2012\...), а на узлах перед ней идёт директория Intel MPI, т.е. сначала mpiexec ищется именно там. Оказывается, некий злоумышленник установил на узлах IntelMPI, у которого исполняемый файл имеет то же название, а путь к нему записался в начало переменной Path. Лечение простое - перемещаем интеловские пути в конец переменной, или вообще удаляем, если злоумышленник разрешает. В результате всё работает.

Данные примеры иллюстрируют, как важно проявлять внимательность при установке различных MPI-служб и проверять, какие переменные они создают.

2) Работоспособность сети и MPI службы именно по этой сети при помощи простых тестов. Особенно это касается сети Infiniband, которая довольно капризна по отношению к драйверам и прошивкам сетевых карт. У меня были случаи, когда из-за отличия версии прошивки только на одной карте не работала вся сеть кластера, пока этот узел активен. По той же причине сеть может работать, но не включится протокол прямого доступа к памяти (RDMA или его виндовая реализация NetworkDirect), в результате чего латентность вырастет на пару порядков, а пропускная способность упадёт примерно на порядок. Под той же виндой версию прошивки можно проверить командой clusrun ibstat | findstr Firmware. Также для диагностики сети Infiniband могут быть полезны команды ibnetdiscover и ibping. Последняя аналогична обычному пингу, но требует, чтобы на пингуемой машине была поднята серверная часть (ibping -S).

3) Совместимость с железом, особенно если в сообщении об ошибке содержится слово affinity. Русскоязычного аналога понятия affinity я не знаю, но оно имеет непосредственное отношение к технологии неравномерного доступа к памяти (NUMA). С практической точки зрения данная технология позволяет привязывать процессы к ядрам и обеспечивает им доступ к наиболее близкорасположенной (физически) памяти. Использование данной технологии может управляться MPI (флаг -affinity), как в CFX, или на уровне кода, как во Fluent. В принципе использование affinity должно ускорять параллельные вычисления (хотя для механики не рекомендуется), но иногда функция работает криво. Это происходит потому, что BIOS выдаёт операционной системе неправильный SRAT (таблица распределение ресурсов), в результате MPI присваивает процессам неправильные ранги, и всё падает. Также в качестве симптома может наблюдаться неправильное определение количества физических ядер системой. Данная проблема наблюдается в современных серверных процах Intel Xeon начиная с 3-го поколения (лично встречал на железе HP и ASUS). 

Чтобы подтвердить данную причину, нужно зайти в BIOS и отключить NUMA или включить Node Interleaving (= отключить NUMA). В свежих прошивках от HP есть вариант не отключать NUMA, а установить параметр NUMA Group Size Optimization = flat. Наиболее правильное решение - накатить свежую прошивку BIOS. Также иногда помогает переход с Platform MPI на Intel MPI или использование локальной установки вместо сетевой.

На этом пока всё. Если материал окажется востребованным, буду его понемногу расширять. Также отмечу, что здесь я описал в основном собственный опыт, который слегка дополняет информацию на портале пользователей и зарубежных форумах. Настоятельно рекомендую при диагностике неисправностей в первую очередь обращаться к Customer Portal'у.

PS Если ошибки, связанные с MPI, возникают в процессе счёта, то проблема может заключаться в банальном делении на ноль при развале решения. Особенно это характерно для флюента, который после floating point exception может растерять связь со своими процессами. В подобных случаях его нужно просто перезапустить и устранить проблему сходимости итераций. До версии 16.1 были известны проблемы с динамической адаптацией, которые также валили MPI, но теперь это исправлено.

PPS Иногда похожие симптомы проявляются при ошибке доступа к серверу лицензий, причём в логе может ничего не отразиться, и если переменная ANSWAIT=1 не задана, то приложение просто закроется. Чтобы исключить этот вариант, нужно убедиться, что сервер лицензий виден всем узлам, т.к. хост-процесс, запрашивающий лицензию, может родиться на любом из них.