Як можна перевірити чисельну реалізацію ODE?


26

Я збираюся розпочати роботу над бібліотекою програмних чисельних вирішувачів ODE , і я борюся з тим, як формувати тести для реалізацій solver. Моя мета в тому , що бібліотека, в кінцевому рахунку, буде включати в себе вирішувачі для обох nonstiff і жорстких задач, і , щонайменше , один неявний вирішувач (більш-менш на одному рівні з можливостями в odeпідпрограма в Matlab ), тому потреби методології випробувань , щоб відобразити різні типи задач та критерії для різних розв’язувачів.

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

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

    Цей метод перевіряє результати розв'язувального методу. Таким чином, немає гарантії того, що розв’язувач насправді працює, просто він працює для заданої тестової проблеми . Тому я підозрюю, що велика кількість тестових проблем потрібна, щоб впевнено перевірити, чи працює розв’язувач.

  • Вручну обчисліть рішення за кілька етапів часу, використовуючи алгоритми, які я маю намір реалізувати, а потім зробіть те саме з розв’язувачами та перевірте, чи результати однакові. Це не вимагає знання справжнього рішення проблеми, але, в свою чергу, вимагає досить багато практичної роботи.

    Цей метод, з іншого боку, перевіряє лише алгоритм , який мені добре, - якщо хтось інший довів, що Runge-Kutta працює 4- го порядку, я не відчуваю відчайдушної потреби. Однак я переживаю, що формувати тестові справи буде дуже громіздко, оскільки я не знаю гарного методу для отримання даних тесту (крім, можливо, вручну, що буде багато роботи ...).

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

Чи є інші способи перевірити числові вирішувачі ODE? Чи є інші критерії в реалізації, які слід перевірити? Чи є якісь хороші (безкоштовні) ресурси для тестування вирішувачів ODE там 1 ?

EDIT:
Оскільки це питання дуже широке, я хочу трохи уточнити. Тестовий набір, який я хочу створити, заповнить дві основні цілі:

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

  2. Тест на обґрунтованість після встановлення бібліотеки. Ці тести не повинні (не повинні) бути детальними або забирати багато часу; лише ті основи, які можна запустити за 5 секунд, але це буде сповіщати користувача, якщо щось не в графіці дивно. Таким чином, мені також потрібен спосіб побудувати тести, які є дуже простими, але все одно розповідають про стан бібліотеки.


1 Так, я гуляв очима, але більшість того, що я знаходжу, - конспекти лекцій із дуже тривіальними прикладами, за винятком виключення тестового набору CWI ODE від Барі, якого я не знаю, чи ні, як я я можу використовувати для моїх цілей, оскільки він обробляє набагато складніші рішення, ніж ті, які я хочу перевірити ...


2
@ user75064: Абсолютно! Я не знав, що цей сайт навіть існував =) Будь-які модники, не соромтеся мігрувати мене туди.
Томаш Ашан

У цій відповіді на Math Stack Exchange є посилання на інші тестові набори .
Джефф Оксберрі

@GeoffOxberry: Я знайшов кілька таких раніше. Більшість з них реалізовані у FORTRAN, і передбачає, що читач хоче перевірити вирішувачі на тій же мові, що додає ще одне джерело помилок ... Однак пара (статті про набір DETEST) виявилася справді корисною. Дуже дякую!
Томаш Ашан

Відповіді:


12

Це дуже широке запитання, і я збираюся дати тобі дещо подумати (деякі вже включені у твій пост, але вони тут повторюються для повноти).

Сфера проблем

  • Потрібно визначити інтерфейс, як вказати проблеми.
  • Чи дозволите дозволити параметри, які можна виправити або можуть змінюватись для рішень?
  • ϵ
  • Ви збираєтесь дозволити безмежну точність?
  • Ви збираєтеся перевірити швидкість та чутливість до числової точності?
  • Ви вибрали дві (можливо більше) бібліотеки, які вже існують для порівняння результатів?
  • Як ви обираєте критерії зупинки, чи будете використовувати різні методи, і дозволите користувачеві вибрати чи визначити свій власний?
  • Чи збираєтесь ви вимірювати помилки, використовуючи різні заходи, і дозволите користувачеві вмикати та вимикати їх?
  • Ви подивилися на професійні пакети, такі як Computer-Algebra-Systems (CAS), і зрозуміли всі варіанти, які вони дозволяють?
  • Чи збираєтесь дозволити показ результатів та / або порівнянь та / або графіків?

Проблемні рекомендації

  • Вам потрібно написати тестову специфікацію, яка визначає джерело проблем, масштаби тестування проблем, фіксуючи результати та метрику виконання процедур.
  • Я, безумовно, звернувся до інших бібліотек, які вже є там, для проблем, які вони використовують (можливо, тестові файли).
  • Я б ходив у бібліотеки коледжів, переглядав книги про ODE та виводив проблеми всіх типів, ті, що мають відому закриту форму або рішення, що мають лише числові значення.
  • Випадок 1: Ми хочемо отримати стільки варіацій задач вирішення закритої форми, скільки ми можемо отримати, щоб порівняти точні та чисельні результати.
  • Випадок 2: Я б перейшов до кожної книги з числовим аналізом, я можу знайти та захопити відпрацьовані приклади та дублювати їх. Я б додатково зафіксував набори проблем, особливо ті, що мають певну патологію, яка існує в більшості книг (чутливість до того чи іншого типу).
  • Випадок 3: Я б перейшов до різних галузей прикладної математики, таких як фізика, екологія, біологія, економіка тощо. al та захоплюйте проблеми з кожного з цих доменів, щоб перевірити, чи відповідає ваша мова специфікації для таких проблем.
  • Випадок 4: Я б досліджував статті / журнали, які містять найкорисніші приклади, коли конкретному автору довелося змінити певний підхід, щоб врахувати якусь патологію чи дивацтво чи твердість.
  • Випадок 5: Шукайте в Інтернеті додаткові приклади. Для жорсткості дивіться посилання тут і вивчіть їх ВСІ, щоб випробувати проблеми з тестом. Ось кілька прикладів MATLAB для ознайомлення.

Це не унікально. Якщо ви подивитесь на книгу "Числові методи для необмеженої оптимізації та нелінійних рівнянь" Денніса та Шнабеля, додаток В "Проблеми тесту", ви можете побачити, як вони це зробили. Після розробки одного з найкрасивіших наборів написаних алгоритмів, які я коли-небудь бачив, вони кинули на нього набір проблем, які зробили, якщо зникли. Вам довелося підправити тут і там! Вони включали п'ять дуже різних і патологічних проблем, які напружували можливості вирішувачів. Це навчило мене, що ми можемо продовжувати накладати проблеми на алгоритми, які вони нездатні вирішити з безлічі причин. Зауважте, вони навіть запозичили цей набір проблем у «Море», «Гарбоу» та «Хіллстром» (ви також можете знайти цю посилання, і, можливо, є й інші, які ви можете використовувати як керівництво).

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


2

Одна перевірка обґрунтованості, яку я запускаю проти моїх вирішувачів ODE, - це просто перевірити її на менших лінійних системах за допомогою точного обчислення експоненції матриці системи. тобто дано

гугт=Ау

перевірити помилку в

досвід(тА)у0-у^(т)

у^(т)

Просто не обчислюйте експоненцію одним із кроків часу (тобто сумнівним методом № 6 :) http://www.cs.cornell.edu/cv/researchpdf/19ways+.pdf )


Лише зауваження: інтегратори DE були визнані "сумнівними" в тому, що вони були дещо неефективними порівняно зі масштабуванням + квадратування, а не через неточність.
JM

1

Ви можете спробувати дослідити "Метод виготовлених рішень", що є загальною методологією, яка використовується для тестування реалізації кодів, що вирішують PDE (з його допомогою можна знайти як математичні, так і помилки кодування). Я думаю, що це могло б бути адаптовано для роботи над вирішенням ODE, якщо ваша методологія рішення є загальною.

http://prod.sandia.gov/techlib/access-control.cgi/2000/001444.pdf

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.