Каковы хорошие типы данных для неструктурированного кода FVM CFD на основе ячеек?

Мне интересны советы по созданию эффективных структур данных для просмотра ячеек в неструктурированных CFD с конечным объемом на основе ячеек.

Один из примеров, с которыми я столкнулся (в коде dolfyn cfd ), выглядит следующим образом (я покажу соответствующий сегмент) list } Итак, у нас есть массив NFaces, в котором хранится количество граней для каждой ячейки. Затем массив CFace, который отображает локальный номер лица в глобальный номер лица.

Код основан на лице, поэтому существует тип данных лица, в котором хранится серийный номер двух ячеек, лежащих между Face (k)% cell1 и Face (k)% cell2.

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

Показанная вами структура является обычным выбором и эквивалентна хранению смежности граней ячеек в матричном формате CSR с выделенными ячейками границы в специальном месте. Тем не менее, обратите внимание, что методы FV также могут быть сформулированы так, чтобы они полностью или почти полностью состояли из обхода лица, при котором каждое лицо посещается только один раз (реконструкция по центроидной / квадратурной точке лица с обеих сторон, решение проблемы Римана, распределение потока обратно в остаток на ячейках ). Вы можете «подделать» это, используя обход на основе ячеек и пропуская любые две ячейки, которые находятся ниже «диагонали» в разреженной матрице, но популярной альтернативой является хранение(leftCell, rightCell) = support(face), в этом случае лица становятся первоклассными объектами. Это полезно, потому что вам обычно нужно место для хранения квадратурных точек лица (центроидов), нормалей лица. Вы также можете поместить детали реконструкции (например, наименьшие квадраты) в структуры данных на основе лица. Обход грани, по-видимому, удобен для векторизации, поскольку все размеры являются регулярными, но, с другой стороны, выходы перекрываются, поэтому вам необходимо организовать обход, чтобы не помещать его во внутренний цикл. При такой более ориентированной на грани структуре данных естественно упорядочить номера граней так, чтобы каждый тип граничного условия мог применяться с использованием непрерывного обхода граней (также дружественных к векторизации).

Если вы выберете эту структуру данных, не забудьте отсортировать грани так, чтобы при повторном использовании данные ячейки в кеше использовались как можно чаще. См. Любой из документов PETSc-FUN3D для анализа производительности упорядочения лица и связанных оптимизаций.

Я знаю, что на этот вопрос уже дан ответ, но вот похожее хранилище циклов на основе одного лица, которое реализовано в библиотеке OpenFOAM C ++:

Каждая ячейка имеет индекс (ID) в cellList. Для всех лиц определены два списка: «лицо внутреннего владельца» и «лицо соседа». Длина обоих списков граней соответствует количеству внутренних граней в сетке. Владелец лица будет ячейкой с более низким идентификатором в cellList (напротив для лица соседа). Граничные грани записываются в последнюю очередь и имеют ориентированные наружу нормали (из области решения) и, конечно, только одну ячейку-владельца. Нормальная область лица ориентирована так, чтобы она смотрела наружу из ячейки владельца в соседнюю ячейку.

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

Поскольку граничные грани агломерированы в патчи, межпроцессное взаимодействие определяется для связанных (процессорных) патчей и предопределено. Это означает, что, как только петля пересекает граничную сетку, функции доступа верхнего уровня вызывают обернутые вызовы MPI, делая такой код «автоматически» распараллеленным, если он опирается на вышеописанное соединение на основе лица.