Симуляция жидкости, газа

Не понятно почему закон Бернули стирилизован так. Вообще давление на самом деле больше в тех объёмах, на противоположных границах которого двжение происходит в противоположных направлениях. Разве так не проще описывать процесс? Просто столкнулся с тем, что алгоритм симулятора жидкости или газа - вещь достаточно не простая, и самое первое что при осмысление оного приходит в голову - стирилиованность закона Бернули. Скорости движения - это какая то упрощённая схема...по ней ничего не сделать толком применимого.
Вообще сначала думал что всё не так сложно, пока думал что можно ограничиться законом Бернули, но потом понял что на нём одном - ничего не сделать.

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

0

В общем тут всё не просто : пока всё не запланируешь и не предусмотришь - тело цикла писать не начинать.

0

За этим решением Симуляция жидкости, газа сразу вставал вопрос - как быть, завести массив - ёмко по ресурсам, пересчитывать - по времени. решение не сложное.
Условие: это
плюс то, что аналогично с сосоедством ячеек по вертикали. Сначала я думал, что прийдётся заводить массив или много считать. Нейронка ответила ветиевато и уклончиво. Тогда было решено сделать так: для расчёта соседства по вертикали достачно запоминать всего одну ячейку, а одну расчитывать (для крайних две), и так двигаться по справа налево. А для горизонтального соседства достаточно запоминать всю линию массива, но не весь массив. И тогда ускорится расчёт и сэкономится ресурс памяти.
Ответ LM был таким

вопрос - Привет. Ответь на вопрос. Пишется симулятор жидкости. Встаёт вопрос - завести дополнительный массив или сделать число повтор одного и того-же вычисления. Существует формула чтобы определить как поступить? ответ - Вопрос о том, использовать дополнительный массив или пересчитывать значения на каждом шаге, зависит от многих факторов, включая размер данных, частоту использования этих значений, доступную память и требования к производительности. Однако есть несколько общих рекомендаций и методологий, которые могут помочь вам принять решение. 1. **Оценка затрат ресурсов:** - **Память:** Дополнительный массив потребует дополнительной памяти для хранения данных. - **Производительность CPU/GPU:** Пересчет может быть дорогостоящим в терминах производительности, особенно если вычисления сложные или выполняются многократно. 2. **Частота использования значений:** - Если значения используются редко и пересчитывать их не слишком затратно, лучше пересчитать их на каждом шаге. - Если они используются часто, хранение в массиве может быть более эффективным. 3. **Размер данных:** - Для больших объемов данных использование дополнительного массива может стать проблемой из-за ограничений по памяти. - Для небольших объемов данных вы можете позволить себе использовать дополнительные массивы без значительных последствий. 4. **Формулы и методологии:** - В некоторых случаях можно применять кэширование результатов вычислений для оптимизации производительности. - Можно провести профилирование кода, чтобы точно определить наиболее узкие места и оптимизировать именно их. В общем случае нет "волшебной формулы", которая могла бы решить этот вопрос однозначно. Вам потреб

. Далее я не смог это читать и после слова "потреб" остановил генерацию. Изображение к задаче прикрепляю. Решение нашёл сам. В данном случае оно экономит время расчёта немного меньше чем в два раза, и на этом фоне объём памяти на квадрат числа минус (число плюс единица), x^2 -(x+1), где x - длинна стороны квадрата пространства физической симуляции.

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

Миниатюры

 

0

Скелет проекта завершён, далее - "мясо".
https://habr.com/ru/articles/912778/

0

Кстати сравнить по точности с другими стимуляторами можно будет без проблем - через виртуальные датчики движения и давления.

0

сколько не крутил в голове, первая операция, как ни крути, над двумя векторами - плотность потока, скорость вычислять можно только после неё. Трудно определить какую величину взять за первую вычисляемую при операции над векторами. Так выходит, что нечто аналогичное давлению, но не давление - нечто вроде плотности. Имеется ввиду для данной сетки виртуального пространства. Допустим есть два потока движузихся навстречу друг другу под углом 45 градусов к осям координат, скорость по вертикали обоих равна скорости по горизонтали. После столкновения согласно закону сохранения импульса (это не твёрдотельное столкновение и часть масс пойдёт по дуге, а значит без потерь импульса) часть масс увеличит свою скорость, а часть - замедлит, и похоже тут можно включать одну геометрию (вязкость и прочее уже потом подключать к расчётам). Сумма модулей импульсов изменится не должна, часть масс может, и она ускорится обязательно только за счёт того, что часть масс - замедлится. А как это уже будет происходить, для данной сетки пространства можно рассчитывать только геометрическим путём. Физика - она ведь в геометрических площадях вся вроде как. Значит через геометрические площади пространства и решать.

0

Похоже, что всё будет немного проще в отношении такой величины как давление. Долго ломал голову, и вот к какой механике пришёл.
Взависимости от разницы длинны вектора А и Б ячеек виртуального пространства среды - на соседние ячейки промежуточного пространства будут накладываться направления векторов (C и C1). Данная механика всключает в себя: эжекцию ( разумеется это в изменённом виде, и насколько точном - пока не известно) и рассеивание. Два скриншота прилагаю. Да - много времени потрачено, и скажу, что на самом деле очень тяжело приходить к решениям, которых никогда не видел, хоть в массах бытует мнение : да что там такого - взял и навыдумывал. Ну-ну, вот они наверное уже много "полезного" и "применимого" навыдумывали, что так размышляют. Пока что я рассматривал упрощённые направления векторов, но похоже теперь пришло время большей детализации механики. Я пока не рассматривал никаких формул, мне нужно было адаптировать явление эжжекции и рассеивания потока под механику взаимодействия данных массивов. Вроде как получается. Решение похоже на решение "в лоб" в принципе, но сначала было только под эжекцию, и потом после некоторого ступора было решено взависимости от длин векторов менять углы других векторов. Пока это на вскидку, но похоже что теперь перейду к экспериментам.

Миниатюры

   

0

Хотя возможно, что примерно такой алгоритм применим и к стандартным массивам, но я не рассматривал.

0

В общем да - у меня вовсе не вектора. У меня вся механика получается на расчете силы потока и направления действия. Математическая база, по работе с направлениями, для этого мной была разработана ранее https://www.cyberforum.ru/blog... 10143.html , плюс будет алгоритм обрабатывающий некоторые нужные детали по работе с направлением действия.

0

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

Изображения

 

0

Ну а для твердотельного физического объекта параметры следующие - нормаль поверхности и вектор движения, разумеется при условии, что поверхность эта объекта - пластина идеально твёрдая и с бесконечно малой толщиной. С этой точки сдвинулся. Может и раньше смог-бы, но времени очень мало можно потратить на проект. Разумеется, что сама ячейка межпространственного массива будет оставаться неподвижной, но вектор движения пластины будет содержать.

0

Про входящий и исходящий поток ячейки вроде как было не правильно, там просто надо проверить равенство длинны вектора входящего и исходящего потока, если равны - условия соблюдены.

0

Поиск методы должен когда-то остановиться. С векторами работать проще, всё-же. Жаль, но это факт, там оказывается вполне себе можно успешно избегать извлечения квадратных корней. Печально, но факт : сила в виртуальном пространстве абстракция, а оси массивов - реальность. От системы пространств почти не отказался, за исключением момента того, что ячейка межпространственного массива будет содержать плавающую точку на сетке координат и вектор, пластины не будет. Плавающая точка будет одна - так или иначе основной поток он всегда один. С лучами работать можно, но когда система частиц. Несовместимое - несовместимо, если сетка - то вектора, если частицы - то лучи, и опять - для нахождения их пересечений нужна сетка. То-есть с лучами провал. В виртуальном пространстве - виртуальные законы, реальные не действуют, точнее - их туда не пропихнуть не потеряв в ресурсах.

0

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

0

межпространственный массив - это ничего особого, на самом деле он уплотняет сетку только на столько, как я несколько увеличил-бы основной, но хлопот с ним возникает намного больше, и самое главное - он мешает осуществлять расчёт чисто по системе лучей, так как овзникает необходимость инвертирования их в вектора и обратно. Поэтому - сетка стандартная, просто в ячейку самой дальней вершины будет записываться значение силы делённое на 1.41421356237 , на квадратный корень из двух, ну или умножаться на 0,707106781 (просто подумал - всё логично, остаточное значение прийдёт на второй итерации). А проблема перекоса скорости распространения устраняется элементарно и уже была озвучена - "баланс ячейки - входящий в ячейку поток должен быть равен исходящему (небольшие правила рассеивания и фокуса+, и это тоже нигде не овучено - хочешь симулятор - на тебе уравнения, будешь послушным - поясним что дописать ещё). Везде пишут про уравнения Ксавье, поэтому было трудно так сразу сориентироваться что делать с разницею в дистанций между вершинами. Нет смысла никакого наклонять сетку - это только усложнит работу, а так - межпространство это тот же наклон обычной сетки ровно на 45 градусов. Но система будет лучевая. Дело в том, что пятая вершина в центре вынуждала к более сложной обработке, с конвертацией лучей в вектора и обратно. Это слишком сложно и не профитно, поэтому от этого бреда с пятой вершиной в центре квадрата образованного четырьмя - пришлось отказаться и думаю больше к этому не возвращаться.

0

Правило номер один - любое действие, даже если оно постоянно - действие, вызывающее изменения в комплексе, даже когда этот комплекс полностью их гасит, потому что гасить он их может только в процессе событий. Без этого попытка написания превращается в процесс угадывания. И учёт этого правило даёт понимание того, как уже будет работать сам движок, от А до Я. В сбалансированной системе, действующая сила - изменяющая.
Далее были размышления над алгоритмами циклической обработки, что было придумано из вариантов (был вариант упрощённого массива, или несколкьих упрощённых, ну типа отдельных поддоменов, но он мне не понравился по своей идее). Начинать с места приложения силы и заводить для каждой ячейки "момент" поиска, когда она на следующей итерации была проверена следом за проверенной на предыдущей итерации соседней, осуществляемого по телу всего массива без исключения по простому алгоритму от нуля и до окончания массива, и момент контакта с проверенной на предыдущей итерации. То есть на обнулённом поле появляется вдруг вектор силы (или изменение вектора) , спереди от его направления находится ячейка в которую должен записаться изменённый вектор и сзади тоже (рядом то уже мелочи), проводить поиск кротчайшего пути на фоне симуляции жидкости или газа, для начала расчёта изменений, на мой взгляд показалось глупо, и мне видится, что циклическая обработка не должна ломаться никакими волновыми алгоритмами, цикл будет повторяться вновь и вновь над всем ячейками пространства, и при проверке каждой будет установлен номер итерации, где получится что 1-самая старшая, а самая последняя как найдётся кротчайший путь, причём, кротчайшие пути можно искать из прохода в проход, устанваливая для них степень краткости.

Идею поддоменов я отмёл, хотя это весьма распространённый приём решения подобных задач, волновой алгоритм "отправился" вслед поддоменам, он не достаточен - тут нужно вести журналы и моментах (итерациях) поиска пути и моментах контакта потоков. Все эти задачи мне пришлось решать бы и с векторами, причём то, что я их не использую - на решения поиска кротчайших путей потока - не влияет никак, я выбрал одно из них согласно исключительно своим соображениям. Моё правило простое - не идеализировать и не уподобляться, всюду искать естественное для среды исполнения решение.

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

Далее согласно этой идее вырисовывается уже сам алгоритм обработки этих журналов - там где уже записан момент итераций и контактов - можно исключать из обработки, сужая поиск естественным путём, где старт будет вестись с обработки пространства симулции, а с некоторой итерации - поиск будет осуществляться исходя из журналов. Так будет достаточно быстро, чтобы тягаться с любыми известными аналогами, которые, согласно логике, должны уступить на векторной обработке перед обработкой ориентиров приложения и сил.

0

Невероятно сложная задача. Чтобы ей заниматься с нуля (начиная с методов - не брать ничей, а создавать свой) нужно очень много пересмотреть и осмыслить, но я попробую всё же. Отступаться вообще не охота. К тому же с ориентирами получается не плохо, но вот организация итераций процессов реально выносит мозг.
Считать можно хоть боком хоть с прискоком - вообще без разницы, хоть по Бойлю, хоть по Мариоту, а вот организовать циклы, чтобы фиксировать все утечки остающиеся движения - вот это действительно выносит мозг.

0

Пока откладываю работу над симулятором, так как надо усиленно учить другой материал. Вообще суть проблемы ясна, на FPGA это решается намного проще, в плане выбора алгоритма и организации циклов, а вот на стандартных архитектурах это всё едва подьемно, возможно прийдется купить Аврору от говин и решать на ней или с её использованием, но пока откладываю.

0

Решил возобновить.

0

Просто когда-то, я назвал кинетическую энергию замкнутой, а вот ИИ назвал её внутренней. И тут уже как-бы становится всё понятно, что и как.
А вот обзор от ИИ

Термин «внутренняя энергия» принадлежит У. Ренкину, который ввел его примерно в 1853 году.

Этого я не знал. Как-то говорил на одном портале что её стоит называть замкнутой, но засмеяли, или хотели высмеять, но про внутреннюю никто ничего не сказал.

0

И, как назвал мной оговариаваемое ИИ "среднее циклическое". Результирующий угол расчитывать от среднего математического (degree
degree= (degree1*F1+degree2*F2)/(F1+F2) (это вот это он назвал среднее циклическое, но там есть небольшая вставка на предмет проверки когда разница углов больше 180 градусов, чтобы правильно считать среднее математическое значение углов), а что касается вычесления суммы модулей сил, то F=F1+F2*cos(degree of deviation), косинус брать из таблицы длинной 360, НО, ЕСЛИ направление без отклонений то модули тоже должны быть средним математическим то-есть сумму скорости (сил) - нужно дорабатывать.... Что касается давления, то разницу между двумя ячейками расчитывать от разницы сил инерции между ними. То-есть откуда шёл - туда и пришёл (это что касается физики), но расчёт уже не по векторной системе (что касается математики). Если брать вектора...то как мне кажется расчёт усложняется, но пока не проверял, тут ещё дорабатывать.

0