Точность ECEF в ECI с использованием только GAST

Я работаю над инструментом анализа орбиты с низкой и средней точностью. Моим ключевым фактором здесь является скорость, я анализирую созвездия с 500-1000 спутниками и хочу иметь возможность выполнять анализ менее чем за 1 минуту. Теперь это отдельная история, но я анализирую конкретные случаи круговых орбит, что значительно упрощает распространение.

Моя проблема, с которой я сталкиваюсь, заключается в преобразовании из ECEF в ECI для анализа доступа. Я знаю, что существует множество функций, использующих сокращения IAU, которые я использовал и тестировал. Моя проблема в том, что они занимают приличное количество времени и памяти (для меня 5-10 секунд - это много).

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

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

Ответы (1)

Вы должны использовать компьютер 1960-х годов, чтобы даже самое точное вычисление ориентации IAU относительно земли занимало «5-10 секунд».

Тем не менее, вычисление ориентации Земли с использованием чрезвычайно точного алгоритма в некоторую эпоху, а затем вращение Земли на 2 π радиан на звездные сутки ( 7.29211585275553 × 10 5 радиан в секунду) относительно земной оси z в эпохальное время будет иметь практически нулевую ошибку в течение следующих нескольких наносекунд после эпохи, пренебрежимо малую ошибку в течение следующих нескольких микросекунд до минут (или, возможно, даже часов) после эпохи, и после этого неприемлемая и постоянно растущая ошибка.

Относится ли эта «незначительная ошибка» всего к нескольким микросекундам или нескольким часам после времени эпохи, полностью зависит от допусков ошибок того, что вы делаете. Вы не сказали, что вы делаете, или каковы ваши допуски на ошибки.

Мне задавали этот вопрос несколько раз, и мой ответ вам будет таким же, как и тем, кто спрашивал в прошлом: я отказываюсь давать общий ответ. Вместо этого я помогаю им найти свой индивидуальный ответ, ища ту точку перегиба, где наихудшая ошибка превышает их устойчивость к ошибкам. Выберите несколько случайных эпох, а затем в обычные моменты времени рассчитайте угловую разницу между высокоточным расчетом ориентации Земли и простым расчетом. 2 π радиан на звездные сутки относительно эпохи. Найдите точку перегиба для этого случайно выбранного времени эпохи, повторите и выберите наихудший случай. Во многих случаях эта точка перегиба находится далеко за той точкой, где она не имеет значения с точки зрения вычислительных затрат.

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

Дэвид, я ценю честность, но я думаю, что это было немного неправильно. Время вычисления связано с тем, что я выполняю расчет каждую секунду в течение 90 дней. Что касается точности, мой вопрос не зависит от того, каковы требования моих требований к симуляции, поэтому я не вдавался в подробности требований симуляции. Мой вопрос заключался в том, что если вы учитываете только вращение Земли (т.е. у вас есть точный расчет GAST), то какой тип ошибки точности возникает
Так что проведите эксперимент. Вы говорите, что у вас есть доступ к высокоточному решению и вашему решению GAST. Запустите их обоих на интересующий период и сравните результаты. Вы можете сравнить их одновременно и посмотреть, во сколько вам обходится эта точность.
Согласитесь и с Дэвидом — с современными вычислительными ресурсами ориентация на землю не должна стоить вам так дорого. Я бы посмотрел на свой алгоритм. Если это не поможет вам, обратите внимание на параллельную обработку — сейчас у всего есть несколько ядер, и такие вещи, как OpenCL, довольно доступны.
@Smoran - Использование GAST - это прошлый век. (На самом деле, прошлое тысячелетие!) Модели прецессии/нутации Международного астрономического союза (МАС) 2000/2006 заменяют эклиптику и GAST концепциями, называемыми Небесным промежуточным происхождением (CIO) и углом вращения Земли (ERA). Эти новые концепции проще, быстрее и точнее, чем старые. Есть оговорка в отношении моего использования «быстрее»: это применимо только в том случае, если используется модель ухудшенной нутации. Самая точная модель нутации/прецессии включает более тысячи различных частот. Они необходимы для микросекундной астрономии.
Модели IAU также обеспечивают модель с более низкой точностью, точную до уровня угловых миллисекунд, которая намного быстрее, чем модель с более высокой точностью. И если даже меньшая точность приемлема, я предлагаю использовать подход, изложенный в моей модели: в различные моменты времени вычислить ориентацию Земли с использованием модели IAU/ICRS (возможно, модель с более низкой точностью), но в промежуточные моменты времени повернуть самая последняя исходная ориентация относительно мгновенной оси z. Вам не нужны GAST или UT1 для этих промежуточных моментов времени. ТТ работает очень хорошо.
@CoAstroGeek - В зависимости от того, сколько точек времени задействовано, использование модели с наивысшей точностью может быть чрезвычайно дорогостоящим в вычислительном отношении. Модель с высочайшей точностью имеет более тысячи составляющих частот, большинство из которых необходимы только для астрономии с высочайшей точностью, требующей точности на уровне микросекунд дуги. Отбрасывание подавляющего большинства этих частот приводит к ошибкам на уровне миллисекунд дуги. Для многих орбитальных анализов даже это является излишним как с точки зрения точности, так и с точки зрения вычислительных затрат.