C ++ или Python для разработки библиотеки CFD


13

Что бы вы сказали о преимуществах / недостатках двух подходов к кодированию общей (конечного объема, fem, dg) библиотеки для вычислительной механики сплошных сред? Вот как я вижу вещи прямо сейчас, поэтому, пожалуйста, предоставьте свой собственный опыт и не подгоняйте меня к моему :):

1) C ++:

  • универсальное программирование, виртуальные функции, перегрузка, скорость ...: все инструменты общего назначения + ООП доступны для создания того, что вы хотите

  • в основном доступны низкоуровневые библиотеки (нет широко распространенных научно-технических библиотек, таких как Python)

2) Python + обертки для параллельных вычислений (pyOpenCL и другие)

  • огромное количество поддерживающих библиотек разных видов

  • код, что вы думаете: реализация делается очень быстро

  • медленное время выполнения

Если бы вы хотели написать код, который бы поддерживал различные методы, работал со сложной геометрией и проблемами, что бы вы выбрали и почему?


1
Я не очень знаком с pyOpenCL, но в целом Python будет слишком медленным даже для задач среднего размера в 2D или 3D, если только ваши вычислительные «ядра» не реализованы на языке низкого уровня (Fortran, C и т. Д.). )
Дэвид Кетчон

Ответы:


14

Я хотел бы получить лучшее из обоих миров и кодировать «пользовательский интерфейс» (то есть структуру функций, которые пользователь вашей библиотеки будет вызывать для описания геометрии и других свойств проблемы) в Python, чтобы получить быстрый время выполнения, затем запишите время выполнения моделирования в C ++.

Фактически, я бы, вероятно, сначала смоделировал даже время выполнения симуляции в Python, а затем заменил бы его на кусочек кода C ++. В конце концов, вы можете подумать о том, чтобы ваш код Python генерировал исходный код C ++, чтобы он был скомпилирован и связан с вашей средой выполнения в Интернете, так что фактическое моделирование вообще не должно вызывать Python - только возвращать результаты в конце. Хорошая особенность этой установки в том, что она по своей природе гибкая: вы начинаете с самого быстрого и простого рабочего решения, вы быстро узнаете, что работает, а что нет, и как только у вас появится что-то, что вам понравится, вы можете начать его ускорять.

(Так работает решатель ODE / DAE Maple, за исключением использования Maple вместо Python. Полное раскрытие: я работаю для них.)


1
+1. Одним из приятных моментов Python является возможность отойти от «Pure Python», если это необходимо.
Fomite

3

Вы также можете использовать Cython для своих алгоритмов. По сути это Python с добавленной информацией о типе для некоторых переменных, которые должны быть «быстрыми». Он переводит код Python в код C, который впоследствии может быть скомпилирован вашим любимым компилятором C. Тщательное добавление информации этого типа может сделать ваш код в 150 раз быстрее, чем простой код Python.


2

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

Возможно, также важно принять во внимание

3) Время разработки

  • сколько времени отведено на разработку
  • когда результаты работы должны быть доставлены? и как?
  • уже существует код, который может сделать эту работу? (Уникальность?)

4) Техническое обслуживание

  • сколько (человек) ресурсов выделено на обслуживание?
  • сколько людей должно работать над кодом?
  • Код должен быть выпущен в какой-то момент? (критерии?)
  • Будет ли код полагаться на сторонние библиотеки?

5) Вопрос лицензирования

  • такое код для исследования?
  • такое код для коммерческих приложений?

6) Коэффициент производительности и веселья (часто упускается из виду!)

  • Где можно быть наиболее продуктивным?
  • Где можно развлечься?
  • Есть ли возможность стать частью (социальной) сети?

2

Это зависит от того, может ли ваш код быть написан как:

some_library_specific_type grid;

for t=0 to T do
    library_function_1(grid,...);
    library_function_2(grid,...);
end

точнее должно быть написано как то так:

some_home_made_mixture_of_native_types grid;

for t=0 to T do
    for all grid elements as g do
        some_function(g,...);
        library_function(g,...);
    end
end

В первом случае выберите то, что вам больше всего нравится в коде; во втором случае не используйте какой-либо язык сценариев или готовьтесь страдать от времени выполнения.


2

Как следствие ответа Аллана (что ваше собственное время разработчика - самый ценный ресурс): используйте то, что уже сделали другие. Вы говорите, что хотите разработать библиотеку для вычислительной механики континуума, но уже есть несколько таких больших, что почти всегда они будут иметь все, что вам нужно. Посмотрите на deal.II, например, для всего, что может быть записано как задача с конечными элементами, OpenFOAM для динамики жидкости или PyCLAW / CLAWPACK для гиперболических задач. deal.II, например, просит вас программировать на C ++, но на самом деле уровень программирования часто настолько высок, что можно сказать, что он похож на предметно-ориентированный язык для кодов FEM, использующих синтаксис C ++.


2
Я никогда не сталкивался с библиотекой, в которой было бы все, что мне было нужно ...
Джек Полсон,

Хорошо, но вы понимаете, я полагаю. В некоторых библиотеках есть «почти все», что вам может понадобиться. Просто приведу пример, с которым я особенно хорошо знаком, - конечный элемент решателя на полностью самоадаптирующихся трехмерных сетках, работающих на 10000+ процессорах с использованием кодов deal.II и PETSc 126. Это явно больше нуля, но на самом деле это очень мало, учитывая сложность того, что находится под капотом.
Вольфганг Бангерт

Чтобы сыграть в защиту дьявола, тривиально запустить код на 10000 ядер, но это совершенно другой вопрос - сделать его масштабируемым. Немногие параллельные предварительные преобразователи для неэллиптических уравнений могут даже эффективно работать на 300 ядрах.
Джек Полсон

Конечно. Но пример, который я привожу, является масштабируемым: math.tamu.edu/~bangerth/publications/2010-distributed.pdf .
Вольфганг Бангерт

В интересах полного раскрытия информации: я являюсь одним из авторов статьи и приведенного выше кода, а также библиотеки deal.II в целом.
Вольфганг Бангерт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.