[image]

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

Тема посвящена программам для расчетов ракет, двигателей, топлив.
 
1 14 15 16 17 18 19 20
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

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

У численным методов нет ограничений по сложности. Их сложность состоит из множества простых элементарных составляющих. И составлять можно бесконечно. И даже тв. частицы можно будет обсчитать предельно дотошно. Но не всё сразу.
   44.0.2403.15544.0.2403.155
RU umbriel #19.08.2015 22:12  @SashaMaks#19.08.2015 20:42
+
+1
-
edit
 

umbriel

опытный

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

Конечно однозначный, с ним гораздо удобнее пускать пыль в глаза, чем с OpenCL :D
   44.0.2403.15544.0.2403.155
RU SashaMaks #19.08.2015 22:16  @Oxandrolone#19.08.2015 22:12
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

Открой глаза, натренеруй внимательность, перестань заниматься троллингом и, главное, научись признавать свои ошибки.
   44.0.2403.15544.0.2403.155
RU umbriel #20.08.2015 00:14  @SGRMrocket#19.08.2015 16:57
+
-
edit
 

umbriel

опытный

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 "широко шагаешь - порвешь штаны" :D

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

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

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

PS Жалко, что ты не из Питера.
   44.0.2403.15544.0.2403.155
Это сообщение редактировалось 20.08.2015 в 00:23
RU SGRMrocket #22.08.2015 13:44
+
-
edit
 

SGRMrocket

новичок

SashaMaks

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

umbriel

Поскольку у меня уже есть опыт разработки подобного софта для cpu и gpu - то мне уже нет принципиальной разницы под что проектировать код. Тем более что код написанный под gpu без проблем запускается и отлаживается на cpu. Попробую вкратце описать (на основе опыта сделанных ранее программ) как будет выглядеть самая простая версия такого симулятора:

Область расчета состоит из равносторонних квадратных ячеек, каждая из которых может содержать или газ, или твердое тело. Граничные условия - открытые (граничные ячейки дублируют своих соседей).

Ячейки с твердым веществом должны быть двух типов - топливные и оболочечные. Отличие между ними лишь в том что топливные ячейки могут включать режим горения и начинать добовлять в свободные соседние ячейки разогретый газ. Остальные свойства твердой материи - способность передавать тепло и способность разрушаться (превращаться в газ под действием окружающей среды или собственной температуры)

Тут встает вопрос производительности и универсальности: нужна ли таком симмуляторе возможность существования одновременно нескольких типов топлив и оболочек? (вдруг Serge77 захочет сделать бессопловик из 2-х типов топлив)

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

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

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


Пока в кртаце я все вижу именно так. В ближайшее время собираюсь почитать про OpenCl чтобы сравнить его с уже известной мне CUDA.


На последок прикладываю обещанные ранее программы симуляции газа и исходные коды.

В папке RME исходный код симулятора двигателей, в папке GDS исходный код симулятора газа на CUDA.

RME.exe - самая последняя ревизия симулятора двигателей, код от которой я потерял... Чтобы посмтореть как она работает - просто запустите exe, нажмите на кнопку "загрузить" и укажите путь к тестовому изображению (demo.bmp). Затем включите галочку "фин разруш" и установите в нижнем правом поле "общее время" - 4 или 5 секунд. Далее нажмите "запустить" для старта расчетов. После начала расчетов окно программы зависнет и сделается минимального размера. Программа будет сохранять результаты по пути расположения исходного изображения с задачей, а после окончания процесса расчета прекратит работу.
Прикреплённые файлы:
 
   40.040.0
RU SashaMaks #22.08.2015 18:54  @SGRMrocket#22.08.2015 13:44
+
-
edit
 

SashaMaks
SashaPro

аксакал

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 просто не поймет по понятным причинам.
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #22.08.2015 21:04  @SashaMaks#22.08.2015 18:54
+
-
edit
 
SashaMaks> Насколько мне известно, OpenCL - это всего лишь дополнение для OpenGL.

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

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

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

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

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

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

Вот OpenCL форсится, потому что он якобы удобнее для программиста, чем CUDA, а, главное, работает независимо от типа видеоадаптера. Т.е. на последних интеловских "встроенных в процессор" видеочипах его тоже можно использовать.
   11.011.0
RU SashaMaks #22.08.2015 21:18  @Бывший генералиссимус#22.08.2015 21:04
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

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

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

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

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

А о чём там идёт речь?
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #23.08.2015 02:46  @SashaMaks#22.08.2015 21:18
+
-
edit
 
Б.г.>> Именно, как стандарт вычислений общего назначения на видеопроцессорах.
SashaMaks> Каких именно вычислений?

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

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

SashaMaks
SashaPro

аксакал

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

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

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

Попробую по-другому спросить. Что за программа у нас получится и что она сможет делать, если в ней будет только OpenCL?
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #23.08.2015 10:27  @SashaMaks#23.08.2015 10:18
+
-
edit
 
SashaMaks> А где примеры этих команд?

clFFT: OpenCL Fast Fourier Transforms (FFT's)

The clFFT library is an OpenCL library implementation of discrete Fast Fourier Transforms. It: The downloadable binary packages are available at Once the appropriate package for the respective OS has finished downloading, uncompress the package using the native tools available on the platform in a directory of the user's choice. Everything needed to build a program using clFFT is included in the directory tree, including documentation, header files, binary library components, and sample programs for programming illustration. // Дальше — clmathlibraries.github.io
 

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

Поиск следующего числа Мерсенна, прогноз погоды, поиск транзитов экзопланет в сырых данных телескопа "Кеплер", да много всяких применений, не связанных с трёхмерной графикой.
У OpenCL некоторые сложности с файловым вводом-выводом, поэтому, насколько я понимаю, программа строится из модулей, написаных в OpenCl и в более традиционных Фреймворках.
   11.011.0
RU SashaMaks #23.08.2015 11:19  @Бывший генералиссимус#23.08.2015 10:27
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

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

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

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

Ракетный софт [SGRMrocket#19.08.15 16:57]

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


Как же тогда вводить данные? Моделировать двигатель, ракету? Картинками?
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #23.08.2015 12:51  @SashaMaks#23.08.2015 11:19
+
-
edit
 
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).
   11.011.0
RU SashaMaks #23.08.2015 17:23  @Бывший генералиссимус#23.08.2015 12:51
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

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

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

Xan

координатор

Skyangel> :facepalm:

Толи магнитная буря
(Магнитные бури)
Толи xep знает что.
С саморазгоном, как в атомной бомбе.
Печально, в общем-то.
   
RU SashaMaks #23.08.2015 20:01  @Skyangel#23.08.2015 18:59
+
-
edit
 

SashaMaks
SashaPro

аксакал

Skyangel> :facepalm:

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

SashaMaks
SashaPro

аксакал

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

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

Но тебе не понять.
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #23.08.2015 23:55  @SashaMaks#23.08.2015 20:01
+
-
edit
 
Skyangel>> :facepalm:
SashaMaks> Не угадал. Скорее растерянность от неопределенности.

Саша, я тебе про Фому, а ты мне про Ерёму.
Я тебе объясняю, что между OpenGL и OpenCL нет никакой связи, за исключением железа, на котором оно исполняется. Тебя вводят в заблуждение похожие буквочки в названии.
OpenCL может применяться независимо от OpenGL, потому что это не надстройка, как ты некоторое время назад написал. Это совершенно отдельный язык (точнее, среда) программирования видеочипов, как вычислительных средств. Вычислительных, понимаешь? Видеочип используется, как векторный математический сопроцессор.
Причём, что интересно, пиковая их производительность достигается не на 3D графике, а на вычислениях над векторами с большими размерностями. Координаты точки - это вектор с размерностью три, координаты твёрдого тела - вектор размерностью шесть (три линейных и три угла).
Максимум же производительности достигается на векторах и матрицах большей размерности, начиная от 64, и дальше - в зависимости от архитектуры чипа.
Дело не в том, что мы хотим или не хотим.
Дело в том, что сейчас даже суперкомпьютеры используют видеочипы, наряду с традиционными процессорными ядрами, и софт для написания программ под них порождает стандарты пачками, и кому-то в голову пришла дурная мысль - "а назовём-ка мы новую среду похоже на то, что использовалось раньше на три дэ ускорителях, глядишь, программисты решат, что им это привычнее, и побегут к нам".
"И вот вам результат." ©
   11.011.0
RU SashaMaks #24.08.2015 00:06  @Бывший генералиссимус#23.08.2015 23:55
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

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

Я предложил среду для разработки, а мне в ответ про "пыль в глаза".
Потом и вовсе выяснилось, что OpenGL не нужен.
   44.0.2403.15744.0.2403.157
RU Бывший генералиссимус #24.08.2015 00:11  @SashaMaks#24.08.2015 00:06
+
-
edit
 
Б.г.>> Саша, я тебе про Фому, а ты мне про Ерёму.
SashaMaks> Там это не векторы, а просто буферы, уверен, что и в OpenCL - это тоже буферы, а из размерность может быть любой, в зависимости от назначения.
Смысл векторных операций в том, что ты одной командой выполняешь операцию над всеми компонентами вектора СРАЗУ, используя аппаратные возможности чипа. Т.е. умножение 128 пар чисел с получением 128 результатов - одной командой. Так что, нет, это не просто буферы.
   11.011.0
RU SashaMaks #24.08.2015 00:21  @Бывший генералиссимус#24.08.2015 00:11
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

Это просто буфер, причём очень маленький.
Те же команды из ряда modeling, viewing, projection operations, rotation, translation, scaling, reflecting, orthographic projection, perspective projection, преобразует сразу все векторы и не только в один заход с CPU одной командой.
   44.0.2403.15744.0.2403.157
Это сообщение редактировалось 24.08.2015 в 01:06
RU umbriel #24.08.2015 00:32  @SashaMaks#24.08.2015 00:21
+
-
edit
 

umbriel

опытный

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

Что ты несешь? Ты представляешь себе, что твою писанину могут читать профессиональные программисты? Стыдоба :(
   44.0.2403.15744.0.2403.157
RU SashaMaks #24.08.2015 02:06  @Oxandrolone#24.08.2015 00:32
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

Поясни, что не так.
   44.0.2403.15744.0.2403.157
RU Ignis Caelum #24.08.2015 21:03  @SGRMrocket#19.08.2015 16:57
+
-
edit
 

Ignis Caelum

опытный

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

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

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

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

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

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

Если есть интерес к такому подходу - предлагаю тебе создать новую тему с названием проекта и там вести обсуждение.
   11.011.0
1 14 15 16 17 18 19 20

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru