Лучшие методологии для управления сеткой в ​​параллельных вычислениях конечных элементов?

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

Я нахожусь в точке, где у меня запущены серийные версии, и теперь я хочу распараллелить их. В конце концов, одной из сильных сторон структуры декомпозиции доменов является разработка алгоритмов, которые легко распараллелить, по крайней мере, в принципе. На практике, однако, есть много деталей, которые необходимо учитывать. Управление сеткой является одним из них. Если приложения должны достигать высокого разрешения при хорошем масштабировании на множество процессоров, репликация всей сетки на каждом процессоре неэффективна.

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

Существует библиотека p4est для распределенного управления сеткой. Мне не нужна AMR, так что это может быть излишним, так как меня интересует только использование равномерных сеток, и я не уверен, может ли это улучшить треугольные сетки. Я также мог бы просто создать однородную сетку, затем подать ее в один из разделителей сетки и выполнить некоторую постобработку вывода.

Кажется, что самый простой подход - создать отдельный файл для каждого раздела, содержащий информацию о сетке, относящуюся только к этому конкретному разделу. Этот файл будет читаться одним процессором, который будет отвечать за сборку дискретной системы в этой части сетки. Конечно, некоторая глобальная информация о связности разделов / окрестностях также должна храниться в файле, читаемом всеми процессорами, для межпроцессного взаимодействия.

Какие еще есть подходы? Если некоторые из вас могли бы поделиться, каковы некоторые из наиболее часто используемых в отрасли методологий или государственных исследовательских учреждений, связанных с решением этой проблемы? Я совершенно новичок в программировании параллельного решателя конечных элементов, и мне хотелось понять, правильно ли я думаю об этой проблеме и как другие к ней подходят. Будем весьма благодарны за любые советы или ссылки на соответствующие исследовательские статьи!

Заранее спасибо!

Если вы не используете AMR и не хотите масштабировать больше 1K-4K ядер, просто сделайте это.

1. Ранг 0 считывает всю сетку и разбивает ее, используя METIS / Scotch и т. Д. (Примечание: это последовательная операция).

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

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

4. Все ранги должны создавать локальные / глобальные отображения узлов / элементов / dof для применения BC и сборки матриц и перенумерации узлов.

После того, как все сказано и сделано, все данные о ранге будут локальными, так что вы сможете хорошо масштабировать (в отношении памяти). Я делаю все это примерно в 100 строк (см. Строки 35-132 здесь ) в моем небольшом коде.

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

Между прочим, AMR-библиотеки обычно не занимаются тэтом. Также PETSc является хорошим выбором для распараллеливания вашего кода.

Изменить: Также см. Здесь и здесь .

Это может вас не удивить, если учесть, что я разрабатываю сделку. II, но вот моя точка зрения: когда я разговариваю со студентами, я обычно говорю им сначала разработать собственный прототип, чтобы они могли видеть, как это делается. Но потом, когда у них что-то работает, я заставляю их использовать библиотеку, которая позволяет им идти намного дальше, потому что им не нужно изобретать велосипед практически с каждым шагом, который они делают.

В вашем случае вы уже видели, как реализовать простой решатель Гельмгольца. Но вы потратите следующие 6 месяцев на написание кода, необходимого для параллельного выполнения, вы потратите еще 3 месяца, если хотите использовать более сложные геометрии. Затем вы потратите еще 6 месяцев, если вам нужен эффективный решатель. И все это время вы пишете код, который уже был написан кем-то другим, и который, в некотором смысле, не приближает вас к тому, что вам на самом деле нужно сделать для вашего доктора философии: разрабатывать что-то новое, что не было сделано раньше. Если вы пойдете по этому пути, вы потратите 2-3 года своего доктора наук на то, чтобы сделать то, что делали другие, и, возможно, 1 год на то, чтобы сделать что-то новое.

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

Это не полный ответ.

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