Кращі методології управління сіткою при обчисленні паралельних кінцевих елементів?


11

В даний час я розробляю метод декомпозиції домену для вирішення проблеми розсіювання. В основному я вирішую систему Helmholtz BVP ітеративно. Я дискретизую рівняння методом кінцевих елементів у трикутних або чотиригранних сітках. Я розробляю код до своєї кандидатської дисертації. Мені відомі деякі існуючі бібліотеки з кінцевими елементами, такі як deal.ii або DUNE, і, хоча я вважаю, що вони чудові, з надихаючим дизайном та API, для цілей навчання я хотів розробити власне маленьке додаток з нуля.

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

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

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

Найпростішим підходом, здається, є створення окремого файлу для кожного розділу, що містить мережеву інформацію, що стосується лише конкретного розділу. Цей файл читатиметься одним процесором, який би відповідав за збірку дискретної системи на цій частині сітки. Звичайно, деякі відомості про підключення / сусідство глобальних розділів також повинні зберігатися у файлі, який читають усі процесори для міжпроцесорної комунікації.

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

Спасибі заздалегідь!


Якщо ви шукаєте сітчастий роздільник - METIS буде хорошим вибором. Перевірте також ParMETIS. Управління сітками - це інша історія, ITAPS iMesh може стати рішенням для вас. Будь ласка, перевірте також відповіді на моє запитання тут: scicomp.stackexchange.com/questions/4750/…
Krzysztof Bzowski

@KrzysztofBzowski: можливо, ви також використовували бібліотеку шотландців? Мені було цікаво, в чому різниця між Скотчем та Метісом, коли мова йде про кінцеві елементи. Проект iMesh здається дуже цікавим. Я детальніше про це прочитаю найближчими днями. Я знаю про deal.II та DUNE. Я пам'ятаю, що заглядав у OpenMesh деякий час тому, але подумав, що буде легше реалізувати потрібну мені функціональність з нуля. Для послідовних сіток я в основному адаптував структуру даних половини краю / обличчя, представлену в цьому паперовому посиланні Спасибі!
середина

Відповіді:


7

Якщо ви не використовуєте AMR і не хочете масштабувати більше ядер 1К-4К, просто виконайте це.

  1. Ранг 0 зчитує всю сітку та її розділи за допомогою METIS / Scotch тощо (Примітка: Це послідовна операція).

  2. Ранг 0 передає інформацію про розподіл елементів / вузлів для всіх інших рангів та звільняє пам'ять (використовується для зберігання сітки)

  3. Усі ранги читають наявні у них вузли / елементи (включаючи привидні вузли) з одного вхідного файлу (Примітка: 2000 рангів, що отримують доступ до одного і того ж вхідного файлу, може здаватися повільним, але це не на практиці, хоча це може бути погано для файлової системи, але тоді ми роблять це лише один раз).

  4. Усі ранги повинні створити локальне до глобального відображення вузла / елемента / dof для застосування БЦ та складання матриць та перенумерування вузлів.

Після того, як все буде сказано і зроблено, всі дані про ранги будуть локальними, тому ви повинні мати змогу добре масштабувати (пам'ять). Я роблю все це близько 100 ліній (див ліній 35-132 тут ) в невеликому коді шахти.

Тепер, якщо ваша сітка занадто велика (наприклад,> 100-250 мільйонів елементів), що ви не можете розділити її за допомогою METIS на одному вузлі і вам потрібен ParMETIS / PT-Scotch, тоді у вас є додаткова робота з розділенням її паралельно перед усіма ядрами / чини можуть це прочитати. У такому випадку може бути простіше тримати фазу розділення від основного коду з логістичних причин.

Btw AMR мочки зазвичай не роблять тети. Також PETSc є хорошим вибором для паралелізації вашого коду.

Редагувати: також дивіться тут і тут .


Дякуємо, що поділилися кодом! Я, швидше за все, прийму маршрут, який ви окреслили вище. Це здається найменш складним, і я вже маю уявлення, як це робити. Крім того, це буде хорошою вправою в програмуванні MPI. Ви згадали, що вугілля AMR, як правило, не справляється з тваринами. Це було б тому, що наївне вдосконалення, наприклад, квадратичного дерева трикутної сітки, може призвести до поганої якості сітки? Удосконалити квадратики здається просто, але розділити тет на чотири здається складно, якщо хочеться зберегти якість. Чи може бути обгортка C ++ для PETSc? Я можу використовувати C, але C ++ буде краще.
середина

@midurad Якщо ви віддаєте перевагу C ++ над C, вам слід розглянути Trilinos, що є бібліотекою C ++, порівнянною з PETSc. Крім того, у Trilinos є пакет (Zoltan), який ви можете використовувати для проведення сітчастого перегородки.
Dr_Sam

@midurad Вам потрібно лише дуже мало MPI-дзвінків, якщо ви використовуєте PETSc. Удосконалення тетів повинно бути простим, але мати справу (ефективно) із пов'язаними з ними динамічними структурами даних може вимагати певної думки та роботи. Ви повинні мати можливість використовувати PETSc з C ++, але, враховуючи ваші вимоги, libmesh може бути життєздатним варіантом (я думаю, він підтримує AMR та тети).
stali

Дякую всім за інформацію. Це було дуже корисно.
середина

2

Це може не стати для вас несподіванкою, враховуючи те, що я розробляю deal.II, але ось моя точка зору: Коли я розмовляю зі студентами, то, як правило, я їм кажу на початку розробити власний прототип, щоб вони побачили, як це робиться. Але потім, після того, як у них щось невелике працює, я змушую їх використовувати бібліотеку, яка дозволяє їм іти набагато далі, тому що їм не потрібно винаходити колесо в основному кожен крок, який вони роблять.

У вашому випадку ви вже бачили, як реалізувати простий вирішувач Helmholtz. Але ви витратите наступні 6 місяців на написання коду, необхідного для паралельного його виконання, ви витратите ще 3 місяці, якщо хочете використовувати більш складні геометрії. Потім ви витратите ще 6 місяців, якщо хочете ефективного рішення. І весь цей час ви пишете код, який вже написав хтось інший і який, певно, не наблизить вас до того, що вам потрібно насправді зробити для доктора наук: розробити щось нове, чого ще не було зроблено раніше. Якщо ви підете цією дорогою, ви витратите 2-3 роки свого докторського часу, роблячи те, що зробили інші, і, можливо, 1 рік робите щось нове.

Альтернативою є те, що зараз ви витрачаєте 6 місяців на вивчення однієї з існуючих бібліотек, але після цього у вас буде 2-3 роки, де ви дійсно робите нові речі, і це те, де кожен другий тиждень ви можете зайти в кабінет свого консультанта і показати йому / їй щось по-справжньому нове, що працює в масштабних масштабах або просто дуже здорово в інших аспектах. Я думаю, ти, мабуть, бачиш, куди я зараз з цим іду.


3
Чесне запитання, оскільки ви, очевидно, авторитет у цьому: хто збирається написати наступне покоління фреймворків, таких як deal.ii, якщо ніхто з нинішніх уроків докторантів не вирішує подібних проблем? Ми вже бачимо проблемну тенденцію прийому докторантів, які ніколи навіть не складали програму. Мені трохи непокоїть те, що середні навички розробки коду, здається, постійно зменшуються в галузі обчислювальної техніки.
Аврелій

1
Справедливе питання. Вам потрібні студенти з такою головою і впертістю, як я :-) Але моя відповідь полягає в тому, що тільки тому, що нам, мабуть, потрібно кілька людей, які це роблять, це не означає, що ми повинні заохочувати всіх витрачати роки свого життя на повторення що вже реалізували інші.
Вольфганг Бангерт

2
Так, досить справедливо. IMO, найбільша річ, яка стримувала світ досліджень CFD протягом останніх 20 років, - це відсутність таланту програмної інженерії та відмова від сучасних програмних практик сірими бородами. Рамки вбік, тому багато аспірантів стримуються поганим спадковим кодом та неможливістю швидко сконструювати складні програмні засоби, необхідні для сучасних чисельних методів на сучасному обладнанні.
Аврелій

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

0

Це не повна відповідь.

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

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