Как стать автором
Обновить

Комментарии 30

И под конец небольшой бонус — несколько красивых скриншотов, снятых в программе
а гифок/коротких видео снятых в программе — нет?
Думаю прикреплю в ближайшее время. Скриншоты чуть проще было сделать, поэтому пока только их добавил
Ужас какой-то, ничего не понятно! Почему не применить общепринятую терминологию?
Метод конечных разностей обычный со схемой по потоку первого порядка точности. Элементарные жидкие объемы названы какими-то частицами. Это Эйлеров подход, мы следим за параметрами точек в пространцстве мы не следим ни за какими частицами!
Замыкание уравнений очень странное, я очень рад за теорему Гельмгольца но это нифига не физично.
Граничные условия… это вообще что за хрень. Почему у вас дивергенцией названо среднее между двумя пристенными ячейками? Нафига дивиргенция? Вы уж либо условие прилипания поставьте, либо мягкие граничные условия второго рода, если хотите, чтобы все втекало и вытекало свободно.
Ужасный стиль.

Возможно, потому, что подобным стилем изложена статья (сильно повлиявшая на данную).

Яяяясно, ну в оригинале понятнее написано.
это и есть общепринятая терминология в контексте жидкостей в компьютерной графике) Метод не эйлеров, а полулагранжевый (semi-lagrangian), виртуальные частицы трекаются из вокселей назад во времени. Но соглашусь, оригинальные статьи из gpu gems нвидиевских очень плохи и крайне сумбурны, ещё и с ошибками когда я последний раз туда смотрел
Зачем они вообще нужны эти частицы, если значения скоростей хранятся в центрах ячеек? Я вообще в осадок выпал от их заявления, а давайте вязкость называть диффузией импульса. О_о Я бы ещё мог понять диссипацию, но диффузию.

Они не создаются в явном виде, а сам метод нужен для стабильного решения с любым сколь угодно большим шагом по времени. У конечно-разгстных схем cfl ниже единицы почти везде, что очень печально для скорости. Оригинальный папер по этому методу:
https://www.researchgate.net/publication/2486965_Stable_Fluids

Что-то я не догнал, как эти частицы используются потом. DPM какой-то?

Никак. Из центра ячеек виртуальные частицы назад во времени трассируются, затем в месте «приземления» линейной интерполяцией по окружающим ячейкам забирается значение (скорости и остальных полей).

Аааа, ясно, господи, ужас какой. А по пути частиц никаких источников, стоков, нихера? Ну да, это такой кастрированый DPM на конечноразностной схеме.

Ну здесь же есть и прелесть. Сколько бы ни было стоков и источников, у нас фиксированный объем вычислений. А симулировать их можно давлением и применяемой силой, насколько я понимаю. Так как у нас есть краситель — источник будет окрашивать какую-то область цветом, который будет со временем утекать.

Не не не, вы не поняли. Вот у нас допустим огромная скорость, надо считать в реальном времени с большим шагом по времени. Число Куранта будет очень большое, трассировка частицы будет через кучу ячеек, и она будет генерировать источники вокруг себя там где оказалась. В нескольких десятках ячеек от того места где считались её параметры. Не очень красиво.
На случай, если не встречали, есть шейдер с похожими результатами на ShaderToy:
Картинка
image

И похоже у автора тот же подход к решению)
Вообще, мне очень нравится эта игрушка: paveldogreat.github.io/WebGL-Fluid-Simulation. Там используется чуть больше пост-эффектов, но в итоге можно очень надолго залипнуть
Спасибо за интересную статью! Надеюсь, что будут выложены анимации работы алгоритма. Также хотелось бы увидеть результаты для 3D-модели. Скриншоты получились довольно красивыми, но реалистичности немного не хватает. Я бы сказал, что реалистичность на 8 из 10 (Только это ни в коем случае не претензия к автору стать). С чем это может быть связано сложно сказать. Мне кажется, что нужно взять более крупную модель сетки. У вас как я понял схема «креста». А что если взять еще несколько соседних точек и учитывать их влияние? Можно еще поэкспериментировать с шагом dx и dy.
На точность больше всего влияет количество итераций для давления и вязкости. Но при их увеличении линейно падает скорость работы алгоритма. Размер сетки также влияет, так что тут нужен некий баланс между производительностью, качеством и красотой. В оригинальном варианте все вычисления проводятся на шейдерах, и это бесспорно эффективней, учитывая что у Cuda если API для работы с OpenGL. Но для статьи решил выбрать более простой и понятный способ
на мой взгляд сильнее всего влияет слишком большой cfl, который нужно сильно уменьшать хотя бы до 2-3, ну и итерации на солвере давления конечно тоже делают свой вклад. вязкость наоборот блюрит детализацию, я бы отключал её вовсе.
CFL это по русски число Куранта. Отключите вязкость — получите Стоксово течение без каких либо потерь устойчивости (никаких дорожек Кармана).
Вох, фу, тысячелетней проблемой меньше. Можно еще в этом отношении gpiv попробовать =/
НЛО прилетело и опубликовало эту надпись здесь
случайно нету заготовок для уравнений Пуассона?
какого плана заготовки интересуют? тут например достаточно читабельные исходники для решения слау из пуассона сопряженным градиентом:
wavelet turbulence
Интересная ссылка.

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

Задача касается дробных эффектов, которые возникают изза того, что присутствует фоновая радиация.
Задача не описана, конечно. Но если хочется то можно OpenFOAM или можно что-нибудь из комерческого типа Fluent.
Смысл задачи в том, что есть фоновое излучение, которое создает свободные электроны. Плотность примерно 10 000 шт на кубический см. При приложении поля они разгоняются и создают электронные лавины. То есть сначала один электрон попрождает 2. Далее 2 попрождают 4,… 4 порождают 8 и тд по экспоненте с оговорками.

Их нельзя учитывать усреднено, как просто сплошную среду, так как есть экспоненциальные зависимости. Нужно учитывать эти электроны поштучно. Если есть какая-то открытая готовая модель газового разряда, которую можно дописать, чтобы учитывать дробные эффекты, то было бы хорошо.

Писать все нуля не охота, так как нужно очень хорошо разбираться в этих расчетах. Частично задача решается через теорию перколяции, без диф-уравнений. Более честно было бы решить её через решение уравнений Пуассона с поштучным учетом частиц.

Охрененная работа, огромное спасибо!


А есть аналогичная восхитительная имплементация для 3D?

Есть планы написать про SPH для 3D случая, однако самый простой способ — взять текущий код и расширить его для трёхмерного случая, код kernel.cu практически не поменяется. Также у Nvidia есть соответствующая статья: https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch30.html

мне этого в обозримом будущем самому не поднять так, чтобы быть уверенным в своём коде ((

я не могу найти подобные готовые имплементации на github.com или bitbucket.com, к сожалению. Было бы чудесно, если бы вы смогли выложить в открытый доступ подобный проект на одной из этих открытых платформ.
У Вас ошибка интерпретации членов УНС — частная производная скорости по времени \frac{\partial\vec{v}}{\partial t}, что стоит слева от знака равенства, это не ускорение, а скорость изменения скорости в фиксированной точке пространства — частная производная же.
А вот если Вы конвективный член (\vec{v}\cdot\nabla)\vec{v}, что стоит с минусом сразу справа от знака равенства, перенесете в левую часть, она как раз и даст ускорение — полную производную скороcти по времени.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.