Ошибка сервиса mpi мпс

Статья была опубликована ровно 3 года назад, еле сам её нашел для дополнения.

Если при оплате картой вы сталкиваетесь с какой-то ошибкой, отказом терминала («деклайн»), то код ответа даст понимание, почему это случилось. Ниже расшифровки ответов платежных систем:

Код 00 – успешно проведенная операция.
Код 01 – отказать, позвонить в банк-эмитент
Код 02 – отказать, позвонить в банк-эмитент (особое условие)
Код 03 Invalid merchant (Неверный мерчант ID), незарегистрированная торговая точка или агрегатор платежей
Код 04 — изъять карту без указания причины. Блок карты в связи с мошенничеством. Pick-up card.
Код 05 – Do not Honour. (Транзакция была отклонена банком без указания причин.

06 Error. Неизвестная ошибка на стороне банка, повторить
07 Pick-up card, special condition. Карта заблокирована банком в связи с мошенничеством
08 — обслуживать с идентификацией по документу и подписи либо отменить всю операцию
12 Invalid transaction card / issuer / acquirer Мерчант не принимает карты этого банка.
13 Invalid amount Сумма превысила лимит банка на транзакцию, возможно, ошибка ввода суммы
14 Invalid card number — Неверный номер карты либо карта заблокирована холдером/банком
17 – отказать, отклонено пользователем карты.
19 System Error  — Системная ошибка на стороне мерчанта/банка, нужно повторить транзакцию
21 No Action Taken Запрещено банком без каких либо объяснений
31 эмитент не найден в платёжной системе
32 частично завершено
34 Suspected Fraud Подозрении в мошенничестве
39 No Credit Account Отсутствует кредитный счет карты
41 Lost Card, Pickup; Карта утеряна, изьять
42 Special Pickup; Карта украдена, изьять
43 Hot Card, Pickup; Карта украдена, изьять
51 Not sufficient funds; Недостаточно средств для оплаты
54 Expired card; Срок карты истек
55 Incorrect PIN; Неверный пин
57 Transaction not permitted on card; Мерчант не принимает карты этого банка или недопустимый тип операции для данного вида карты (например, по карте можно только снять нал, без оплаты покупок)
58 Txn Not Permitted On Term; Мерчант не принимает этот вид операции, см. 57
59 Suspected Fraud; подозрение в мошенничестве.
61 Exceeds amount limit; сумма превышает разрешенный суточный максимум для карты
62 Restricted card; картсчет заморожен, блок карты
63 Security violation; картсчет заморожен, блок карты
64 — сумма отмены авторизации отлична от суммы оригинальной авторизации
65 — отказать, превышение максимального количества операции для данной карты //лимит  расходных операций по счету
67 — карта изъята в банкомате
75 Exceeds PIN Retry; пин введен максимальное количество раз
78 Function Not Available; номер карты не действителен или не существует
80 Ошибка сети
81 Ошибка в шифре PIN (МС)
82 CVV Validation Error; неверный cvv код)
83 – отказать, ошибка сети (технические проблемы)
86 невозможно проверить pin
88 ошибка шифрования Pin
91 Issuer not available; связь с банком отсутствует, тех.проблемы
93 Transaction violates law; транзакция незаконна
94 Duplicate Transaction; двойная транзакция.
96 System Error; системная ошибка на стороне мерчанта/не связаться с банком-эмитентом

100 (используется Visa, аналог кода 119 для MasterCard) — Нет разрешения. Неверный способ шифрования данных. (пример: банк-эмитент блокирует операции по магнитной полосе для Чипованной карты).
101 — Карта просрочена (примеры: истек срок действия карты или карта была перевыпущена)
117 — Неверный ПИН-код

119 для MC (см. код 100 выше): Unable to Encrypt Message — SecurePay’s security methods were unable to encrypt the message

Код 182 — отказ банка-эмитента. Возможно, на карте установлены ограничения по расчетам в интернете.

Код Z1 — техническая ошибка терминала; если нет приоритета PIN, то карта не обслуживается.
Код Z3 — онлайн не работает, а в оффлайне терминал отклонил транзакцию.
Q1 — аутентификация карты не прошла
NX — внутренняя ошибка терминала, например, отсутствие маршрута сети или сброс IP-адреса

ОБ — не обслуживать

Pos-errors (pdf)

Result Code
Description
Как решить проблему
Куда обратиться

76

51

076

9859

116

603

Insufficient funds

Not sufficient funds

Decline, not sufficient funds

Decline, not sufficient funds
На балансе карты недостаточно средств
Если на карте баланс больше или равен сумме транзакции, а отказ все равно происходит по причине недостатка средств, тогда возможны такие причины:
— банк-эмитент удерживает дополнительные комиссии с держателя карты. Это может возникать в случаях погашение кредита посредством интернет-платежа, либо если договор на обслуживание банковской карты предусматривает дополнительные комиссии;
— происходит конвертация из валюты покупки в валюту карты. Убедитесь, что средств на карте достаточно для покрытия комиссии за конвертацию валют. Некоторые банки-эмитенты устанавливают комиссии на конвертацию валют как-правило в пределах 1%
Банк-эмитент (банк, выпустивший карту)

50

5

9905

180

Transaction declined

Do not honor

Do not Honour

Transaction declined

Do not honor
Не обслуживать
Пожалуй, самый общий и не определенный код отказа. Он может указывать на любые ограничения, наложенные банком-эмитентом, которые банк пожелал оставить не уточненными.
Возможные причины:
— карта заблокирована или на ней установлен статус
— на карте не установлен лимит на оплату в интернет, либо этот лимит недостаточный
— сработали настройки системы безопасности банка-эмитента
— сработали ограничения по сумме или количеству операций по карте у банка-эмитента
— банк-эмитент установил ограничения на проведение данного типа транзакций
— по карте не разрешены международные платежи (доместиковая карта)
— банк-эмитент установил ограничение на транзакции с двойной конвертацией валют (DCC)
— банк-эмитент установил ограничения на транзакции в данной валюте
— банк-эмитент установил ограничения на транзакции в данной стране
— банк-эмитент в США ограничил по карте операции в валюте, отличной от USD
— банк-эмитент в США ограничил по карте операции в странах бывшего СНГ и других рисковых регионах
Банк-эмитент (банк, выпустивший карту). Если банк-эмитент не видит данную транзакцию, тогда необходимо обратиться в банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

55

055

12

902

9882

9912

Invalid transaction

Invalid transaction card / issuer / acquirer

Decline reason message: invalid transaction

Invalid transaction
Операция для данной карты или мерчанта не разрешена
Причины могут быть теми же, что и для Do not honor
Банк-эмитент (банк, выпустивший карту). Если банк-эмитент не видит данную транзакцию, тогда необходимо обратиться в банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

95

095

61

061

121

9861

9863

Decline, exceeds withdrawal amount limit

Exceeds amount limit

Exceeds withdrawal limit

Withdrawal limit would be exceeded

Withdrawal limit already reached

Card exceeds withdrawal amount limit
На карте достигнут лимит по сумме операций в сутки, в месяц или на разовую транзакцию
Возможные причины (более детально смотрите по банку-эквайеру выше):
— на карте не установлен лимит операций в интернет или он уже достигнут или будет достигнут с текущей транзакцией
— общий лимит по сумме для операций покупок по карте уже достигнут или будет достигнут с текущей транзакцией
— карта не открыта для расчетов в интернет
— на карте не активирован сервис 3D-Secure из-за чего операции в интернет без 3D-Secure пароля попадают под ограничения банка-эмитента
Банк-эмитент (банк, выпустивший карту)

65

065

82

082

9860

Activity count exceeded

Exceeds frequency limit

Maximum number of times used

Card exceeds withdrawal frequency limit
На карте достигнут лимит по количеству операций в сутки или в месяц
Возможные причины (более детально смотрите по банку-эквайеру выше):
— на карте не установлен лимит операций в интернет или он уже достигнут или будет достигнут с текущей транзакцией
— общий лимит по количеству операций покупок по карте уже достигнут или будет достигнут с текущей транзакцией
— карта не открыта для расчетов в интернет
— на карте не активирован сервис 3D-Secure из-за чего операции в интернет без 3D-Secure пароля попадают под ограничения банка-эмитента
Банк-эмитент (банк, выпустивший карту)

57

119

Not permitted to client

Transaction not permitted on card

Transaction not permitted to card

Decline, transaction not permitted to cardholder

Transaction not permitted to card

Not permitted to client

Decline, transaction not permitted to cardholder

Function Not Permitted To Cardholder

Not permitted to client
Транзакция не разрешена для карты или клиента

Банк эмитент отклонил транзакцию так как она не может быть осуществлена для этой карты или клиента.

Возможные причины (более детально смотрите по банку-эквайеру выше):
— данный карточный продукт не рассчитан для такого типа операции
— для данной карты не настроен такой тип операции на стороне банка-эмитента

Банк-эмитент (банк, выпустивший карту)

58

120

Decline, transaction not permitted to terminal

Not permitted to merchant

The requested service is not permitted for terminal

Function Not Permitted To Terminal

Txn Not Permitted On Term

Not permitted to merchant
Транзакция не разрешена для терминала или мерчанта
Мерчант или терминал настроен некорректно, или данный тип операции не разрешен на стороне банка-эквайера или платежного провайдера. В первую очередь нужно уточнить конфигурацию торговой точки у платежного провайдера и список допустимых операций
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

211

N7

9881

Bad CVV2

Decline for CVV2 Failure

CVV2 is invalid

Invalid CVV2

Decline Cvv2 failure

Invalid CVV2 code
Введен неверный CVV2 код во время проведения платежа
Необходимо проверить CVV2 код на оборотной стороне карты. Код состоит из 3 цифр для Visa/MasterCard/Discover и из 4 цифр для карт American Express.
CVV2 код также может называться CVC2, CID, CSC2 код.
В некоторых случаях такой код отказа может возвращаться и при вводе неверного срока действия карты.
Стоит обратить внимание, если банк эмитент использует динамический код CVV2, генерируемый на короткий промежуток времени в клиент-банке — срок жизни такого CVV2 кода мог истечь на момент совершения операции
Банк-эмитент (банк, выпустивший карту)

058

59

059

62

062

9858

104

Restricted card

Restricted status

Decline, restricted card

Card is restricted

Your card is restricted

Restricted Card
Операции по карте ограничены
Возможные причины:
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи
— для карты не доступны интернет-платежи
Банк-эмитент (банк, выпустивший карту)

56

056

Transaction not supported by institution
Your card is not supported. Please use card of other payment system
Данный тип платежной системы не поддерживается
Банк-эквайер или платежный провайдер не поддерживает платежную систему данной карты.
Отказ может возникать в таких случаях:
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— оплата картой Monobank в счет микро-кредитной организации (погашение кредита), либо выдача кредит. Монобанк блокирует операции в адрес МФО по некоторым типам карт
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру
Монобанк, если карта этого банка

100

1000

Decline (general, no comments)

General decline, no comments

General decline

General decline
Общий отказ.
Причины могут быть теми же, что и для Do not honor
Банк-эмитент (банк, выпустивший карту)

54

101

Expired card

Decline, expired card

Expired card

Pick-up, expired card

Card expired

Invalid card expiry date
Истек срок действия карты
Возможные причины
— срок действия карты закончился
— указан неверный срок действия карты
— карта была перевыпущена с новым сроком
Банк-эмитент (банк, выпустивший карту)

14

111

9852

1012

305113

Card number does not exist

Invalid card number

No such card

Decline, card not effective

Invalid card

Wrong card number

Invalid card number
Неверный номер карты
Возможные причины:
— неверный номер карты
— карта не действительна
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи
Банк-эмитент (банк, выпустивший карту)

909

42

7

07

108

9875

207

42

External Decline Special Condition

Special Pickup

Pick up card (special)

Pick up card, special condition (fraud account)

Pick-up, special conditions

Decline, refer to card issuer’s special conditions

Pick up card, special condition (fraud account)
Специальный отказ банка-эмитента. Владелец карты подозревается в мошенничестве.
Банк-эмитент подозревает держателя карты в мошенничестве, либо система безопасности (антифрод-система) банка эмитента отклонила транзакцию
Банк-эмитент (банк, выпустивший карту)

122

63

89

Decline, security violation

Security violation

Security violation
Отказ по соображениям безопасности
Код отказа может отдаваться как банком-эмитентом, так и банком-эквайером. Возможные причины:
— карточный счет заморожен или заблокирован
— ограничения правил безопасности (система Antifraud на стороне любого из участников)
Банк-эмитент (банк, выпустивший карту)
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

200

76

114

21

Invalid account

Decline, no account of type requested

No To Account

Invalid card number
Неверный номер карты или счета
Возможные причины:
— счет карты закрыт или заблокирован
— по счету запрещены расходные операции
— карта не действительна
— неверный номер карты
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи
— карта не предназначена для расчетов в интернет
Банк-эмитент (банк, выпустивший карту)

74

074

907

911

910

9872

91

291

82

908

810

Unable to authorize

Decline reason message: card issuer or switch inoperative

Destination not available

Issuer or switch inoperative

Issuer unavailable

Time-out at issuer

Decline reason message: card issuer timed out

Decline reason message: transaction destination cannot be found for routing

Transaction timeout

Acquiring bank request timeout

Ошибка связи: таймаут

Недоступен эмитент/эквайер

Таймаут при попытке связи с банком-эмитентом. Как правило такая ошибка возникает при проблемах технического характера на стороне любого из участников: банка-эквайера, банка эмитента, платежной системы Visa/MasterCard/МИР.

В первую очередь необходимо обратиться в банк-эквайер для выяснения причины и определения, на чьей стороне неисправности.

Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

Банк-эмитент (при получении 91 кода)

15

815

92

No such card/issuer

No such issuer

Invalid Issuer

Invalid card number
Указан неверный номер карты
см. Неверный номер карты

811

96

0

System error
Unknown payment system error
Технический сбой на стороне эквайера/платежной системы
Технический сбой на стороне банка-эквайера
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

4

04

44

43

200

104

Pick-up (general, no comments)

Pick up card

Your card is restricted

Hot Card, Pickup (if possible)

Hold — Pick up card

Pick-up, restricted card

Pick-up, card acceptor contact card acquirer

Pick up card (no fraud)
Изъять карту
Банк-эмитент отклонил транзакцию с сообщением о необходимости изъять карту, если это возможно. Как правило причиной является блокировка карты по причине утери
Банк-эмитент (банк, выпустивший карту)

52
Number of PIN tries exceeded
PIN tries exceeded
Превышен лимит попыток ввода PIN-кода
На карте установлен статус в связи с превышением попыток ввода PIN-кода при оплате в наземных POS-терминалах или использования карты в банкомате.
Также причиной может быть то, что карта только что выпущена и первой операцией для нее должна быть операция смены PIN-кода
Банк-эмитент (банк, выпустивший карту)

205

110

13

567

9913

9867

Invalid advance amount

Decline, invalid amount

Invalid amount

Invalid amount
Неверная сумма
Причины отказа:
— слишком маленькая сумма. Если карта открыта в валюте, убедитесь, что сумма транзакции не менее 1 цента доллара США или 1 Евро цента
— слишком большая сумма
— из суммы транзакции невозможно удержать сумму комиссии платежного провайдера. Убедитесь, что сумма транзакции не меньше суммы всех комиссий
— ограничения на карте плательщика на стороне банка, который выпуcтил карту.
— достигнуты лимиты на стороне банка-эквайера.
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру, Банк-эмитент (банк, выпустивший карту)

948

102

202

9934

59

Suspected fraud

Decline, suspected fraud

Suspected fraud
Подозрение в мошенничестве
Система безопасности одного из участников процессинговой цепочки подозревает участие карты в мошеннических действиях или в компрометации.
Также, возможно, что банк-эмитент заблокировал карту/счет в связи с подозрительными действиями, скиммингом, компрометацией
Банк-эмитент (банк, выпустивший карту)

800

904

30

030

9874

574

Format error

Decline reason message: format error

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

41

540

208

9840

Lost Card, Pickup

Pick up card (lost card)

Lost card

Lost card, pick-up

Pick-up, lost card

Lost card
Карта утеряна
На карте установлен статус утеряна по заявлению картодержателя.
Банк-эмитент (банк, выпустивший карту)

93

124

Violation of law

Decline, violation of law

Suspected fraud
Транзакция не может быть выполнена: нарушение закона
Банк-эмитент отказал в осуществлении транзакции во избежание нарушения закона
Банк-эмитент (банк, выпустивший карту)

909

96

Decline reason message: system malfunction

System malfunction

System malfunction
Технический сбой на стороне эквайера/платежной системы
Технический сбой на стороне банка-эквайера
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

01

02

107

108

Refer to card issuer

Decline, refer to card issuer

Decline, refer to card issuer special conditions

Refer to issuer

Decline, refer to card issuer
Обратиться к банку-эмитенту
Отказ банка-эмитента. Держатель карты должен обратиться в свой банк
Банк-эмитент (банк, выпустивший карту)

201
Incorrect PIN
Incorrect PIN
Неверный PIN
На карте установлен статус в связи с превышением попыток ввода PIN-кода при оплате в наземных POS-терминалах или использования карты в банкомате.
Также причиной может быть то, что карта только что выпущена и первой операцией для нее должна быть операция смены PIN-кода
Банк-эмитент (банк, выпустивший карту)

210
Bad CAVV
Do not honor
Неверный CAVV
Ошибка возникает при проверке 3DSecure на стороне банка-эмитента. Причиной может случить либо неверная настройка 3DSecure на карте, либо некорректная реализация Apple/Google Pay токенов на стороне платежной платформы, мерчанта или банка-эквайера
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

43

209

057

9841

Pick up card (stolen card)

Pick-up, stolen card

Stolen card

Stolen card, pick-up

Lost/Stolen

Lost or stolen card

Stolen card
Карта украдена
Банк-эмитент установил на карте статус «украдена» по обращению держателя карты
Банк-эмитент (банк, выпустивший карту)

6000

106

Pre-authorizations are not allowed within this context.

Merchant is not allowed preauth

Preauth not allowed
Операция предавторизации на разрешена для торговца
Необходимо обратиться к платежному провайдеру или банку-эквайеру для активации двухстадийной оплаты перед пред-авторизацию/завершение (preauth/capture или prepurchase/completion или authorization/sale)
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

03

3

109

9903

20003

Invalid merchant

Decline, invalid merchant

Merchant is not configured correctly
Мерчант настроен некорректно
Необходимо обратиться к платежному провайдеру или банку-эквайеру для настройки или активации мерчанта или мерчант-аккаунта.
Также причиной может быть некорректно переданный идентификатор мерчанта в транзакции
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

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

На днях ковырялся с нашим виндовым кластером, пытаясь возобновить работоспособность флюента через планировщик, и теперь, победив проблему, решил написать немного о наболевшем. Вообще проблемы с работой различных 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 IncvXXXcommonfilesMPI), но и иногда вредно. Подтверждающий пример приведу ниже.

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 (domainuser) [HPCvdk]: 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 FilesMicrosoft 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 не задана, то приложение просто закроется. Чтобы исключить этот вариант, нужно убедиться, что сервер лицензий виден всем узлам, т.к. хост-процесс, запрашивающий лицензию, может родиться на любом из них.

Произошла ошибка в MPI_Send на коммуникаторе MPI_COMM_WORLD MPI_ERR_RANK: неверный ранг

Я пытаюсь выучить MPI. Когда я отправляю данные с одного процессора на другой, я успешно могу отправлять данные и получать их в другом в переменной. Но, когда я пытаюсь отправить и получить на обоих процессорах, я получаю ошибку неверного ранга.

Вот мой код для программы

#include #include #include int main(int argc, char **argv) < int world_size; int rank; char hostname[256]; char processor_name[MPI_MAX_PROCESSOR_NAME]; int name_len; int tag = 4; int value = 4; int master = 0; int rec; MPI_Status status; // Initialize the MPI environment MPI_Init(argv); // get the total number of processes MPI_Comm_size(MPI_COMM_WORLD, // get the rank of current process MPI_Comm_rank(MPI_COMM_WORLD, // get the name of the processor MPI_Get_processor_name(processor_name, // get the hostname gethostname(hostname,255); printf(«World size is %dn»,world_size); if(rank == master)< MPI_Send( MPI_Recv(status); printf(«In master with value %dn»,rec); >if(rank == 1) < MPI_Send( MPI_Recv(status); printf(«in slave with rank %d and value %dn»,rank, rec); >printf(«Hello world! I am process number: %d from processor %s on host %s out of %d processorsn», rank, processor_name, hostname, world_size); MPI_Finalize(); return 0; >

Вот мой файл PBS:

Выходной файл выглядит так:

World size is 1 World size is 1 World size is 1 World size is 1 World size is 1 World size is 1 World size is 1 World size is 1 =================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 6 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES =================================================================================== Job complete

Если размер мира равен 1, размер мира должен быть напечатан один раз, а не 8 раз.

[compute-0-34.local:13110] *** An error occurred in MPI_Send [compute-0-34.local:13110] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13110] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13110] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13107] *** An error occurred in MPI_Send [compute-0-34.local:13107] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13107] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13107] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13112] *** An error occurred in MPI_Send [compute-0-34.local:13112] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13112] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13112] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13108] *** An error occurred in MPI_Send [compute-0-34.local:13108] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13108] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13108] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13109] *** An error occurred in MPI_Send [compute-0-34.local:13109] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13109] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13109] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13113] *** An error occurred in MPI_Send [compute-0-34.local:13113] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13113] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13113] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13106] *** An error occurred in MPI_Send [compute-0-34.local:13106] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13106] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13106] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort [compute-0-34.local:13111] *** An error occurred in MPI_Send [compute-0-34.local:13111] *** on communicator MPI_COMM_WORLD [compute-0-34.local:13111] *** MPI_ERR_RANK: invalid rank [compute-0-34.local:13111] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort

2 дня назад я смог отправить и получить одновременно, но после этого рабочий код показывает мне эту ошибку. Есть ли какие-либо проблемы в моем коде или на компьютере высокой производительности, на котором я работаю?

Решение

С точки зрения MPI, вы запустили не одно задание MPI с 8 заданиями MPI, а 8 независимых заданий MPI с одним заданием MPI каждое.

Обычно это происходит, когда вы смешиваете две реализации MPI (например, ваше приложение было построено с использованием Open MPI, и вы используете MPICH mpirun).

До вызова mpirun Я предлагаю вам добавить в свой скрипт PBS

which mpirun ldd mpitest

Удостовериться mpirun и библиотеки MPI из одной и той же библиотеки (например, одного и того же поставщика) а также та же версия)

Другие решения

Была проблема с HPC, и он не выделял мне необходимое количество процессоров. Спасибо, парни.

Источник: web-answers.ru

Ошибка при вызове MPI_Send

Fatal error in MPI_Send: A process has failed, error stack:
MPI_Send(171). MPI_Send(buf=0x7ffff5a90a4e, count=1, MPI_CHAR, dest=0, tag=1, MPI_COMM_WORLD) failed
MPID_nem_tcp_connpoll(1833): Communication error with rank 0: Connection refused

Доступ по SSH без пароля есть с обоих узлов в обе стороны.

ОС: Ubuntu Server 14.04
Версия MPICH: 3.1, собрал из исходников

В чем может быть проблема?

Добавлено через 9 часов 25 минут
Решил проблему. Оказывается MPI_Recv(status); не блокировал программу ожидая получения сообщения, а возвращал ошибку, поэтому MPI_Send передавал уже несуществующему процессу. Правильным вариантом будет указать в функции не MPI_ANY_SOURCE, а номер узла напрямую, т.е. в данном случае 1: MPI_Recv(status);

Однако можно обойтись и с MPI_ANY_SOURCE таким образом:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
if(rank == 0) { int i = 0; while(i != (numtasks — 1)) { char ch; if(MPI_Recv(status) == MPI_SUCCESS) { printf(«message: %cn», ch); i++; } } } else { char mess = ‘!’; MPI_Send( }

Т.е. в данном коде у нас вечный цикл, пока не получим все сообщения от всех узлов.

Я не нашел никаких объяснений такому поведению в официальной документации. Я только начинаю знакомиться с MPICH и везде пишут, что MPI_Recv блокирующий вызов.

Источник: www.cyberforum.ru

Ошибка EPC на приборной панели: что это такое?

Что означает значок ЕРС на приборной панели автомобиля.

На панели приборов автомобиля могут отображаться различные типы сообщений о неправильной работе одного из компонентов или сбоях автомобиля. Одним из них является индикатор EPC – Electronic Power Control. Но в каких случаях на приборной панели может выскочить ошибка EPC?

Electronic Power Control (EPC) – это компьютеризированная система зажигания и управления двигателем, которая используется в автомобилях VAG (более известная как Volkswagen Group).

Многие автовладельцы, увидев на панели приборов индикатор, путают его с ошибкой системы ABS или ESP, последняя из которых отвечает за систему стабилизации автомобиля на дороге (система контроля устойчивости автомобиля). ABS и ESP относятся к противоскользящим системам, защищающим транспортное средство от потери сцепления во время движения и торможения. Что касаемо сигнальной лампы ЕРС, для многих эта аббревиатура на приборке остается загадкой. На самом деле это горящее предупреждение ЕРС говорит о проблемах в автомобиле, связанных со сбоями в электропитании.

К сожалению, ошибка ЕРС может означать почти все, в том числе значительные неисправности, начиная от неправильных значений, поступаемых с датчиков двигателя, и заканчивая отказом стоп-сигнала или ошибкой датчика температуры охлаждающей жидкости. Как правило, чтобы определить причину сбоя, необходимо использовать диагностический компьютер или специальное диагностирующее приложение, установленное на смартфон, который должен быть соединен с диагностическим разъемом автомобиля.

Примечательно, что индикатор EPC встречается в основном на автомобилях Volkswagen или автомобилях, выпускаемых VW Group, – например, сигнальный значок ЕРС есть в автомобилях Seat, Audi и Porsche. Кстати, именно в этих автомобилях индикация ЕРС полностью независима от индикатора «Чек двигателя» (Check Engine). Что это означает?

Например, неработающие стоп-сигналы в автомобилях Volkswagen не приводят к появлению индикации «Чек двигателя» – вместо этого на приборной панели появится значок ЕРС, поскольку лампы в стоп-сигналах не связаны с системой управления двигателем. И это правильно, так как лампочки не влияют на работу двигателя. Увы, такая отдельная индикация в автомобилях Volkswagen есть не во всех автомобилях. Во многих авто индикатор ЕСР может означать как мелкую проблему с лампочкой, так и проблему с датчиками двигателя.

Безопасно ли ехать с включенной ошибкой EPC?

Все зависит от того, какие еще ошибки есть на приборной панели. Если на приборке вместе с сигнальной лампой EPC горит индикатор «Чек двигателя» (Check Engine), автомобиль должен быть проверен как можно скорее, чтобы предотвратить существенное повреждение двигателя. Внимание: не стоит паниковать при появлении ошибки «Чек двигателя» – как правило, в этом случае двигатель управляется в аварийном режиме (система ограничивает положение дроссельной заслонки, не допуская движение на больших оборотах). Обычно при аварийном режиме вы будете чувствовать, что в автомобиле пропала мощность.

Поскольку система EPC используется во многих других системах автомобиля VW Group, вполне вероятно, что после появления ошибки ЕРС на приборке могут появиться и другие сигнальные огни, предупреждающие о неисправностях. Например, если по каким-то причинам будет неисправна система контроля устойчивости автомобиля (ESP) или выйдет из строя круиз-контроль, то на приборке появится значок ESP или значок, предупреждающий о нерабочей системе круиза.

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

Источник: 1gai.ru

Неисправность системы TPMS

Спустя тфи недели после переобувши выскочила ошибка TPMS. Раньше тоже такое бывало пару раз, но после глушения двигателя исчезало. А тут уже неделю катаемся и постоянно выскакивает.
Почитал что могли местами колеса переставить в шиномонтаже, и надо заново прописать датчики.
Окей, начал прописывать с помощью NMPS Diag. Три колеса уже в красной зоне, а заднее правое ни на грамм не спускается, судя по программе. Стало быть — датчик сдох(
Какие есть пути решения, может по гарантии заменят или с али заказать пару штук прозапас, или может нафиг отключить эту ерунду?

21 апреля 2021 Метки: поломка

Источник: www.drive2.ru

Реализация MPI может обрабатывать или не обрабатывать некоторые ошибки, которые возникают при выполнении вызовов MPI . Это могут быть ошибки, которые генерируют исключения или прерывания, например, ошибки для операций с плавающей точкой или при нарушении доступа. Набор ошибок, которые корректно обрабатываются MPI , зависит от реализации. Каждая такая ошибка генерирует исключение MPI .

Вышеупомянутый текст имеет приоритет над любым текстом по обработке ошибок внутри этого документа. Текст, в котором говорится, что ошибки будут обработаны, должен содержать информацию о том, как они могут быть обработаны.

Пользователь может связывать обработчик ошибок с коммуникатором. Эта процедура будет использоваться для любого исключения MPI , которое имеет место в течение вызова MPI для обмена с использованием этого коммуникатора. Вызовы MPI , которые не связаны ни с одним коммуникатором, рассматриваются, как относящиеся к коммуникатору MPI_COMM_WORLD .

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

Вновь созданный коммуникатор наследует обработчик ошибок, который связан с «родительским» коммуникатором. В частности, пользователь может определить «глобальный» обработчик ошибок для всех коммуникаторов, связывая этот обработчик с коммуникатором MPI_COMM_WORLD сразу после инициализации.

В MPI доступны несколько предопределенных обработчиков ошибок :

MPI_ERRORS_ARE_FATAL — обработчик, который после вызова прерывает работу программы на всех процессах. Это имеет тот же эффект, как если бы процессом, который запустил обработчик, был вызван MPI_ABORT .

Реализации могут обеспечивать дополнительные обработчики ошибок, программисты также могут написать свои собственные обработчики ошибок.

Обработчик ошибок MPI_ERRORS_ARE_FATAL связан по умолчанию с MPI_COMM_WORLD после его инициализации. Таким образом, если пользователь не желает управлять обработкой ошибок самостоятельно, то каждая ошибка в MPI обрабатывается как фатальная. Так как все вызовы MPI возвращают код ошибки, пользователь может работать с ошибками в головной программе, используя возвращенные вызовами MPI коды и выполняя подходящую программу восстановления в том случае, когда вызов не был успешным. В этом случае будет использоваться обработчик ошибок MPI_ERRORS_RETURN . Обычно более удобно и более эффективно не проверять ошибки после каждого вызова, а иметь специализированный обработчик ошибок.

После того, как ошибка обнаружена, состояние MPI является неопределенным. Это означает, что даже если используется определенный пользователем обработчик ошибок или
MPI_ERRORS_RETURN , не обязательно , что пользователю будет разрешено продолжить использовать MPI после того, как ошибка определена. Цель таких обработчиков состоит в том, чтобы пользователь получил определенное им сообщение об ошибке и предпринял действия, не относящиеся к MPI (такие, как очистки буферов ввода/вывода) перед выходом из программы. Реализация MPI допускает продолжение работы приложения после возникновения ошибки, но не требует, чтобы так было всегда.

Совет разработчикам: Хорошие реализации MPI должны максимально ограничивать воздействие ошибки, чтобы нормальное функционирование могло продолжаться после того, как обработчик ошибок был запущен. В документации должна содержаться информация относительно возможного эффекта по каждому классу ошибок.[]

Обработчик ошибок MPI является скрытым объектом, связанным с дескриптором. Процедуры MPI обеспечивают создание новых обработчиков ошибок, связывают обработчики ошибок с коммуникаторами и проверяют, какой обработчик ошибок связан с коммуникатором.

Синтаксис функции MPI_ERRHANDLER_CREATE представлен ниже.

int MPI_Errhandler_create(MPI_Handler_function *function,
MPI_Errhandler *errhandler)

MPI_ERRHANDLER_CREATE(FUNCTION, ERRHANDLER, IERROR)
EXTERNAL FUNCTION
INTEGER ERRHANDLER, IERROR

Функция MPI_ERRHANDLER_CREATE регистрирует процедуру пользователя в качестве обработчика MPI исключений. Возвращает в errhandler дескриптор зарегистрированного обработчика исключений.

В языке Си процедура пользователя должна быть функцией типа MPI_Handler_function , которая определяется как:

Первый аргумент является идентификатором используемого коммуникатора, второй является кодом ошибки, который будет возвращен процедурой MPI , которая выявила ошибку. Если процедура возвратила MPI_ERR_IN_STATUS , то это значит, что код ошибки возвращен в статусный объект обращения, которое запустило обработчик ошибок. Остающиеся аргументы есть аргументы « stdargs », номер и значение которых являются зависимыми от реализации. В реализации должны быть ясно документированы эти аргументы. Адреса используются так, чтобы обработчик мог быть написан на языке ФОРТРАН.

Синтаксис функции MPI_ERRHANDLER_SET представлен ниже.

int MPI_Errhandler_set(MPI_Comm comm, MPI_Errhandler errhandler)

MPI_ERRHANDLER_SET(COMM, ERRHANDLER, IERROR)
INTEGER COMM, ERRHANDLER, IERROR

Функция MPI_ERRHANDLER_SET связывает новый обработчик ошибок errorhandler с коммуникатором comm на вызывающем процессе. Заметим, что обработчик ошибок всегда связан с коммуникатором.

Синтаксис функции MPI_ERRHANDLER_GET представлен ниже.

int MPI_Errhandler_get(MPI_Comm comm, MPI_Errhandler *errhandler)

MPI_ERRHANDLER_GET(COMM, ERRHANDLER, IERROR)
INTEGER COMM, ERRHANDLER, IERROR

Функция MPI_ERRHANDLER_GET возвращает в errhandler дескриптор обработчика ошибок, связанного с коммуникатором comm. Пример: библиотечная функция может записать на входной точке текущий обработчик ошибок для коммуникатора, затем установить собственный частный обработчик ошибок для этого коммуникатора и восстановить перед выходом предыдущий обработчик ошибок.

Синтаксис функции MPI_ERRHANDLER_FREE представлен ниже.

int MPI_Errhandler_free(MPI_Errhandler *errhandler)

MPI_ERRHANDLER_FREE(ERRHANDLER, IERROR)
INTEGER ERRHANDLER, IERROR

Эта функция маркирует обработчик ошибок, связанный с errhandler для удаления и устанавливает для errhandler значение MPI_ERRHANDLER_NULL . Обработчик ошибок будет удален после того, как все коммуникаторы, связанные с ним, будут удалены.

Синтаксис функции MPI_ERROR_STRING представлен ниже.

MPI_ERROR_STRING(errorcode, string, resultlen)

int MPI_Error_string(int errorcode, char *string, int *resultlen)

MPI_ERROR_STRING(ERRORCODE, STRING, RESULTLEN, IERROR)
INTEGER ERRORCODE, RESULTLEN, IERROR
CHARACTER*(*) STRING

void MPI::Get_error_string(int errorcode, char* name, int& resulten)

Функция MPI_ERROR_STRING возвращает текст ошибки, связанный с кодом или классом ошибки. Аргумент string обязан иметь длину не менее _MAX_ERROR_STRING знаков. Число фактически записанных символов возвращается в выходном аргументе resultlen .

Объяснение: Форма этой функции была выбрана такой для того, чтобы сделать привязки в языке ФОРТРАН и Си похожими. Версия, которая возвращает указатель на строку, создает две проблемы. Во первых, возвращенная строка должна быть статически распределена и различаться для каждого сообщения об ошибке (позволяя указателям, возвращенным успешными обращениями к MPI_ERROR_STRING , указать правильное сообщение). Во вторых, в языке ФОРТРАН функция, объявленная, как возвращающая CHARACTER*(*), может не ссылаться, например, на оператор PRINT .[]

Next: Коды и классы ошибок. Up: Управление исполнительной средой MPI Previous: Получение сведений об исполнительной &nbsp Contents Alex Otwagin 2002-12-10

Источник

«Мне 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 IncvXXXcommonfilesMPI), но и иногда вредно. Подтверждающий пример приведу ниже.

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 (domainuser) [HPCvdk]: 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 FilesMicrosoft 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 не задана, то приложение просто закроется. Чтобы исключить этот вариант, нужно убедиться, что сервер лицензий виден всем узлам, т.к. хост-процесс, запрашивающий лицензию, может родиться на любом из них.

Источник

I am having problem when running MPI codes using NVIDIA MPS Service on multi-GPU nodes.

The system that I am using has 2 K80 GPUs (total of 4 GPUs).

Basically, I first set the GPU mode to exclusive_process:

nvidia_smi -c 3

Then I start the MPS Service:

nvidia-cuda-mps-control -d

When I increase the number of processes and run my code I get the following error:

 all CUDA-capable devices are busy or unavailable

Here is an example:

This is my code:

#include <stdio.h>
#include <stdlib.h>
#include "cuda_runtime.h"
#include "mpi.h"
#define __SIZE__ 1024

int main(int argc, char **argv)
{

    cudaError_t cuda_err = cudaSuccess;
    void *dev_buf;

    MPI_Init(&argc, &argv);

    int my_rank = -1;
    int dev_cnt = 0;
    int dev_id = -1;

    MPI_Comm_rank(MPI_COMM_WORLD, &my_rank);

    cuda_err = cudaGetDeviceCount(&dev_cnt);
    if (cuda_err != cudaSuccess)
        printf("cudaGET Error--on rank %d %sn", my_rank, cudaGetErrorString(cuda_err));

    dev_id = my_rank % dev_cnt;

    printf("myrank=%d dev_cnt=%d, dev_id=%dn", my_rank, dev_cnt, dev_id);

    cuda_err = cudaSetDevice(dev_id);
    if (cuda_err != cudaSuccess)
        printf("cudaSet Error--on rank %d %sn", my_rank, cudaGetErrorString(cuda_err));

    cuda_err = cudaMalloc((void **) &dev_buf, __SIZE__);
    if (cuda_err != cudaSuccess)
        printf("cudaMalloc Error--on rank %d %sn", my_rank, cudaGetErrorString(cuda_err))
    else
        printf("cudaMalloc Success++, %d n", my_rank);


    MPI_Finalize();
    return 0;
}

Here is the output for 12 processes:

#mpirun -n 12 -hostfile hosts ./hq_test

myrank=0 dev_cnt=4, dev_id=0
myrank=1 dev_cnt=4, dev_id=1
myrank=2 dev_cnt=4, dev_id=2
myrank=3 dev_cnt=4, dev_id=3
myrank=4 dev_cnt=4, dev_id=0
myrank=5 dev_cnt=4, dev_id=1
myrank=6 dev_cnt=4, dev_id=2
myrank=7 dev_cnt=4, dev_id=3
myrank=8 dev_cnt=4, dev_id=0
myrank=9 dev_cnt=4, dev_id=1
myrank=10 dev_cnt=4, dev_id=2
myrank=11 dev_cnt=4, dev_id=3
cudaMalloc Success++, 8
cudaMalloc Success++, 10
cudaMalloc Success++, 0
cudaMalloc Success++, 1
cudaMalloc Success++, 3
cudaMalloc Success++, 7
cudaMalloc Success++, 9
cudaMalloc Success++, 6
cudaMalloc Success++, 4
cudaMalloc Success++, 2
cudaMalloc Success++, 5
cudaMalloc Success++, 11

Here is the output for 14 processes:

 #mpirun -n 14 -hostfile hosts ./hq_test

myrank=0 dev_cnt=4, dev_id=0
myrank=1 dev_cnt=4, dev_id=1
myrank=2 dev_cnt=4, dev_id=2
myrank=3 dev_cnt=4, dev_id=3
myrank=4 dev_cnt=4, dev_id=0
myrank=5 dev_cnt=4, dev_id=1
myrank=6 dev_cnt=4, dev_id=2
myrank=7 dev_cnt=4, dev_id=3
myrank=8 dev_cnt=4, dev_id=0
myrank=9 dev_cnt=4, dev_id=1
myrank=10 dev_cnt=4, dev_id=2
myrank=11 dev_cnt=4, dev_id=3
myrank=12 dev_cnt=4, dev_id=0
myrank=13 dev_cnt=4, dev_id=1
cudaMalloc Success++, 11
cudaMalloc Success++, 3
cudaMalloc Success++, 7
cudaMalloc Success++, 2
cudaMalloc Success++, 10
cudaMalloc Success++, 6
cudaMalloc Success++, 1
cudaMalloc Success++, 8
cudaMalloc Error--on rank 13 all CUDA-capable devices are busy or unavailable
cudaMalloc Error--on rank 5 all CUDA-capable devices are busy or unavailable
cudaMalloc Error--on rank 9 all CUDA-capable devices are busy or unavailable
cudaMalloc Error--on rank 4 all CUDA-capable devices are busy or unavailable
cudaMalloc Error--on rank 0 all CUDA-capable devices are busy or unavailable
cudaMalloc Error--on rank 12 all CUDA-capable devices are busy or unavailable

Note: I have already tried changing CUDA_DEVICE_MAX_CONNECTIONS value, but it didn’t help.

I’d appreciate if you share your thoughts on this with me.