Да мы его подкрутили и добавили метод, который позволяет ввести автоматическое ограничение интегральной составляющей путем его однократного вызова из setup
Ну для этого я и поделился нашим опытом, что бы если у кого-то будет нужда сделать такое при ограниченных средствах временные затраты снизились бы.
По времени 2 недели заняло и не с утра до вечера
Да, можно на всякий случай. Но в нашем случае подразумевается что система всегда работает в присутствии человека и "цена" зависания невысока. Клапан вряд-ли откроется на полную т.к. для этого зависший контроллер должен подать на него высокий сигнал. Залипнуть в каком то положении может, да
Во-первых точность не достаточная, во-вторых давление в системе и расходы могут плавать (как показано на последнем рисунке) а нужно поддерживать постоянный расход в течении определенного времени.
Пожаробезопасность обеспечивается герметичностью системы, которая связана с используемыми соединениями. Мы используем быстросъемные, они нас устраивают, хотя работаем с горючими газами но с вытяжкой, непродолжительные пуски и т.д. Можно выбрать более суровые соединения.
Спасибо за советы! Конденсатор пробовали ставить но как оценить его эффект не понятно. На звук или нагрев клапана заметно не влияет. Диод ставим, просто на фото и схеме нет. Схему поправил.
На данном этапе измеритель расхода не тарировали. Для тарировки обычно используем барабанный или пузырьковый расходомер на больших и малых расходах, соответственно.
Должен добавить, что т.к. константная память более быстрая, то после изменения кода в соответствии с Вашим комментарием отношение PyCuda/CudaC стало не более 2-2.5%
Преимущество неявной схемы заключается не в меньшем значении N, потому что N пространственное разрешение сетки и соответственно задает точность (грубо говоря) решения, а в возможности снять ограничение на шаг по времени. Поэтому, что бы просчитать одинаковые времена НРС требует сделать меньше временных шагов, однако при этом число операций на шаг больше. Выбор ЯРС для тестовой задачи был связан с тем, какую реальную задачу мы собирались решать, т.к. мы хотели смоделировать те условия которые будут там. Так вот, в этих задачах есть сильно нелинейные члены и как показали предыдущие сравнения сильно увеличить шаг по времени с использованием НРС не удается и большее количество операций, требующихся на обращения матриц, не окупается.
Вы правы в том, что для других задач НРС — хороший выход и конечно мы будем сравнивать производительность операций с разреженными матрицами в дальнейшем и по мере необходимости
К сожалению я не нашел способа как в PyCUDA передать переменные через константную память и поэтому использовал такой способ. Буду очень благодарен если кто-нибудь покажет как это сделать.
Должен согласится с Вашими утверждениями, однако, меня интересовало сравнение времени выполнения для задач и сеток характерных для практических задач, которые мне уже доводилось или предстоит решать. В этих задачах я не использую ни очень большие (N>=16384) ни очень маленькие (N<256) сетки. Что касается параллельной реализации на CPU, я проводил тесты с использованием MPI и получал прирост скорости (CPU 4 ядра)/GPU порядка 35-40 раз на интересующих меня сетках. По поводу энергопотребления, это конечно тоже важно, но за свет платим не мы (хотя я понимаю значение этого фактора для экологии). Вообще детальное сравнение CPU vs. GPU тема для отдельной статьи и таких статей можно найти достаточно много, в этой статье я лишь упомянул один результат не претендуя на сколько-нибудь детальное сравнение
После исследования производительности, представленного в статье именно такой вывод я для себя и сделал. Однако изначально результат для меня был не очевиден. Во-первых, я не был уверен что на питоне мне удастся настолько приблизится к C. Во-вторых, была надежда, что если это возможно, то и Numba позволит получить приемлемое время по отношению к C
По трудозатратам на мой взгляд питон менее трудозаиратен, но вообще все конечно будет зависеть от конкретных задач. Мне полученные результаты дали ориентир.
Мое чисто субъективное мнение состоит в том, что для расчетов занимающих время в пределах 1-10-30 минут на один кейс Numba с одномерными массивами мне подойдет т.к. время на разработку, а также анализ результатов и т.п. нивелирует несколько большее время расчетов. Для расчетов занимающих часы я бы уже использовал PyCUDA или C. Поэтому для ближайшей задачи — PyCUDA.
Да, только нам корпуса, климатическое исполнение и т.п. не нужны. Мы же не продавать собираемся. Для многих целей это не нужно.
Статьи на Хабре в качестве отчёта никому не нужны. Цель в том, что бы помочь тем кому это может пригодиться.
Да мы его подкрутили и добавили метод, который позволяет ввести автоматическое ограничение интегральной составляющей путем его однократного вызова из setup
Сейчас никаких защит нет. У нас система всегда работает в присутствии человека. Он и защищает
Ну для этого я и поделился нашим опытом, что бы если у кого-то будет нужда сделать такое при ограниченных средствах временные затраты снизились бы.
По времени 2 недели заняло и не с утра до вечера
Полностью согласен. Были б деньги так и сделали бы)).
Да, можно на всякий случай. Но в нашем случае подразумевается что система всегда работает в присутствии человека и "цена" зависания невысока. Клапан вряд-ли откроется на полную т.к. для этого зависший контроллер должен подать на него высокий сигнал. Залипнуть в каком то положении может, да
Вы правы в том, что для других задач НРС — хороший выход и конечно мы будем сравнивать производительность операций с разреженными матрицами в дальнейшем и по мере необходимости
По трудозатратам на мой взгляд питон менее трудозаиратен, но вообще все конечно будет зависеть от конкретных задач. Мне полученные результаты дали ориентир.