Які хороші типи даних для неструктурованого коду FVM CFD, орієнтованого на клітинку?

Мене цікавить порада щодо ефективних структур даних для перегляду стільників у неструктурованому КЗД на кінцевому об'ємі з кінцевим об'ємом.

Один із прикладів, з якими я стикався (у коді dolfyn cfd ), виглядає так (я покажу відповідний сегмент) Internal Отже, у нас є масив NFaces, де зберігається кількість граней для кожної комірки. Потім масив CFace, який відображає номер обличчя від локальної до комірки до глобального номера обличчя.

Код заснований на обличчі, тому існує тип даних особи, який зберігає порядковий номер двох комірок, він лежить між Face (k)% cell1 та Face (k)% cell2.

Будь-які коментарі щодо цього або пропозиції щодо альтернативного підходу вітаються.

Показана вами структура - це звичайний вибір і рівнозначна збереженню прилягань клітини-обличчя у форматі матриці CSR, причому осередки прикордонних примар мають особливе місце. Однак зауважте, що методи FV також можуть бути сформульовані так, щоб повністю або майже повністю складалися з обходу обличчя, де кожне обличчя відвідується лише один раз (реконструюйте до центральної / квадратурної точки з обох сторін, вирішіть задачу Рімана, розподіліть флюс назад у залишки на клітинах ). Ви можете "підробити" це, використовуючи обхід на основі комірок і пропустивши будь-які дві комірки, які знаходяться нижче "діагоналі" в рідкій матриці, але популярною альтернативою є зберігання(leftCell, rightCell) = support(face), в цьому випадку обличчя стають сутнісними категоріями. Це корисно, оскільки вам зазвичай потрібно місце для зберігання квадратурних точок обличчя (центроїдів), нормальних облич. Ви також можете розмістити частини реконструкції (наприклад, найменші квадрати) в структурах даних на основі обличчя. Обхід обличчя здається векторизаційним, тому що всі розміри є регулярними, але, з іншого боку, є виходи, що перекриваються, тому вам потрібно організувати обхід, щоб не ставити його у внутрішню петлю. Завдяки цій структурі даних, орієнтованої на обличчя, природно впорядкувати номери обличчя, щоб кожен тип граничних умов можна застосувати за допомогою суміжного обходу граней (також сприятливого для векторизації).

Якщо ви вибираєте цю структуру даних, не забудьте сортувати обличчя, щоб обхід даних максимально використовував дані комірок у кеші. Дивіться будь-який документ із PETSc-FUN3D для аналізу ефективності впорядкування обличчя та пов'язаних з ними оптимізацій.

Я знаю, що на це питання вже відповіли, але ось схожий циклічний накопичувач на основі однієї особи, який реалізований у бібліотеці OpenFOAM C ++:

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

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

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