Схема памяти для данных сетки в научных вычислениях - PullRequest
Новая
       38

Схема памяти для данных сетки в научных вычислениях

1 голос
/ 01 ноября 2010

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

Вы можете использоватьдва крайних подхода:

  • В отношении свойств: ведение единого массива для каждого свойства:

    double* x, *y, *z, *e_field, *b_field, *conductivity;

  • Ввод-wise: Поддерживать один единственный массив, где каждый массив имеет структуру

    struct { double x, y, z, e_field, b_field, conductivity; } *meshnodedata;

Между ними можно смешиваться, например, применяя второй подход только для координатx, y, z и используя первый подход для остальных свойств.Чем больше свойств ваша симуляция поддерживает для каждого узла сетки, тем больше возможностей для микширования.

С одной стороны, у меня возник классический вопрос, какой из этих подходов (и их миксов) лучше всего подходит для научных вычислений в отношениипроизводительность программы и ремонтопригодность кода.С другой стороны, мне интересно, как реализовать код таким образом, чтобы переход между различными подходами стал простым.Кроме того, это может быть даже решение для перехода между различными макетами памяти для разных частей программы.

Чтобы подойти к вопросу:

  • Какие у вас были переживания с этими разнымиподходы?
  • Насколько значительными были эти различия?
  • Получили ли вы опыт миграции между этими двумя макетами?

1 Ответ

3 голосов
/ 01 ноября 2010

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

  1. Существует масса фреймворков FE и менеджеров сетки - используйте один из них!

  2. Грид-менеджеры более сложны, чем думают многие.Пока он работает только в 3D на одном компьютере, он все еще может быть управляемым.Диспетчер сетки со смешанными типами элементов в 3D с локальным уточнением и параллельной балансировкой нагрузки - огромная задача.Разрабатывайте свой собственный менеджер сетки только в том случае, если вы знаете, что хотите улучшить по сравнению с легкодоступными.

  3. Структура памяти. Теперь перейдем к актуальному вопросу:)
    Отдельная сеткаданные и проблемные данные.Это сделает ваш код более понятным.Диспетчер сетки может использоваться для различных задач, и каждая проблема имеет свой собственный набор данных, прикрепленный к каждому элементу.

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

  5. Храните ваши неизвестные (вероятно, e_field и b_field в вашем примере) в одном непрерывном блоке памяти.Это значительно повысит производительность вашего линейного решателя.Итеративный линейный решатель обычно ограничен пропускной способностью памяти для больших матриц.

  6. Внутренняя структура вашего вектора неизвестных может быть сгруппированной или блочной (в основном два подхода, которые вы описали сами)Какой из этих двух подходов выбрать для нумерации неизвестных зависит от многих факторов, включая тип PDE, который вы решаете, и тип линейного решателя, который вы используете.Только по этой проблеме есть много научных публикаций.

...