Определение положения планет

Я пишу трехмерный симулятор солнечной системы , в котором есть планеты, астероиды, кометы и транснептуновые объекты. Он также включает ежедневные тела "Близкого сближения" из базы данных Лаборатории реактивного движения. Я рассчитываю положения планет, используя документ « Кеплеровские элементы для приблизительного положения больших планет » из JPL/Caltech с формулами, действительными для диапазона от 3000 г. до н.э. до 3000 г. н.э. Похоже, расчеты дают мне положение, которое недостаточно точно при работе с близкими объектами: в моделировании время наименьшего расстояния между землей и объектом не соответствует теоретическому времени.

Я также попробовал формулы для диапазона от 1800 до 2050 года нашей эры (которые должны быть более точными) без существенной разницы.

Мой вопрос: есть ли более точный метод для расчета положения планет, чем метод, который я использую.

Я предполагаю, что вы знакомы с этим: ssd.jpl.nasa.gov/?ephemerides#planets
Насколько точно будет достаточно для ваших целей? Вам действительно нужны +/- тысячи лет или десятки или сотни будут в порядке?
Что касается точности, прямо сейчас, когда я загружаю элементы орбиты тела, которое должно быть ближе всего к Земле в этот день, это не так. Это может быть ближе за день до или через день после. Я предполагаю, что ошибка возникает из-за аппроксимации расчета элементов орбиты Земли по формулам, поскольку автор статьи называет расчеты «более низкой точностью».
@ChuckM Хорошо, я бы порекомендовал вам задать новый вопрос и включить полный конкретный пример (ссылки, числовые значения), ясно показывающий числовое несоответствие. Здесь есть несколько человек, которые могут помочь вам с этим, но чем больше вы документируете конкретную проблему/вопрос, тем больше вероятность того, что люди помогут. Кажется, нет предела количеству вопросов хорошего качества, которые вы можете задать здесь. Также включите ссылку на этот вопрос для справки.
Какой календарь используется для очень длительного периода в 6000 лет? Простой юлианский с продолжительностью года 365,25 дня или григорианский с 365,2425 днями? Разница в 6000 лет составляет 45 дней. В формуле статьи есть значение 36525, оно похоже на юлианское, а не на григорианское.
Юлианская длина года используется как 365,25. Я использую референс эпохи J2000 (2451545).
@Vince49: да, я знаком с веб-сайтом, но я не нашел API, который позволил бы мне программно извлекать эти данные.
@ChuckM, проверьте мой графический интерфейс для Horizons, он автоматически создает необходимый URL-адрес, а также разбивает его на читаемый формат: win98.altervista.org/space/exploration/NHUGUI.html
@jumpjack, спасибо за это. Очень удобно, что все параметры выяснены.

Ответы (1)

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

Реалистичные орбиты Солнечной системы лишь приблизительно кеплеровы.

Я упомяну, что интегрировать себя — это весело и познавательно, если вам действительно нравятся такие задачи, но сделать это правильно гораздо сложнее, чем показано в этих связанных ответах. Мне удалось сопоставить эфемериды JPL с 1 км за 1 год для дюжины крупных тел, но без правильного учета приливных эффектов между Землей и Луной положение Земли будет продолжать ухудшаться с каждым годом. Вам нужно будет сделать более сложный расчет, чем показанное здесь приближение.

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

Поэтому я думаю, что рано или поздно вы, вероятно, решите использовать существующие эфемериды. Если вам нравится программировать на C, должна быть документация по использованию таких вещей, как набор инструментов Spice для интерполяции ядер JPL . Как только вы освоите это, вы можете решить построить менее точные гораздо меньшие таблицы для интерполяции, учитывая, что вам может потребоваться сделать тысячи или десятки тысяч второстепенных тел.

Отличный ответ @RoryAlsop включает в себя несколько полезных ссылок, в том числе библиотеку Python jplephem , которая интерполирует ядра Spice. Это может быть особенно полезно для вас.

Пакет Python Skyfield уже настроен для автоматической загрузки и интерполяции эфемерид развития JPL , но они предназначены только для основных тел Солнечной системы. Поскольку вы уже используете Python, я думаю, вам действительно понравится читать этот пакет. Это радость от использования.

Кроме того, пакет Python PyEphem выполняет для вас более широкий спектр функций орбиты. Я менее знаком с этим, так что вам придется исследовать себя. Он существует довольно давно, и я узнал, что он основан на XEphem и VSOP87 ( см. также ).

Пакеты Python SkyField и PyEphem поддерживаются одним человеком.

Это действительно крутой программный пакет, который у вас есть на Github! На следующей неделе посмотрю.
@MarkAdler Я действительно думаю, что вам следует восстановить свой ответ. Они дополняют друг друга — мой — это что-то вроде шведского стола, ваш — к делу, так что будущим читателям лучше увидеть их обоих. Ответ прямо от НАСА - золотой!
На самом деле я ушел из НАСА около восьми месяцев назад.
@MarkAdler Поздравляю, но блеск (и опыт) НАСА никогда не стирается :-)