Повторить подвиг Кирилла Левина

Б.г.> Но хочется чего-то позагогулистее. В Лин Индастриал Алексей Мазур (я не знаю, есть ли у него аккаунт на авиабазе) сделал хороший инструмент для моделирования вывода на орбиту

Этот инструмент был написан на Матлабе. Как оказалось, у современного матлаба есть модель Земли, учитывающая несферичность и т.д. Понятно, что программировать всё на C++ самому сейчас не нужно. Понятно, что нужно брать какой-нибудь правильный инструмент. Но в Матлабе я ни бум-бум. Готовый скрипт запустить умею, но и только. Как в нём чего править - надо учиться.

Значит, какой-то нужен инструмент для задачи того, что у Мазура зафиксировано. По мотивам "Таймыра" той ещё инкарнации. И программа угла тангажа взята "от прототипа".

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

Б.г.> До этого в Лин Индастриал приходили разные люди и предлагали разную (в том числе, и безвозмездную) помощь, но решать начинали какие-то свои задачи, нисколько не сообразуясь с поставленной...
Задачи ставят своим работникам.
Ты хочешь коллаборацию собрать для создания программы?
Тогда сформулируй внятное ТЗ на программу.
И условия работы в коллаборации.

Я, по привычке, ни на кого не надеясь, ковыряют своё.

Тупое симулирование с маленьким квантом времени.
Многоступенчатость, ТТ-ступени с коротким временем работы — всё задаётся, время работы, тяга, тангаж.
Геометрия меняется, для каждой таблица Cx и Cy с интерполяцией.
Счёт Cx и Cy в отдельной чужой проге с переносом результатов в таблицы.

Эллиптическая Земля, задаётся место и время старта, из этого определяется направление на солнце и магнитное поле.

Но всё это ещё не сделано!

Вопрос: в какой форме лучше задавать параметры ступеней?

А, ещё другой прогой хочется посчитать, как далеко спутник будет пролетать от других спутников вообще и от МКС в частности. На предмет ДТП.
С учётом вариаций сопротивления атмосферы.
Живых спутников, которые могут встретиться, порядка сотни.

Б.г.>> До этого в Лин Индастриал приходили разные люди и предлагали разную (в том числе, и безвозмездную) помощь, но решать начинали какие-то свои задачи, нисколько не сообразуясь с поставленной...
Полл> Задачи ставят своим работникам.

Ну, так, ясен пень! Чел приходит в "Лин Индастриал" с улицы и говорит, что готов поработать, причём, некоторое время - бесплатно, есличо, на будущее благо частной космонавтики! Ему говоришь, так и так, нужно то-то и то. Он говорит, - ясно, через неделю принесу первые намётки. Появляется через месяц, предъявляет перелицованную (или даже не перелицованную) программу, написанную им или его отделом - для другого, по другому поводу, и не делающую того, что просили!

Полл> Ты хочешь коллаборацию собрать для создания программы?

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

Полл> Тогда сформулируй внятное ТЗ на программу.
Полл> И условия работы в коллаборации.

ТЗ-то сформулировать можно. Что же до условий... Я же не могу ничего предложить! За исключением своей работы по координации усилий других людей, плюс альфа-бета-гамма-дельта-тестирование
Скажу больше, все мы "творцы" в худшем смысле этого слова - капризные, самолюбивые, и т.д. И, когда возникают замечания и претензии, они быстро убивают первоначальный энтузазизм, и совместная работа прекращается.

Б.г.> ТЗ-то сформулировать можно.
Сделай.

Б.г.> Что же до условий...
Условия это список вроде такого:
1. Не менее раза в сутки прочитывать электронную почту, при планируемой поездки без интернета - сообщать об этом заранее.
2. Не реже пары дней отписываться по своим работам коллегам, даже если работы не велись.
3. Не использовать в переписке с коллегами мат (список уточняется по мере работы).
4. Считать все результаты работ, совершенных в коллаборации, собственностью коллаборации, не выдавать их посторонним и не присваивать себе без согласования в коллаборации.
...

Б.г.>> ТЗ-то сформулировать можно.
Полл> Сделай.

Без ТЗ вообще непонятно, как вести работы. Оно должно быть хоть в каком-то виде.

Полл> 1. Не менее раза в сутки прочитывать электронную почту, при планируемой поездки без интернета - сообщать об этом заранее.
Полл> 2. Не реже пары дней отписываться по своим работам коллегам, даже если работы не велись.

Отсекаются большинство опенсорсников и люди с непостоянным графиком работы. Не всегда можно работать в таком упорном режиме, если это работа в свободное время.

Полл> 4. Считать все результаты работ, совершенных в коллаборации, собственностью коллаборации, не выдавать их посторонним и не присваивать себе без согласования в коллаборации.

Ты предлагаешь софт сделать платным? Иначе непонятно, зачем такие требования.

Sandro> Без ТЗ вообще непонятно, как вести работы. Оно должно быть хоть в каком-то виде.

Есть более первичный док — "Инструкция оператору".
Который заканчивается фразой "... и нажать Главную Кнопку".
Что оператор хочет увидеть и за какие рычаги хочет дёргать.
Скорее, эмоциональные хотелки, приспособленные к устройству человека.

На его основе пишется ТЗ.
Где всё формально и чётко.
Но это потом, для конкретных исполнителей.

Как-то так!!!

Sandro> Без ТЗ вообще непонятно, как вести работы. Оно должно быть хоть в каком-то виде.
Xan> Есть более первичный док — "Инструкция оператору".
Какие этапы пройдет разработка ТЗ - это вопрос второй.
Но ТЗ должно быть.

Sandro> Отсекаются большинство опенсорсников и люди с непостоянным графиком работы. Не всегда можно работать в таком упорном режиме, если это работа в свободное время.
Ок, с каким интервалом "не отсекаются"?

Sandro> Ты предлагаешь софт сделать платным? Иначе непонятно, зачем такие требования.
Есть юридические проблемы бесплатного софта, когда группы разработчиков распадаются или кто-то присваивает себе кусок общей разработки.
Для уменьшения подобных проблем данный пункт в правилах необходим.

Xan> Есть более первичный док — "Инструкция оператору".
Xan> Что оператор хочет увидеть и за какие рычаги хочет дёргать.
Xan> Скорее, эмоциональные хотелки, приспособленные к устройству человека.

Чего хотелось бы.
Прежде всего, анализа баллистики.
Что я под этим понимаю.
Вот у меня есть X (где X=<6) ступеней и X-1 баллистических пауз. Напомню, Лямбда-4S была, фактически, пятиступенчатой. Но там баллистическая пауза была ровно одна - перед последней ступенью. Поскольку я имею ограниченное время работы первой ступени, мне может понадобится баллистическая пауза между 1 и 2 ступенями. Помнится, Дмитрий Воронцов вводил такую паузу для нанолончера, про который он написал статью в НК.

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

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

Поскольку прога предназначена для энтузиастов, а не для профессионалов, она должна давать советы:

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

Дополнительно хочется, чтобы программа автоматически просчитывала варианты, когда "что-то идёт не так" - двигатели недобирают 5% тяги, но дают правильный полный импульс, двигатели дают правильную тягу, но недобирают 5% полного импульса, плотность атмосферы на 1% больше стандартной, и т.д.
И ещё хочется иметь возможность вводить уход навигационных датчиков. Хотя бы линейный от времени. А, желательно, квадратичный от времени, т.к. у всех "нетрадиционных" датчиков выходной сигнал - это угловая скорость, а угол является интегралом.

Б.г.> Вот у меня есть X (где X=<6) ступеней и X-1 баллистических пауз.
Накидать в Экселе расчет взлета проблем нет. Но если ты собираешься со старта "рвать когти" куда-то на сверхзвук, потребуется реалистичная характеристика Сх ракеты-носителя во всем диапазоне скоростей с 4-ой ступенью и без нее.

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

Б.г.> Поскольку прога предназначена для энтузиастов, а не для профессионалов, она должна давать советы:
Б.г.> а) когда даётся нереалистичное время выведения на орбиту;
Разве время выхода на орбиту не сама программа вычислять будет?

Б.г.> б) когда даётся нереалистичная программа угла тангажа;
Не понял, что это значит.

Б.г.> в) когда даётся нереалистичное значение весового совершенства;
Я у себя в подобных скриптах в комментариях подписываю для людей диапазон или характерное значение, но вдруг ты внеочередному Илону Маску собираешься портить праздник жизни, доказывая нереальность характеристик его гениального творения?

Б.г.> г) когда малые изменения входных параметров почему-то дают большие изменения выходных.
То есть считать пакет траекторий, а затем анализировать результаты?

Б.г.> Дополнительно хочется, чтобы программа автоматически просчитывала варианты, когда "что-то идёт не так"
А потом на пакет траекторий из предыдущего пункта считать на размерность больший пакет вероятных траекторий.
Просятся многопотоковые вычисления под запросы ваши, барин.
И смайлик Йоды.

Б.г.>> Соответственно, хочется использовать гравитационный разворот,
Полл> Потери на аэродинамическую стабилизацию

А какие на неё потери? колебания вокруг нейтрального положения с соответствующим рассеянием кинетической энергии? Площадь же миделя можно задать отдельно, и Cx тоже?

Полл> и процессию может имеет смысл посчитать отдельно? Не представляю, как их считать в общей программе вывода.

А, между тем, прецессия - вещь крайне важная при стабилизации вращением...

Полл> А еще эти потери будут вероятностными - то есть в каком-то диапазоне, соответственно считать надо пакет траекторий.

В корень зришь! Но не затем ли у меня на столе шестиядерный процессор и карта с терафлопсом, хоть и одинарной точности?

Б.г.>> Поскольку прога предназначена для энтузиастов, а не для профессионалов, она должна давать советы:
Б.г.>> а) когда даётся нереалистичное время выведения на орбиту;
Полл> Разве время выхода на орбиту не сама программа вычислять будет?

Я неточно выразился. Вот у нас есть суммарное время работы всех N ступеней в 100 секунд. Программа должна подсказать, что, без баллистических пауз с таким временем работы на орбиту не попасть. Т.е. чел, севший в первый раз программу эту мучить, имеет право не знать, что надо задать баллистические паузы, и где их выгодно вставлять, а где - невыгодно.

Б.г.>> б) когда даётся нереалистичная программа угла тангажа;
Полл> Не понял, что это значит.
Угол атаки на трансзвуке больше 8 градусов. Угол атаки на MaxQ больше 4 градусов. Угловая скорость по тангажу больше 15 градусов в секунду. Угловое ускорение больше 100 градусов в секунду за секунду. Скоростной напор на каком-то этапе больше 1 атмосферы.
Б.г.>> в) когда даётся нереалистичное значение весового совершенства;
Полл> Я у себя в подобных скриптах в комментариях подписываю для людей диапазон или характерное значение, но вдруг ты внеочередному Илону Маску собираешься портить праздник жизни, доказывая нереальность характеристик его гениального творения?
Б.г.>> г) когда малые изменения входных параметров почему-то дают большие изменения выходных.
Полл> То есть считать пакет траекторий, а затем анализировать результаты?

Да, конечно! Я готов полчасика подождать, если программа предупредит, что долго считать будет!

Б.г.>> Дополнительно хочется, чтобы программа автоматически просчитывала варианты, когда "что-то идёт не так"
Полл> А потом на пакет траекторий из предыдущего пункта считать на размерность больший пакет вероятных траекторий.
Полл> Просятся многопотоковые вычисления под запросы ваши, барин.
Полл> И смайлик Йоды.

Надо иметь возможность регулировать размерность массива траекторий Чем ближе к окончательному варианту, тем дольше юзер согласен ждать. С другой стороны, можно делать анализ по частным производным.

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

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

Б.г.> Я неточно выразился. Вот у нас есть суммарное время работы всех N ступеней в 100 секунд. Программа должна подсказать, что, без баллистических пауз с таким временем работы на орбиту не попасть. Т.е. чел, севший в первый раз программу эту мучить, имеет право не знать, что надо задать баллистические паузы, и где их выгодно вставлять, а где - невыгодно.
Уверен, что интерфейс программы, способной на требуемые тобой расчеты, сделает невозможным ее применение человеком, не знающим про баллистические паузы.

Б.г.> Б.г.>> б) когда даётся нереалистичная программа угла тангажа;
Полл>> Не понял, что это значит.
Б.г.> Угол атаки на трансзвуке больше 8 градусов. Угол атаки на MaxQ больше 4 градусов. Угловая скорость по тангажу больше 15 градусов в секунду. Угловое ускорение больше 100 градусов в секунду за секунду. Скоростной напор на каком-то этапе больше 1 атмосферы.
Как я понимаю, все эти параметры взяты от реально существующих ракет, и не являются физически непреодолимыми барьерами?

Б.г.> Да, конечно! Я готов полчасика подождать, если программа предупредит, что долго считать будет!
Ты хочешь оценки потребного времени вычисления по каждому отдельному случаю или предупреждения в интерфейсе программы, что расчет может быть достаточно длительным?

Б.г.> Надо иметь возможность регулировать размерность массива траекторий Чем ближе к окончательному варианту, тем дольше юзер согласен ждать. С другой стороны, можно делать анализ по частным производным.
Пожалуйста, распиши этот пункт подробней, у меня не складывается понимание его.

Тут два пересекающихся вопроса, на самом деле.

Sandro>> Отсекаются большинство опенсорсников и люди с непостоянным графиком работы. Не всегда можно работать в таком упорном режиме, если это работа в свободное время.
Полл> Ок, с каким интервалом "не отсекаются"?

В случае бесплатного проекта — к сожалению, с неограниченно большим. Тебе просто нечем мотивировать человека непрерывно работать в случае, если ты не платишь ему денег и при этом отбираешь результаты труда. Это же не армия, где "... не хочешь — заставим!"
В слчае, если ты отбираешь его труд в пользу коллаборации и даже лишаешь публичной славы, как автора, вообще непонятно, зачем ему на тебя работать.

Sandro>> Ты предлагаешь софт сделать платным? Иначе непонятно, зачем такие требования.
Полл> Есть юридические проблемы бесплатного софта, когда группы разработчиков распадаются или кто-то присваивает себе кусок общей разработки.

И они решаются публичной выкладкой проекта под лицензией, запрещающей присвоение, например такой жестокой, как GNU GPL.
В случае закрытого проекта вообще непонятно, как этому помешать, особенно в случае распада группы. Вот было трое разработчиков, они все перессорились, кто из них теперь "коллаборация"?

В случае опенсорса — это общественность, ей и принадлежит проект.

Полл> Для уменьшения подобных проблем данный пункт в правилах необходим.

По моему опыту, наоборот, он является их генератором.

Б.г.> Чего хотелось бы.

То есть, задача разбивается на три:

1) Написать более-менее приемлемую аэробаллистическую решалку
2) Сделать к ней пользовательский интерфейс, позволяющий подбирать параметры вручную
3) Попытаться написать автомат подбора

Так?

Б.г.>> Чего хотелось бы.
Sandro> То есть, задача разбивается на три:
Sandro> 1) Написать более-менее приемлемую аэробаллистическую решалку
Sandro> 2) Сделать к ней пользовательский интерфейс, позволяющий подбирать параметры вручную
Sandro> 3) Попытаться написать автомат подбора
Sandro> Так?

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

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

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

Sandro>> То есть, задача разбивается на три:
Sandro>> 1) Написать более-менее приемлемую аэробаллистическую решалку
Sandro>> 2) Сделать к ней пользовательский интерфейс, позволяющий подбирать параметры вручную
Sandro>> 3) Попытаться написать автомат подбора
Sandro>> Так?
Б.г.> В принципе, да. Только не очень понятно, насколько это "естественное" членение задачи.

На мой взгляд, да. Во всяком случае математическое ядро уж точно должно быть изолировано от прочих подсистем, и автомат подбора — это более высокоуровневая часть, чем математическое ядро. Разумеется, при росте проекта придётся разделять и более тонкие сущности.

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

Вот это точно не для первой версии. Вообще, ИМХО для первой альфы необходимо ограничиться натурально обсчётом материальной точки над безатмосферным глобусом. Со вводом и выводом .csv . На самом деле уже на этом этапе придётся решать кучу архитектурных проблем. Например, как представлять углы? Эйлеровы неоднородны и имеют особые точки, с кватернионами у многих людей есть пробы понимания, матрицы поворота теряют унитарность при накоплении вращений.
Ладно, как числа-то представлять вообще?

Ну про числа я могу сказать сразу: double, и только double. Одинарная точность приводит к тому, на расстоянии в 6400 км (радиус планеты!) от начала координат дискретность представления положения составляет ... так, сколько?

package tests;

public class FPPrecision {
	public static void main(String[] args) {
		float earthRadius = 6400.f * 1000.f;
		float nextPos = Math.nextUp(earthRadius);
		float step = nextPos - earthRadius;
		
		System.out.printf("Delta is: %f\n", step);
	}
}

Запускаем:

Delta is: 0.500000

... 50 см ровно. А на 10000 км целый метр, кстати. Какая уж тут баллистика...

Sandro> Вообще, ИМХО для первой альфы необходимо ограничиться натурально обсчётом материальной точки над безатмосферным глобусом. Со вводом и выводом .csv .

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

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

Кватернионам нет реальной альтернативы для космического аппарата. Для ракеты-носителя, работа которой заканчивается через максимум 15 минут после начала движения, в принципе, можно ограничиться плоским движением, считать, что космодром на экваторе и мы всегда летим только на восток. Тем более, что мы уж решили, что глобус безатмосферный.

Если честно, я сейчас пытаюсь вкурить кватернионы в n+1 раз. Именно потому, что хочется везти вектор положения даже в стабилизированной вращением ракете. Один из моих жж-френдов с ником nabbla1 берётся за написание того, как же нужно работать с кватернионами в БИНС.

Sandro> Ладно, как числа-то представлять вообще?

На писишке-то? Да как угодно! Другое дело - в БЦВМ!

Sandro> Ну про числа я могу сказать сразу: double, и только double. Одинарная точность приводит к тому, на расстоянии в 6400 км (радиус планеты!) от начала координат дискретность представления положения составляет ... так, сколько?
Sandro> ... 50 см ровно. А на 10000 км целый метр, кстати. Какая уж тут баллистика...

GeForce GTX580 плохо заточена под расчёты с двойной точностью, но, 280 гигафлопсов всё же даёт. Плюс Xeon X5650 ещё где-то 90 гигафлопсов. Дабл - значит, дабл... Надо - так надо.

Если, в принципе, на видеокарте будет считаться хорошо, я могу и 1080 купить! У неё падение при переходе на дабл всего в 2 с небольшим раза, значит, около 4 терафлопсов можно выжать.

Вот только майнеры успокоятся чуть-чуть...

Sandro> Вот это точно не для первой версии. Вообще, ИМХО для первой альфы необходимо ограничиться натурально обсчётом материальной точки над безатмосферным глобусом.
Влияние атмосферы в большинстве случаев будет на несколько порядков превосходить погрешность от использования 32-битных переменных.
Для участка траектории не обязательно считать в масштабах всей планеты. Даже если требуется использовать модель гравитационного поля Земли.

Sandro> В случае бесплатного проекта — к сожалению, с неограниченно большим.
В таком разе и работы не будет.
Слава разработчику достается.

Sandro>> Ладно, как числа-то представлять вообще?
Б.г.> На писишке-то? Да как угодно! Другое дело - в БЦВМ!

Ну так на Pic24, если вращение и ускорение float, а скорость и координаты double — 320 счётов в секунду при 29.5 МГц

Зачем терафлопсы и параллельность?
Задача же одномерная (по времени).
Не погоду считаешь!

Полл>> Есть юридические проблемы бесплатного софта, когда группы разработчиков распадаются или кто-то присваивает себе кусок общей разработки.
Sandro> И они решаются публичной выкладкой проекта под лицензией, запрещающей присвоение, например такой жестокой, как GNU GPL.
Выкладка софта, принципиально пригодного для проектирования многоступенчатых баллистических ракет, под GNU GPL, не приветствуется ни одним государством. По очевидным причинам. Больше того, есть прецеденты.

Полл> Влияние атмосферы в большинстве случаев будет на несколько порядков превосходить погрешность от использования


А левитация над безатмосферной планетой вполне хорошая задача для моделирования.
И никто из регулирующих органов не достанет.
Фантастика и есть фантастика.

Б.г.> ...
Попробуем определится с исходными данными.
1. Форма Земли - сфера, геоид, физ.модель?
2. Гравитационное поле Земли - условное, физмодель?
3. Атмосфера - отсутствует, условно-усредненная модель, физмодель?
4. Учитываем влияние гравполя Луны и Солнца, приливные явления?
5. До какой детализации считаем движение Земли - вращение, движение в связке с Луной, движение связки Земля-Луна вокруг Солнца без учета других тел Солнечной Системы, полная физмодель в границах СС?

Далее вопрос оптимизации. Будем использовать переменные "двойной точности" или "нарезать" пространство на куски под расчет куска траектории?
"Нарезание" потребует ресурсов на прогнозирование этих кусков, на их вырезание и совмещение. Но в самом куске расчеты будут идти быстрее.

Б.г.>> ...
Полл> Попробуем определится с исходными данными.
Полл> 1. Форма Земли - сфера, геоид, физ.модель?

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

Полл> 2. Гравитационное поле Земли - условное, физмодель?

Хотелось бы учёта несферичности. Возможно, отключаемого, для владельцев слабых компов. Я уже несколько раз встречал утверждения, что при запуске на восток и плоском выведении, реально получающееся наклонение орбиты на 0,2-0,3 градуса больше, чем широта площадки.

Полл> 3. Атмосфера - отсутствует, условно-усредненная модель, физмодель?

Атмосфера нужна обязательно, ибо я собираюсь моделировать ракету с аэродинамической стабилизацией первой ступени. Сезонный фактор надо учитывать, ибо плотность меняется заметно. В своё время это повлияло на выбор траекторий Союз-2.1. Думаю, что достаточно движка "зима-лето" плюс таблица стандартной атмосферы.

Полл> 4. Учитываем влияние гравполя Луны и Солнца, приливные явления?

Нет, это излишне.

Полл> 5. До какой детализации считаем движение Земли - вращение, движение в связке с Луной, движение связки Земля-Луна вокруг Солнца без учета других тел Солнечной Системы, полная физмодель в границах СС?

Только вращение Земли.

Полл> Далее вопрос оптимизации. Будем использовать переменные "двойной точности" или "нарезать" пространство на куски под расчет куска траектории?
Полл> "Нарезание" потребует ресурсов на прогнозирование этих кусков, на их вырезание и совмещение. Но в самом куске расчеты будут идти быстрее.

Пока про это нельзя сказать - неясен сам объём вычислений.

Смотри. Когда мы с Алексеем Мазуром моделировали выведение с использованием реальных шумов и дрейфа ADIS16445, он использовал готовую модель Земли, что есть в Матлабе. Там есть включение отдельно сжатия и отдельно высших гармоник гравитационного поля.

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

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

Думаю, что пока надо ориентироваться на использование даблов везде.

Б.г.> Достаточно учёта сжатия.
Геоид с отдельно настраиваемыми параметрами РН в момент пуска - высотой от "условного 0", углами ориентации и вектором скорости?

Б.г.> Хотелось бы учёта несферичности. Возможно, отключаемого, для владельцев слабых компов. Я уже несколько раз встречал утверждения, что при запуске на восток и плоском выведении, реально получающееся наклонение орбиты на 0,2-0,3 градуса больше, чем широта площадки.
Эта погрешность получается от геометрии, а не гравитации.
Предлагаю гравполе считать по упрощенной модели.

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

Полл>> 4. Учитываем влияние гравполя Луны и Солнца, приливные явления?
Б.г.> Нет, это излишне.
Ок.

Полл>> 5. До какой детализации считаем движение Земли - вращение, движение в связке с Луной, движение связки Земля-Луна вокруг Солнца без учета других тел Солнечной Системы, полная физмодель в границах СС?
Б.г.> Только вращение Земли.
То есть считать будем только АУТ и только на низкую орбиту?

Б.г.> Смотри. Когда мы с Алексеем Мазуром моделировали выведение с использованием реальных шумов и дрейфа ADIS16445, он использовал готовую модель Земли, что есть в Матлабе. Там есть включение отдельно сжатия и отдельно высших гармоник гравитационного поля.
Б.г.> Из-за шумов и дрейфа гироскопа разброс высот перигея, при наличии коррекции по Солнцу в середине времени работы составлял 16 км (среднеквадратичное отклонение, пиковое примерно в 3 раза больше). Включение учёта сжатия давало ровно такой же сдвиг высоты перигея - 16 км. Высшие гармоники давали младшие сотни метров.
Б.г.> Хорошо видно, что учитывать в такой проге высшие гармоники нет смысла, а не учитывать сжатие неприятно.
Я в данном примере не понимаю, зачем заниматься увеличением точности, учетом несферичности в конкретном примере, если СКО(погрешность) сравнимо с увеличением точности?
Обычно принимается достаточной точность в два раза больше погрешности.

Б.г.> Думаю, что пока надо ориентироваться на использование даблов везде.
При использовании программы для вычисления АУТ вывода на низкие орбиты с точностью в километры или даже десятки километров пока не вижу в этом смысла. Но для меня это вопрос не принципиальный.
З.Ы. Заодно подобная точность снимет часть вопросов "безопасников" к данному ПО.