Будь-які рекомендації щодо одиничних тестувань рамок, сумісних з кодом / бібліотеками, які використовують MPI?

Зазвичай я пишу серійний код, і коли це роблю, я пишу одиничні тести з деякою рамкою тестування у стилі xUnit (MATLAB xUnit, PyUnit / nos або тестова рамка C ++ Google).

Спираючись на короткий пошук в Google, я не бачив багато того, як практикуючі опрацьовують тестовий код, який використовує MPI. Чи є найкращі практики для цього?

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

Більшість того, що я шукаю для тестування, - це правосторонні оцінки функцій та схеми складання матриці Якобії для тимчасових кроків, які будуть інтегрувати напівдискретні PDE. Я буду використовувати PETSc, тому якщо є щось певне для PETSc, це було б корисно на додаток до більш загальних рамок тестування.

Поправки до уточнення:

Прикладом може бути те ${PETSC_DIR}/src/ts/examples/tutorials/ex2.c, де я хотів би перевірити щось на кшталт RHSFunction(оцінка функції правої частини) таRHSJacobian(оцінка матриці Якобії). Я б протестував на відомі значення для зібраної правої частини та зібраної матриці Якобі; Я можу отримати ці значення аналітично для деяких простих випадків проблеми. Ці функції - це функції, що стосуються додатків, які не виконують жодної іншої функції на рівні додатків, але вони можуть викликати MPI, якщо вектор або матриця збирається в межах функції (як у зв'язаному прикладі PETSc вище). Якщо я пишу функції, які обчислюють лише частину векторів або матриць, локальних для процесора, я б хотів перевірити глобальну, зібрану версію, якщо це можливо, тому що, будучи новим для паралельного програмування, мені інтуїтивніше думати про глобальні вектори та глобальні матриці. Ці тести проводитимуться на невеликих розмірах проблем та невеликій кількості процесорів.

Я можу придумати кілька стратегій для цього:

• Стратегія, яка, ймовірно, не спрацює добре, базуючись на пошуках Google у цій темі, - це побудувати відомий вихід, паралельно знайти відносну / абсолютну помилку, а потім виконати наївні порівняння. Результат, ймовірно, буде пошкодженим - кожен, хто написав програму MPL «Привіт, світ», знає, чому - що обмежує корисність тестування одиниць. ( Це стало поштовхом до запитання. ) Також, мабуть, є певна потенційна хитрість у виклику рамки тестування одиниць.
• Запишіть вихідний файл у файл (наприклад, у PETSc, використовуючи VecViewта MatView) та порівняйте із відомим виводом щось подібне до ndiffабо numdiff. Моє відчуття кишки за допомогою цього методу з попереднього досвіду тестування одиниць із порівнянням файлів полягає в тому, що він буде витонченим, і він потребує деякої фільтрації. Цей метод здається, що він буде чудовим для регресійного тестування, оскільки я міг би замінити утиліти вище звичайними diff, і не потрібно турбуватися про відповідність текстових форматів. Я зібрав, що ця стратегія - це більш-менш те, що пропонують ВольфгангБангерт та Андібауер. PETSc також використовує подібний підхід для деяких тестувань.
• Використовуйте блок тестування блоків, збирайте все на процесор з MPI ранг 0 і попросіть його виконати тести одиниць, лише якщо ранг процесора дорівнює 0. Я міг би зробити щось подібне з нормами (це, мабуть, ще простіше), хоча компроміс полягає в тому, що будь-які повернуті помилки підкажуть мені, що у мене є проблема в моєму розрахунку, але не те, які елементи помиляються. Тоді мені не потрібно турбуватися про те, що будь-який одиничний тестовий вихід буде зібраний; Мені потрібно лише турбуватися про те, щоб правильно викликати рамки тестування блоку. PETSc, як видається, використовує нормознавчі порівняння у своїх прикладних програмах, коли є точні рішення, але він не використовує блок тестування підрозділів при здійсненні цих порівнянь (а також не обов'язково).

Я щасливий користувач GoogleTest з C ++ MPI-кодом у середовищі побудови CMake / CTest:

• CMake автоматично встановлює / посилає googletest із svn!
• додавання тестів - це однолінійний!
• написання тестів легко! (і глузливість Google дуже потужна!)
• CTest може передавати параметри командного рядка у ваші тести та експортувати дані на CDash!

Ось як це працює. Пакет одиничних тестів, що вимагають mpi, записується у якийсь my_mpi_test.cppфайл, який виглядає приблизно так:

#include <gtest/gtest.h>
#include <boost/mpi.h>

/// Most testing libraries allow to define main yourself to override initialization.
int main(int argc, char* argv[]) {
    ::testing::InitGoogleTest(&argc, argv);  /// Set gtest environment
    mpi::environment env(argc, argv);  /// Set mpi environment
    return RUN_ALL_TESTS();  /// Execute all gtest tests
}

TEST(test_batch_name, test_name) {  /// Then you can create tests as usual,
  using namespace mpi;
  communicator world;  /// and use MPI inside your tests.
  /* ... test stuff here ... */
}

CMakeLists.txt, який додає цей тест, є:

add_mpi_test(my_mpi 2)  # Uses 2 MPI processes

де add_mpi_testзагортає CMake add_testвсередині мого кореня CMakeLists.txt:

function(add_mpi_test name no_mpi_proc)
  include_directories(${MY_TESTING_INCLUDES})
      # My test are all called name_test.cpp
      add_executable(${name} ${name}_test.cpp)
      add_dependencies(${name} googletest)
  # Make sure to link MPI here too:
  target_link_libraries(${name} ${MY_TESTING_LIBS})
  set(test_parameters ${MPIEXEC_NUMPROC_FLAG} ${no_mpi_proc} "./${name}")
      add_test(NAME ${name} COMMAND ${MPIEXEC} ${test_parameters})
endfunction(add_mpi_test)

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

Існує кілька програмних пакетів з підтримкою MPI, які використовують набір інструментів CMake для тестування. Ті, про які я можу придумати голову, - це Trilinos, VTK та ParaView. Я думаю, що ви не хочете припускати, що виконуваний файл потрібно запустити за допомогою mpirun та / або mpiexec. CMake має підтримку вказувати, як правильно запустити виконуваний файл разом з різними параметрами, такими як максимальна кількість процесів для використання та, до необхідності, до і після прапорців.

Ви можете подивитися розділ сайтів HPC на панелі приладів ParaView, де проводяться тести на різних суперкомп'ютерах NERSC та Argonne. Тут також є більшість налаштувань, які вам потрібно буде вказати, щоб вони працювали на цих машинах.

Для довідки, приладова панель Trilinos має найрізноманітніші перелічені пакети, і для мене це досить вражає своєю організацією.

Повне розкриття інформації: Я є працівником Kitware, і CMake - один із проектів з відкритим кодом, з яким Kitware задіяний.

Ми просто наводимо власний код у deal.II - по суті, ми повідомляємо рамки для виконання тестів, використовуючи mpirun -np .... Раніше ми тільки використовували схему тестування на основі Makefile (компілювати, посилати, виконувати тест, потім порівнювати вихідний з тим, який раніше був збережений), і ви можете знайти це тут:

• https://svn.dealii.org/branches/releases/Branch-8-0/tests/mpi/Makefile

а для контексту цілі, що не стосуються MPI:

• https://svn.dealii.org/branches/releases/Branch-8-0/tests/Makefile.rules

Ми переписуємо речі за допомогою CMake / CTest, з поточною розробкою тут:

• https://svn.dealii.org/branches/branch_port_the_testsuite/tests/CMakeLists.txt
• https://svn.dealii.org/branches/branch_port_the_testsuite/tests/cmake/

Тестовий джгут Teuchos Unit в Trilinos в основному підтримує модульні тести, що використовують MPI. Такі речі, як контроль виводу з декількох процесів та агрегація пропуску / відмови над усіма процесами, є автоматичним. Поглянь:

http://trilinos.org/docs/dev/packages/teuchos/doc/html/group__Teuchos__UnitTest__grp.html