Что вызвало проблему с двумя линейными элементами на МКС, начавшуюся 24 декабря 2019 г.?

Кто-нибудь знает, что произошло в NORAD или NASA или где бы то ни было из опубликованных TLE, что вызвало шатание TLE МКС в последнюю неделю 2019 года? В 2018 году этого не произошло. Что случилось? День года увеличился за 365 дней (не високосный год), а год остался 19 (2019) для вычисленных наборов TLE, которые вошли в первую неделю 2020 года и прошли после нее.

Я получаю свои наборы ISS TLE отсюда:

https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html

и здесь:

https://tle.info/data/ISS_DATA.TXT

Мой код теперь исправляет эти даты TLE, хранящиеся в моем архиве, после двух дней переписывания кода, чтобы следить за ним в следующий раз (и, с другой стороны, это привлекло мое внимание к некоторым скрытым проблемам в будущем, которые теперь также исправлены) . Но я хотел бы знать, был ли это просто сбой, или в настоящее время происходит какое-то изменение формата, который «тестируется»? По состоянию на 02.01.2020 TLE, которые я получил сегодня, вернулись в ожидаемый формат и больше не упоминаются как дни 2019 года, превышающие 365.

Официальное слово?

Поймите, я очень благодарна, что у нас есть все эти замечательные сервисы, и что мне больше не нужно щуриться на бумажные отчеты из Greenbelt, MD, или вводить их вручную, как это было необходимо много лет назад (но даже тогда, благодарна за это). Я хотел бы знать, есть ли изменения в работах, к которым я мог бы подготовиться заранее. И большое спасибо всем тем, кто поддерживает серверы, услуги и программные инструменты, которые здесь так ценятся.

Обновление 1-2-2020

В ответ на запрос uhoh в комментариях, вот три образца набора TLE, приобретенных 30 декабря 2019 г., но проблема впервые обнаружена 24 декабря 2019 г. по вышеупомянутым ссылкам. Обратите внимание на первый здесь (который не был первым TLE на веб-странице, но я сокращаю). Это нормально. А вот у других, из которых я показываю два, в качестве года указан 2019 (конечно, начальные 20 не показаны в стандартном формате), но тогда день года 366 (год не високосный), а затем в последнем TLE, день года 372? А год еще 19. То, что я назвал "шатким".

ISS
1 25544U 98067A   19365.78947330  .00016717  00000-0  10270-3 0  9114
2 25544  51.6407 101.7439 0005315  86.0590 274.1168 15.49502788  5904

ISS
1 25544U 98067A   19366.82137887  .00016717  00000-0  10270-3 0  9129
2 25544  51.6392  96.6358 0005156  88.7140 271.4601 15.49497216  6061

.
.
.

ISS
1 25544U 98067A   19372.17436792  .00016717  00000-0  10270-3 0  9187
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Я модифицировал свой код, чтобы поймать и исправить это при чтении из моих архивов, конечно, также пересчитав контрольную сумму, поскольку мои архивы сохраняют «шаткие» те, которые я впервые получил. (Для тех, кому не терпится задать вопрос, да, я забыл о пересчете контрольной суммы с первого раза.). Вот переработанная версия того последнего набора, который теперь отлично работает с pyephem (которому я рад, прямо не понравилась неправильная контрольная сумма):

ISS
1 25544U 98067A   20007.17436792  .00016717  00000-0  10270-3 0  9184
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Я был бы рад предоставить более подробную информацию или код, если бы они помогли, но в первую очередь я спрашиваю, знает ли кто-нибудь, было ли это всего лишь сбоем обработки в конце года, как мини-вещь 2000 года, или есть некоторые изменения в формат в работе, и они были не совсем готовы к прайм-тайму? Как и большинство людей, я бы предпочел запрограммировать заранее известное предстоящее изменение, чем удивляться этому. И это частичный мотив моего вопроса.

Обновление 1-4-2020:

Теперь читайте отчет № 3 о космическом треке для дальнейшего понимания. Кому интересно, ссылка здесь:

https://celestrak.org/NORAD/documentation/spacetrk.pdf

По мере того, как я продолжаю исследовать это, я продолжаю надеяться, приветствовать и ценить больше понимания от других.

Хотя у меня еще нет своего ответа, практический вывод из этой темы состоит в том, чтобы другие знали, что дой > дни целевого года в ситуации года - это возможная дата эпохи, которая может встречаться в TLE в последнюю неделю этого года. год или даже начало предыдущего года (?!, поскольку мы еще не установили, существует ли фиксированный жесткий предел меньше 999 до того, как год будет увеличен, и дой корректируется должным образом для этого увеличения года), и поэтому собственная кодовая база необходимо иметь дело с этим везде, где это может вызвать проблемы, если это произойдет неожиданно. IOTW, напишите код, чтобы ожидать этого.

@uhoh в ответ на ваш комментарий сегодня я добавил обновление с некоторыми образцами.
Какова бы ни была причина появления именно этих данных — функции преобразования данных вашего языка программирования должны справиться с этим. Очень распространено обращение к таким вещам, как «день -1» для последнего дня последнего месяца или «34 октября» для обозначения третьего дня ноября. Просто очень удобно с расчетами.
@asdfex после прочтения нескольких источников, предоставляющих ключ для понимания данных в различных позициях набора двухстрочных элементов, я еще не сталкивался с какими-либо подробностями, такими как ваши. Очень часто ссылаются на такие вещи, как «день -1» для последнего день последнего месяца или «34 октября» для обозначения третьего дня ноября. . Я полагаю, что я не единственный, кто хотел бы, чтобы это было изложено более ясно, ясно и официально на многих страницах, предназначенных для информирования нас. Спасибо, что вдохновили заполнить этот пробел своим комментарием.
Если это действительно, как было сказано, «очень распространено», возникает вопрос: «Насколько далеко за пределами стандартных ожидаемых диапазонов в этом контексте можно разумно ожидать, что официальная дата эпохи будет дрейфовать за культурно общепринятые ожидаемые диапазоны Григорианский календарь? Пять дней? Девять недель? Меньше 999 дней?» Есть ли документ, разъясняющий это? Это может оказаться чрезвычайно полезным при разработке кода и написании тестов для этого кода.
Мой комментарий был о работе с объектами даты в любом программном обеспечении, а не конкретно о TLE.
@asdfex хорошо. Понял. Мой код широко использует такие функции. Что было неожиданным, так это то, что фактически опубликованные данные отклонялись от разумно ожидаемого диапазона, основанного на документах, дающих ключ к пониманию значений, и подразумевающих, что диапазоны находятся в культурно приемлемых пределах. Значение дня года 372 для 2019 года не является нормальным культурно принятым ограничением для дней в году по григорианскому календарю. Отсюда и мой ОП. Действительно ли дой 372 на 2019 год лучше представляет четкую и не запутанную возможность использования данных? Не помешала бы даже сноска к ключу формата файла. Да?
@always_learning Просто посмотрите на спецификацию. Ио, и вот, их несколько. Все они имеют одну общую черту: эпоха — это юлианский день + дробь, представленная тремя символами в диапазоне [0–9]. Таким образом, 999 определенно является самым большим допустимым числом, отрицательные числа не допускаются. STK также говорит, что максимальное допустимое значение равно 366, ограничение, которое отсутствует в спецификации NORAD. Поэтому, если вы строго соблюдаете спецификацию NORAD, вам необходимо разрешить количество дней до 999.
@polygnome, не могли бы вы дать нам ссылку на спецификацию NORAD и спецификацию STK, чтобы другие читатели могли читать именно то, на что вы только что ссылались? Поскольку в качестве ответа еще ничего не было опубликовано, я попытаюсь обобщить то, что было сказано до сих пор, как первую публикацию ответа.
@always_learning Значения > 366, не запрещенные в TLE, едва ли отвечают на вопрос, почему они на самом деле сделали это или почему они остановились на 372, а затем переполнились. Вот почему я не опубликовал ответ, это дополнительная информация.
@полигном Я согласен. У меня еще нет вывода, но я попытаюсь подвести итоги, прочитав завтра пару статей. Возможно, это натолкнет на какие-то идеи. Если NORAD годами не менял свой алгоритм, можно было бы сделать вывод, что мы просто должны убедиться, что наш код правильно справляется с ситуацией. Технически, TLE, выраженный в любом случае, дает один и тот же орбитальный трек, но это оставляет мой вопрос без ответа. Если это возможный результат, время от времени, SGP4 или юлианских дат... что несомненно, так это то, что знакомые людям даты потребуют дополнительного кода для проверки и преобразования при необходимости.
@always_learning Я думаю, что наиболее важным вопросом, интересующим читателей сайта, был бы объективный вопрос о допустимых диапазонах TLE в различных контекстах, и это позволило бы Polygnome опубликовать информативный ответ для всех. Вы можете изменить свой заголовок, чтобы это произошло. Однако, если наиболее важным для вашего вопроса является «Что вызвало…» на сайте spaceflight.nasa.gov (что может быть трудно выяснить и, в конечном счете, тривиально и неинтересно), то вы можете оставить его как есть.
@uhoh очень хорошие моменты. У меня почти готова редакция. Кроме того, изучив отчет о космическом треке 3 и код на Фортране, я думаю, что у меня есть ключ к разгадке причины. Как вы говорите, я могу не получать известия непосредственно от НАСА или НОРАД, но я надеюсь, что моих предположений будет достаточно, чтобы другие поняли, что день года может сделать это в конце года в зависимости от того, как часто они выполняют дополнительные запуски для генерации TLE, предшествующие обновлению, запускаются 1 или 2 января. Все сводится к тому, что загружается в их вызывающую программу, и когда происходит запуск обновления. Я расскажу об этом подробнее, когда закончу писать.
@uhoh Уже есть сообщения о том, как далеко в будущем эпоха TLE может оставаться точной и т. Д., С участием ... вас. Я не собираюсь набирать больше очков, если это означает повторение темы, поэтому я могу оставить вопрос как есть и закончить тем, что может быть тривиальным ответом, но этот ответ был зудом, который мне нужно было почесать. Увидев в отчете подпрограммы, ВОДИТЕЛЯ и т. д., начал обращать на это внимание. Простой вопрос, возможно, в том, сколько TLE в будущем будет создано с даты начала выполнения задания, где вызывающий код рассматривает эту проблему конца года как да, тривиальную.
Большинство этих моих комментариев исчезнут, когда я опубликую краткий «ответ», поскольку он объединит соответствующие биты в краткий обзор. До тех пор приветствуются дополнительные предложения.

Ответы (1)

Распространитель SGP4 на самом деле не использует день года (только время, прошедшее с эпохи), поэтому значение выше 366 вполне нормально. Некоторые люди могут добавить некоторые проверки в TLE, чтобы вызвать это как ошибку, но сам распространитель не увидит в этом проблемы. Кроме того, если вы хотите увидеть, сколько «времени с начала эпохи» находится между эпохой TLE и заданной датой, у вас могут возникнуть проблемы с использованием одного такого TLE, но опять же, это не проблема ни с TLE, ни с SGP4.

Я предполагаю, что проблема связана с программным обеспечением для генерации TLE (которое не раскрывается NORAD). Они, вероятно, распространяют орбиту МКС в будущее, используя более совершенные численные методы, и подгоняют TLE к сочетанию фактических и распространяемых положений, но помещают эпоху близко к концу окна подгонки. Возможно, в зависимости от того, какой длины должно быть окно и когда был сгенерирован TLE, они в конечном итоге сгенерируют эпоху, которая происходит «в следующем году», но поле года не затрагивается программным обеспечением, только день поле года.

Другой скрипт/программа мог исправить это, и, возможно, программное обеспечение/сервер было перемещено или обновлено, и, возможно, кто-то не заметил, что он нужен или что он не работает. Возможно, кто-то отключил его для повышения производительности, потому что он «никогда» не нужен и забыл включить его снова.

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

+1«Распространитель SGP4 на самом деле не использует день года (только время с начала эпохи)…» Ого, до сих пор я никогда не осознавал этого до конца! Да, быстрая проверка отчета Revisiting Spacetrack Report № 3 показывает только зональные гармоники (J2, J3, J4) и никаких тессералов, которые затем потребовали бы знания абсолютного времени и модели вращения Земли, а выражения всегда расширяются относительно (t -t_ноль).
Что ж, в последнее время я был занят и теперь вижу это, это около 3/4 того, что я сейчас редактирую примерно в четвертый раз. Так что, похоже, мы все в целом на одной волне. Я делаю несколько графических примеров, чтобы еще больше подчеркнуть суть, но это может не публиковаться в течение недели. И я беру идеальную эпоху эпохи TLE в годы, чтобы приблизить дату года к 999, чтобы увидеть, как это работает, и снова показать, что эпоха — это в основном моментальный снимок момента времени. Как сообщает spacetrack rpt3, некоторые его компоненты для глубоких орбит используют смещение 1950 января 0,0 для учета гравитации Солнца и Луны.
... И повторяющаяся переменная TSINCE в коде большинства подпрограмм на фортране IV. Определяющий момент времени и время с этого момента, определяющее текущий интересующий момент времени.
Что вызвало проблему с двумя линейными элементами на МКС, начавшуюся 24 декабря 2019 г.?
СпросиСетьПолитика конфиденциальности1y, 0v