Чому мій ітеративний лінійний вирішувач не збігається?

Що може піти не так, якщо використовувати попередньо налаштовані методи Крилова з KSP ( пакет лінійних розв'язків PETSc ) для розв’язання розрідженої лінійної системи, такої, яку отримують шляхом дискретизації та лінеаризації часткових диференціальних рівнянь?

Які кроки я можу зробити, щоб визначити, що не так у моїй проблемі?

Які зміни я можу внести, щоб успішно та ефективно вирішити свою лінійну систему?

Початкові поради

• Завжди бігайте з, -ksp_converged_reason -ksp_monitor_true_residualнамагаючись дізнатися, чому метод не збігається.
• Зробіть розмір проблеми та кількість процесів якомога меншими, щоб продемонструвати збій. Ви часто отримуєте розуміння, визначаючи, які невеликі проблеми проявляють поведінку, яка спричиняє руйнування вашого методу, а час розвороту скорочується. Крім того, є деякі методи дослідження, які можна використовувати лише для невеликих систем.
• Якщо проблема виникає лише після великої кількості часових кроків, етапів продовження чи нелінійного кроку вирішення, розгляньте можливість запису стану моделі, коли виникає збій, щоб можна було швидко експериментувати.
• Крім того, особливо якщо ваше програмне забезпечення не має можливості контрольної точки, використовуйте -ksp_view_binaryабо MatView()зберігайте лінійну систему, тоді використовуйте код у, $PETSC_DIR/src/ksp/ksp/examples/tutorials/ex10.cщоб прочитати в матриці та вирішити її (можливо, з різною кількістю процесів). Для цього потрібна зібрана матриця, тому її корисність може бути дещо обмежена.
• Існує багато можливих варіантів вирішення (наприклад, нескінченна кількість, наявна в командному рядку в PETSc через довільну кількість рівнів складу), див. Це питання для загальних порад щодо вибору лінійних розв'язувачів.

Загальні причини не зближення КСП

• Рівняння є єдиними випадково (наприклад, забули встановити граничні умови). Перевірте це на наявність невеликої проблеми за допомогою -pc_type svd -pc_svd_monitor. Спробуйте також вирішити прямий вирішувач із -pc_type lu(паралельно через сторонній пакет, наприклад -pc_type lu -pc_factor_mat_solver_package superlu_dist).
• Рівняння є навмисно сингулярними (наприклад, постійний нульовий простір), але метод Крилова не повідомлявся, див KSPSetNullSpace().
• Рівняння навмисно однини і KSPSetNullSpace()використовувались, але права рука не узгоджується. Можливо, вам доведеться зателефонувати MatNullSpaceRemove()праворуч перед тим, як телефонувати KSPSolve().
• Рівняння невизначені, тому стандартні попередні кондиціонери не працюють. Зазвичай ви знаєте це з фізики, але ви можете перевірити значення -ksp_compute_eigenvalues -ksp_gmres_restart 1000 -pc_type none. Для простих проблем з точкою сідла спробуйте -pc_type fieldsplit -pc_fieldsplit_type schur -pc_fieldsplit_detect_saddle_point. Детальнішу інформацію див. У Посібнику користувача та довідковій сторінці PCFIELDSPLIT . Для більш складних проблем прочитайте літературу, щоб знайти надійні методи, і запитайте тут (або petsc-users@mcs.anl.govабо petsc-maint@mcs.anl.gov), чи хочете ви поради щодо їхнього втілення. Наприклад, дивіться це питання щодо високочастотного Гельмгольца. Для скромних розмірів проблеми подивіться, чи можна жити просто за допомогою прямого рішення.
• Якщо метод сходиться в попередньо обумовленому залишковому, але не в справжньому залишковому, попередній кондиціонер, ймовірно, є сингулярним або майже таким чином. Це властиво для проблем з точкою сідла (наприклад, стислий потік) або сильно несиметричних операторів (наприклад, гіперболічні проблеми з низьким Махом з великими кроками часу).
• Попередній кондиціонер занадто слабкий або нестабільний. Подивіться, чи -pc_type asm -sub_pc_type luпокращує швидкість конвергенції. Якщо GMRES втрачає занадто великий прогрес у перезапуску, подивіться, чи допоможуть триваліші перезавантаження -ksp_gmres_restart 300. Якщо транспонування доступне, спробуйте -ksp_type bcgsінші способи, які не потребують перезавантаження. (Зауважимо, що конвергенція з цими методами часто помилкова.)
• Матриця попереднього кондиціонування може бути не близькою до (можливо, не зібраного) оператора. Спробуйте вирішити за допомогою прямого рішення, послідовно -pc_type luабо паралельно, використовуючи сторонній пакет (наприклад -pc_type lu -pc_factor_mat_solver_package superlu_dist, або mumps). Метод повинен сходитися за одну ітерацію, якщо матриці однакові, а в "невеликій" кількості ітерацій - інакше. Спробуйте -snes_type testперевірити матриці, якщо вирішувати нелінійну задачу.
• Попередній кондиціонер нелінійний (наприклад, вкладене ітераційне рішення), спробуйте -ksp_type fgmres or -ksp_type gcr.
• Ви використовуєте геометричну багаторешітку, але деякі рівняння (часто граничні умови) не змінюються сумісно між рівнями. Спробуйте -pc_mg_galerkinалгебраїчно побудувати правильний масштаб грубого оператора або переконайтесь, що всі рівняння масштабуються однаково, якщо ви хочете використовувати передискретизовані грубі рівні.
• Матриця дуже погано обумовлена. Перевірте номер умови, використовуючи описані тут методи . Спробуйте покращити його, вибравши відносне масштабування компонентів / граничних умов. Спробуйте -ksp_diagonal_scale -ksp_diagonal_scale_fix. Можливо, змінити формулювання проблеми, щоб скласти більш дружні алгебраїчні рівняння. Якщо ви не можете виправити масштабування, можливо, вам доведеться використовувати прямий розв'язувач.
• Матриця нелінійна (наприклад, оцінюється за допомогою кінцевої диференціації нелінійної функції). Спробуйте різні параметри розмежування (наприклад -mat_mffd_type ds). Спробуйте використовувати більш високу точність , щоб зробити різницевий більш точним, ./configure --with-precision=__float128 --download-f2cblaslapack. Перевірте, чи він конвергується в "простіших" режимах параметрів.
• Для несиметричної задачі використовується симетричний метод.
• Класичний Грам-Шмідт стає нестабільним, спробуйте -ksp_gmres_modifiedgramschmidtабо скористайтеся методом, який ортогоналізується по-різному, наприклад -ksp_type gcr.

Моя порада студентам - спробувати прямий вирішувач у цих випадках. Причина полягає в тому, що існують два класи причин, через які розв’язувач може не сходитися: (i) матриця неправильна, або (ii) є проблема з розв'язувачем / попередньою умовою. Прямі розв'язувачі майже завжди дають щось, що ви можете порівняти з очікуваним рішенням, тому якщо відповідь прямого вирішувача виглядає правильною, то ви знаєте, що проблема полягає в ітераційному вирішенні / передумові. З іншого боку, якщо відповідь виглядає неправильно, проблема полягає у складанні матриці та праворуч.

Зазвичай я просто використовую UMFPACK в якості прямого рішення. Я впевнений, що просто спробувати щось подібне з PETSC.