Розробка наукових алгоритмів - це дуже ітераційний процес, який часто включає зміну безлічі параметрів, які я хочу змінити або як частина мого експериментального дизайну, або як частина роботи алгоритму налаштування. Які стратегії я можу взяти за структурування цих параметрів, щоб я міг легко змінювати їх між ітераціями, щоб я міг легко додавати нові?
Відповіді:
Користувач громіздко визначає кожен аспект алгоритму. Якщо алгоритм дозволяє вкладені компоненти, то жодної кінцевої кількості варіантів не буде достатньо. Тому вкрай важливо, щоб параметри не обов'язково "піднімалися" до верхнього рівня, як у випадку явних аргументів або параметрів шаблону. Іноді це називається "проблемою конфігурації" в інженерії програмного забезпечення. Я вважаю, що PETSc має унікально потужну систему управління конфігурацією. Він схожий на схему «Локатор послуг» у нарисі Мартіна Фаулера про інверсію контролю .
Система конфігурації PETSc працює за допомогою комбінації визначеної користувачем конфігурації, керованої об'єктами solver (із запитами отримання та встановлення) та базою даних параметрів. Будь-який компонент моделювання може оголосити параметр конфігурації, значення за замовчуванням та місце для розміщення результату. Вкладені об'єкти мають префікси, які можна скласти таким чином, що кожен об'єкт, який потребує конфігурації, може бути адресований незалежно. Самі параметри можна читати з командного рядка, середовища, файлів конфігурації або з коду. Коли опція оголошена, вказується рядок довідки та довідна сторінка, щоб -helpпараметр був зрозумілим і щоб можна було записати правильно пов'язаний графічний інтерфейс.
Користувач викликає SetFromOptionsметод зробити сам конфігурацію об'єкта на основі параметрів командного рядка. Виклик цієї функції необов'язковий і не може бути викликаний, якщо користувач (особа, що пише код, який викликає PETSc) відкриває параметри через якийсь інший інтерфейс. Ми настійно рекомендуємо користувачеві виставляти базу даних з опціями, оскільки це дає кінцевому користувачеві (особі, яка запускає додаток) велику потужність, але це не потрібно.
Типова конфігурація, що називається через
PetscObjectOptionsBegin(object); /* object has prefix and descriptive string */
PetscOptionsReal("-ts_atol", /* options database key */
"Absolute tolerance for local truncation error", /* long description */
"TSSetTolerances", /* function and man page on topic */
ts->atol, /* current/default value *?
&ts->atol, /* place to store value */
&option_set); /* TRUE if the option was set */
PetscOptionsList("-ts_type","Time stepping method","TSSetType",TSList,
defaultType,typeName,sizeof typeName,&option_set);
TSAdaptSetFromOptions(ts->adapt); /* configures adaptive controller method */
/* ... many others */
/* ... the following is only called from implicit implementations */
SNESSetFromOptions(ts->snes); /* configure nonlinear solver. */
PetscOptionsEnd();
Примітки:
PetscOptionsList()представляє користувачеві вибір з динамічного списку. Існує архітектура плагінів, яку нові реалізації можуть використовувати, щоб піддавати себе як першокласні абоненти. (Ці реалізації можна розмістити в спільних бібліотеках і використовувати як першокласні без перекомпіляції програм.)SNESSetFromOptions() рекурсивно налаштовує лінійні розв'язувачі, попередні кондиціонери та будь-які інші компоненти, які потребують конфігурації.Я декілька разів стикався з цією проблемою, коли розробляв власні коди імітації з нуля: які параметри повинні входити у вхідний файл, які слід брати з командного рядка тощо. Після деяких експериментів наступне виявилося ефективним. (Він не такий просунутий, як PETSc.)
Замість того, щоб написати експериментальну програму моделювання, я більше схильний написати пакет Python, який містить усі функції та класи, необхідні для запуску моделювання. Традиційний вхідний файл замінюється невеликим сценарієм Python з 5 - 10 рядками коду. Деякі рядки, як правило, стосуються завантаження файлів даних та вказівки виводу. Інші - це інструкції щодо фактичного обчислення. Хороші значення за замовчуванням для необов’язкових аргументів у пакеті Python роблять його можливим для початківців використовувати бібліотеку для простих імітацій, тоді як досвідчений користувач все ще має доступ до всіх дзвіночків.
Кілька прикладів:
В першу чергу я б зробив алгоритм І програмне забезпечення максимально загальним. Я навчився цього важким шляхом.
Скажімо, ви починаєте з простого тестового випадку. Ви можете зробити це швидше. Але тоді, якщо ви зробили програмне забезпечення занадто конкретним (занадто мало параметрів) для цього початкового випадку, ви втрачаєте все більше і більше часу, адаптуючи його щоразу, коли ви додаєте нову ступінь свободи. Що я зараз роблю, це витрачаю більше часу на початку, роблячи річ досить загальною, і збільшуючи зміну параметрів під час руху вперед.
Це передбачає більше тестування з самого початку, оскільки у вас буде більше параметрів з початкової точки, але це означає, що ви можете остаточно грати з алгоритмом при нульовій або дуже низькій вартості.
Приклад: алгоритм включає обчислення поверхневого інтеграла крапкового добутку двох векторних функцій. Не припускайте спочатку розмір, геометрію та дискретизацію поверхні, якщо в майбутньому ви, можливо, захочете це змінити. Зробіть функцію крапки-добутку, зробіть поверхню якомога загальнішою, обчисліть інтеграл приємно формально. Ви можете перевірити кожну функцію, яку ви робите окремо.
На початку ви можете і почати інтегруватись за допомогою простих геометрій і оголошувати параметри май на початку як константи. З плином часу, якщо ви хочете змінити геометрію, ви можете це зробити легко. Якби ви зробили припущення на початку, вам доведеться щоразу міняти весь код.