Ракетный софт

pinko> Также есть не только физические процессы, но много промежуточных химических веществ и для это также требует хорошего понимания химии процессов.

Химия процессов уже есть. Всё то, что вычислял PROPEP, теперь возможно будет применить к каждой конкретной точке пространства. Это именно расчёт равновесия. Сие алгоритм я уже начал писать в новой форме.

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

SashaMaks> 1. OpenGL выбор однозначный.

Конечно однозначный, с ним гораздо удобнее пускать пыль в глаза, чем с OpenCL

SashaMaks>> 1. OpenGL выбор однозначный.
umbriel> Конечно однозначный, с ним гораздо удобнее пускать пыль в глаза, чем с OpenCL

Открой глаза, натренеруй внимательность, перестань заниматься троллингом и, главное, научись признавать свои ошибки.

SGRMrocket> В университете у меня была специальность "прикладная математика" и, так получилось, что вся моя кафедра как раз занималась численными методами сплошных сред. Поэтому я и пишу для себя, для удовольствия всякие симуляторы, как на предстваленном выше видео. Сейчас их у меня написано 2 штуки - один для визуализации ракет на с++ с многопоточностью и второй - универсальный симулятор позволяющий можелировать подкрашенный газ, написанный на cuda с расчетом на нескольких видеокартах. Могу предоставить исходные коды (проекты) обоих, если интересно. Собственно началось все с любви к ракетам (а она у меня с детства) - после окончания вуза начал пытаться их делать, и поскольку мое образование позволяло, появилось желание не только делать ракеты, но и с помошью компьютера смоделировать то что я делаю. Точные результаты мне было делать лень и они не представлялись такими интересными, поэтому я все сделал с параметрами "на глаз" - лишь бы было правильно с точки зрения законов сплошных сред и красиво на глаз. Но осталось ощущение что я не раскрыл потенциал тех технологий которыми владею, поэтому и думаю сейчас над применением их для действительно полезных целей.

Что касается внутренней баллистики РДТТ, то обычно симулируют отдельно поток массы и давление в камере сгорания, и отдельно уже само сопло/его разгар/влияние двухфазности и тд.
Такой подход - ОК, потому что никаких бонусов в объединении нет, но зато можно разбить задачу на подзадачи, что очень хорошо.

Пару месяцев назад я делал симулятор (и сейчас, в общем, тоже делаю) камеры сгорания.
Самый простой способ - ограничить знания о КС тем, что она просто имеет некую площадь свода горения и считать, что все что сгорело - все вылетело через сопло.
Это 0-D "стабильная" симуляция, она имеет аналитическое решение, моделировать вообще нечего.

Я же делил КС(канал) на отрезки + считал, что все что сгорело не обязано вылетать через сопло, а может и накапливаться.
Это 1-D "нестабильная" симуляция.
Надеялся, что такая, более сложная модель будет выдавать графики тяги более похожие на то, что получается в реале на стенде, но ошибся.
График тяги растет почти так же как и в 0-D stable (почти моментально), и так же, почти моментально падает в конце (не смотря на то, что из-за разницы давления у сопла топливо догорает чуть медленнее).

Все это из-за твоего пункта (2): я знаю о топливе только его закон горения, пресловутый u = u0 * (p/p0)^b, который, на самом деле, весьма погано описывает реальное топливо.
Кроме этого знаю плотность топлива, состав и температуру продуктов сгорания.
Но не знаю ни скорость распространения горящей поверхности на старте, ни то, как быстро меняется скорость горения при резкой смене давления, ни того, в какой момент возникает эрозионное горение и каков, грубо говоря, его закон.

Возможно, если перейти к 3-D, то последние два пункта можно победить, т.к. если копнуть дальше, то скорость горения зависит вообще-то не от самого давления, а от температуры горящей поверхности, от потока энергии. Т.е. еще и от турбулентности, о которой 1-D ничего не знает.
Скорость распространения горящей поверхности можно измерить как-то непосредственно, а потом прикрутить какую-нибудь теорию. График тяги станет похожим.
Но в любом случае, пока этих "глубинных" данных нет, особого смысла в более точной симуляции нет: результат будет не сильно отличаться от 0D.

По поводу пункта (1) и быстродействия: обычно камеру делят на симметричные дольки, считают в них и экстраполируют результат. Лучше начинать просто с CPU, а то как говаривал a_centaurus "широко шагаешь - порвешь штаны"

Пункт (3) - STL, например, очень простой. Или просто одну модель + настроечки, как во всех этих астрокадах. Или вот, обрати внимание, это язык описания: OpenSCAD - The Programmers Solid 3D CAD Modeller
Лично я собираюсь генерить геометрию шашки аналитически, и было бы удобно, чтобы одна прога другой проге не передавала временный большущий STL-файл.
А пока лучше генерить геометрию прямо из c++ (см. предыдущий пункт про штаны)

Пункт (4) - вывод очень простой: нужен график потока массы + график давления в КС. Больше ничего не нужно, даже красивых картиночек.

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

PS Жалко, что ты не из Питера.

SGRMrocket> SashaMaks
SGRMrocket> Я всетаки веду речь про OpenCl, а не про OpenGl (просто уточняю на всякий случай). OpenGl в данной задаче ни к чему. Поразмыслив над технологиями реализации, я считаю что остановиться стоит именно на OpenCl, так как придется производить огромное кол-во вычислений и при этом желательно сохранить универсальность кода для разных устройств.

Насколько мне известно, OpenCL - это всего лишь дополнение для OpenGL. Сделанное с целью использования по максимуму ресурсов современных GPU (многопотоковость, универсальность и тд.)

Вся основа OpenCL - это тот же OpenGL. Вся трёхмерка идёт из OpenGL.
Что касается вопросов универсальности и совместимости кода, то только, например, версия OpenGL1.6 позволит использовать компьютеры до 2000-2002 года выпуска. А такие, кстати, ещё остались во многих офисах)))
А вот OpenGL версии 4.0 и выше позволит использовать программу уже только на компьютерах где-то от 2010 года выпуска.

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

Про технологию CUDA я наслышан, что она позволяет использовать ряд аппаратных функций GPU, применительно уже не к графическим расчётам, а к физическим.

У тебя есть конкретные примеры данных функций?

Ну, например, как в графике OpenGL функция glrotate?
Она преобразует пространство при вращении, но её данные не возможно использовать в CPU, поэтому ядро симулятора своим кодом на CPU делает расчёт независимо для базового вектора и отправляет полученные данные на GPU, где уже просто рисуется всё векторное множестве, которое является просто картинкой, в точности повторяющей преобразование поворота базового вектора. Если код для CPU написан верно, то графика в GPU совпадает и это даёт возможность проверки. Но я не могу получить данные о преобразовании координат пространства при вращении в GPU, я их могу только просто видеть на мониторе, а в оперативку они не поступают, так как мои переменные в CPU, описывающие вектора, GPU просто не поймет по понятным причинам.

SashaMaks> Насколько мне известно, OpenCL - это всего лишь дополнение для OpenGL.

Нет, это то, что продвигается AMD (бывшим ATi), как платформенно-независимый стандарт, в противовес нвидиевскому CUDA. Именно, как стандарт вычислений общего назначения на видеопроцессорах (независимо от их архитектуры). CUDA предназначен для того же самого, но крепко завязан на чипы NVidia.

SashaMaks> Вся основа OpenCL - это тот же OpenGL.

Да ни разу сходства примерно столько же, сколько между Си и Паскалем.

SashaMaks> Вся трёхмерка идёт из OpenGL.

Там обычно не о трёхмерке идёт речь, т.е. компонентов у вектора не три, а 128 или типа того

SashaMaks> Про технологию CUDA я наслышан, что она позволяет использовать ряд аппаратных функций GPU, применительно уже не к графическим расчётам, а к физическим.

Вот OpenCL форсится, потому что он якобы удобнее для программиста, чем CUDA, а, главное, работает независимо от типа видеоадаптера. Т.е. на последних интеловских "встроенных в процессор" видеочипах его тоже можно использовать.

Б.г.> Именно, как стандарт вычислений общего назначения на видеопроцессорах.

Каких именно вычислений?

> Вся основа OpenCL - это тот же OpenGL.
Б.г.> Да ни разу сходства примерно столько же, сколько между Си и Паскалем.

Я не о сходстве писал, а дополнении и расширении функционала OpenGL. Без OpenGL там всё равно не обойтись.

Б.г.> Там обычно не о трёхмерке идёт речь

А о чём там идёт речь?

Б.г.>> Именно, как стандарт вычислений общего назначения на видеопроцессорах.
SashaMaks> Каких именно вычислений?

Это уж у кого что болит Наилучшие достижения - в быстром преобразовании Фурье и умножении плотных матриц больших размерностей. Линпак (точнее, нынешняя его версия) хорошо ложится на OpenCL

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

Б.г.> Наилучшие достижения - в быстром преобразовании Фурье и умножении плотных матриц больших размерностей.

А где примеры этих команд?

Б.г.> Ну я ж пишу - 128-мерные вычисления (векторы со 128 компонентами).

Попробую по-другому спросить. Что за программа у нас получится и что она сможет делать, если в ней будет только OpenCL?

SashaMaks> А где примеры этих команд?

Б.г.>> Ну я ж пишу - 128-мерные вычисления (векторы со 128 компонентами).
SashaMaks> Попробую по-другому спросить. Что за программа у нас получится и что она сможет делать, если в ней будет только OpenCL?

Поиск следующего числа Мерсенна, прогноз погоды, поиск транзитов экзопланет в сырых данных телескопа "Кеплер", да много всяких применений, не связанных с трёхмерной графикой.
У OpenCL некоторые сложности с файловым вводом-выводом, поэтому, насколько я понимаю, программа строится из модулей, написаных в OpenCl и в более традиционных Фреймворках.

SashaMaks>> А где примеры этих команд?
Б.г.> clFFT: OpenCL Fast Fourier Transforms (FFT's)

Я думал, ты сам расскажешь...

Б.г.> да много всяких применений, не связанных с трёхмерной графикой.

Т.е. трехмерная графика не нужна? А как же?
"Поскольку мы будем моделировать в 3d"


Как же тогда вводить данные? Моделировать двигатель, ракету? Картинками?

SashaMaks>>> А где примеры этих команд?
Б.г.>> clFFT: OpenCL Fast Fourier Transforms (FFT's)
SashaMaks> Я думал, ты сам расскажешь...

Я сам в OpenCL не программирую, только пользуюсь чужими программами, поэтому мне рассказать - это с чужих слов.

Б.г.>> да много всяких применений, не связанных с трёхмерной графикой.
SashaMaks> Т.е. трехмерная графика не нужна? А как же?
Трёхмерная графика не нужна, потому что бессильна.

Когда ты моделируешь, например, возникновение ВЧ колебаний возле форсуночной головки, то ты должен как-то визуализировать колебания плотности, но тогда сквозь них не видно ударные волны, которые должны предотвращать их распространение. А "полупрозрачная" картинка получается недостаточно информативной.

SashaMaks> "Поскольку мы будем моделировать в 3d"
SashaMaks> Ракетный софт [SGRMrocket#19.08.15 16:57]
SashaMaks> Как же тогда вводить данные? Моделировать двигатель, ракету? Картинками?

OpenCL - это не надстройка над OpenGL, это вычислительная среда, которой всё равно, что вычислять. Результаты вычислений, возможно, будут представлены в виде трёхмерной графики, а, возможно, не будут (будут представлены в каком-то другом виде), а, даже если в виде трёхмерной графики, возможно, удобнее будет пользоваться DirectX 11, с ним у OpenCL большее сродство, чем с OpenGL.

Смысл OpenCL в том, чтобы спрятать от программиста реальное железо видеопроцессора, на котором будут идти его вычисления. Это и плохо, и хорошо. Хорошо потому, что можно писать программу, как и для OpenGL, не заботясь, на чём она будет исполняться. Плохо потому, что при этом пиковой производительности на конкретном железе (а пока Nvidia по числу инсталлированных для вычислений графических чипов опережает AMD на порядок) достичь сложно. Поэтому те, кому реально нужно выжать максимум, пишут на CUDA, а OpenCL используют постольку, поскольку его форсит АМД и Интел (и ещё, говорят злые языки, Apple).

Б.г.> Результаты вычислений, возможно, будут представлены в виде трёхмерной графики, а, возможно, не будут

Я, понял так, что было желание уйти от 2D в пользу 3D. Но если в 2D копаться привычней, то тогда я пошёл со "своим" OpenGL от сюда... Тем более, что DirectX 11 вам ближе.

Принцип: "Всё, что делаю я, либо неправильно, либо ерунда, либо никому не нужная фигня".
У меня возник ещё один вопрос: А тебе нужны вообще мои расчёты в 3D на OpenGL для ваших полётов? Может я тут зря всё это делаю? У вас OpenCL, поди уже всё давно посчитали?

Skyangel>

Толи магнитная буря
(Магнитные бури)
Толи xep знает что.
С саморазгоном, как в атомной бомбе.
Печально, в общем-то.

Skyangel>

Не угадал. Скорее растерянность от неопределенности.

Skyangel>>
Xan> Толи магнитная буря
Xan> (Магнитные бури)
Xan> Толи xep знает что.
Xan> С саморазгоном, как в атомной бомбе.
Xan> Печально, в общем-то.

Тоже всё мимо.
1. У меня сегодня свободный день.
2. Я переработал конструкцию стабилизаторов.
3. Нашёл способ как увеличить консоль стабилизаторов без потери в жесткости и увеличения миделя.
4. Сделал новые чертежи стабилизаторов.
5. Проверил расчёты по устойчивости.
6. Нашёл ошибку касательно удлиненного корпуса.
7. Обжёг сопло.
8. Сегодня будут собраны все сегменты двигателя для его заправки - это ещё в процессе.

Но тебе не понять.

Skyangel>>
SashaMaks> Не угадал. Скорее растерянность от неопределенности.

Саша, я тебе про Фому, а ты мне про Ерёму.
Я тебе объясняю, что между OpenGL и OpenCL нет никакой связи, за исключением железа, на котором оно исполняется. Тебя вводят в заблуждение похожие буквочки в названии.
OpenCL может применяться независимо от OpenGL, потому что это не надстройка, как ты некоторое время назад написал. Это совершенно отдельный язык (точнее, среда) программирования видеочипов, как вычислительных средств. Вычислительных, понимаешь? Видеочип используется, как векторный математический сопроцессор.
Причём, что интересно, пиковая их производительность достигается не на 3D графике, а на вычислениях над векторами с большими размерностями. Координаты точки - это вектор с размерностью три, координаты твёрдого тела - вектор размерностью шесть (три линейных и три угла).
Максимум же производительности достигается на векторах и матрицах большей размерности, начиная от 64, и дальше - в зависимости от архитектуры чипа.
Дело не в том, что мы хотим или не хотим.
Дело в том, что сейчас даже суперкомпьютеры используют видеочипы, наряду с традиционными процессорными ядрами, и софт для написания программ под них порождает стандарты пачками, и кому-то в голову пришла дурная мысль - "а назовём-ка мы новую среду похоже на то, что использовалось раньше на три дэ ускорителях, глядишь, программисты решат, что им это привычнее, и побегут к нам".
"И вот вам результат." ©

Б.г.> Саша, я тебе про Фому, а ты мне про Ерёму.

Я от твоей "Фомы" не узнал ничего нового, и никак не могу это прикрепить к делу программному. Просто очередной трёп вокруг да около. Никакой конкретной информации по тому же OpenCL. С большими размерностями и OpenGL работает и API и много чего другого, точнее чипы - железо. Там это не векторы, а просто буферы, уверен, что и в OpenCL - это тоже буферы, а из размерность может быть любой, в зависимости от назначения. Но это совершенно очевидная и потому совершенно бесполезная информация.

Я предложил среду для разработки, а мне в ответ про "пыль в глаза".
Потом и вовсе выяснилось, что OpenGL не нужен.

Б.г.>> Саша, я тебе про Фому, а ты мне про Ерёму.
SashaMaks> Там это не векторы, а просто буферы, уверен, что и в OpenCL - это тоже буферы, а из размерность может быть любой, в зависимости от назначения.
Смысл векторных операций в том, что ты одной командой выполняешь операцию над всеми компонентами вектора СРАЗУ, используя аппаратные возможности чипа. Т.е. умножение 128 пар чисел с получением 128 результатов - одной командой. Так что, нет, это не просто буферы.

Б.г.> Так что, нет, это не просто буферы.

Это просто буфер, причём очень маленький.
Те же команды из ряда modeling, viewing, projection operations, rotation, translation, scaling, reflecting, orthographic projection, perspective projection, преобразует сразу все векторы и не только в один заход с CPU одной командой.

Б.г.>> Так что, нет, это не просто буферы.
SashaMaks> Это просто буфер, причём очень маленький. Та же команда glrotate или gltranslate или glscale, преобразует сразу все векторы в один заход с CPU одной командой.

Что ты несешь? Ты представляешь себе, что твою писанину могут читать профессиональные программисты? Стыдоба

umbriel> Что ты несешь? Ты представляешь себе, что твою писанину могут читать профессиональные программисты? Стыдоба

Поясни, что не так.

SGRMrocket> То что на видео я считал на сетке 1920х1080 методом годунова 2-го порядка. Обсчитывается это на обычном компьютере с многопоточностью со скоростью 1-2 кадра в минуту. Если интересно - могу скинуть эту программу (если нужен могу дать исходный код) она написана на с++ под виндовс.
SGRMrocket> umbriel
SGRMrocket> В университете у меня была специальность "прикладная математика" и, так получилось, что вся моя кафедра как раз занималась численными методами сплошных сред.
...
SGRMrocket> 5) Самое главное - есть ли действительно потребность в подобной программе. Я имею ввиду что одно дело просто разок заглянуть внутрь двигателя ради любопытства и совсем другое дело если подобное приложение действительно поможет ответить на определенные вопросы и даст практическую пользу при разработке двигателей.

SGRMrocket> Собственно главный вопрос для меня - последний, так как одну программу для "просто взглянуть" я уже имею. А хочется принести практическую пользу сообществу.

Привет!
Интересную ты тему поднял.
Аналогичная мысль меня точила давно, но не чуствовал готовности за нее взяться.
(Во времена учебы моделировал температурные колебания в твердом теле методом разностных схем)
Предлагаю рассмотреть такую задачу:
одновременно с расчетом переноса массы и энергии из ячейки в ячейку считать в каждый момент времени для каждой ячейки равновесное термодинамическое и термохимическое состояние.
Для конкретной температуры и давления в этой ячейке. Результат расчета состояния даст химические превращения веществ, соответственно изменится соотношение газообразных, жидких и твердых масс в ячейке.

Что даст корректное решение этой задачи (возможно):
1. можно будет оценить будет/не будет гореть состав. Сейчас можно оценить теоретический импульс топлива в программах типа PROPEP. Но значение импульса и выделение энергии при химических реакциях не дают гарантии , что топливо вообще будет гореть.
2. Можно будет теоретически оценить закон горения топлива (скорость при разных давлениях)
3. Процессы в РДТТ в динамике будут более реалистично рассчитываться.

Для того чтобы оценить корректность подхода можно взять одномерный случай.
В качестве топлива - cорбитовую карамель (35% Sorbitol 65% KNO3)
И сравнить расчет с реальными данными . Закон для сорбитовой карамели неплохо изучен.

Для расчета термодинамического и термохимического равновесия в каждой ячейке можно использовать общедоступную библиотеку cpropep.
Кажется SashaMaks ее использовал для написания программы для расчета свойств топлива - аналога PROPEP.

Если есть интерес к такому подходу - предлагаю тебе создать новую тему с названием проекта и там вести обсуждение.