Как найти среднее боковое время по Гринвичу?

Я пишу программу, которая преобразует положение в системе координат ECI (CIS, EPOCH JD2000.0) в координаты WGS 84 (CTS, ECEF). Для этого я следую тому, что описано в этом документе , и реализую код C++.

Мои познания в астрофизике очень ограничены, поэтому мне трудно понять некоторые термины. В частности, я не могу правильно понять, как вычисляется среднее по Гринвичу боковое время и почему я всегда получаю разные значения.

Например (при условии, что время 2019-01-01 08:00:00и дата по юлианскому календарю равны 2458484.833333):

  • Если я воспользуюсь этим онлайн- калькулятором GMST , я обнаружу, что GMST равен 14:42:45.3766.
  • Если я использую выражение, используемое в этом скрипте MATLAB (показывающее значение во времени, а не в градусах), я также получаю 14:42:45.350.
  • Однако, если я вычислю его сам с помощью выражения, приведенного в приложении выше, я получу 06:42:45.379163(с явным смещением

Согласно уравнениям на странице A-26, GMST зависит от количества юлианских столетий (Tu). Выражение H0 точно такое же, как у CelesTrak для θ(0h). Однако я не могу понять, что на самом деле означает du , или, точнее, почему в документе показано du → ±0.5, 1.5, 2.5.... Более того, чтобы найти Λ (которое указано в секундах времени ), в выражениях нечетко используются значения в радианах и секундах времени.

Может ли кто-нибудь пролить свет на это?

Ответы (2)

Для этого я следую тому, что описано в этом документе , и реализую код C++.

Вы используете очень старый документ. Он использует прецессионную модель IAU 1982 года. С тех пор было несколько обновлений. Последний набор изменений направлен на устранение концепции звездного времени по Гринвичу. (С точки зрения программного обеспечения, GMST и GAST являются устаревшими концепциями. Несмотря на то, что они все еще поддерживаются в настоящее время, поддержка будет прекращена в некоторых будущих версиях модели вращения Земли.)


Помимо использования устаревшей версии устаревшей концепции, что вы сделали не так? Выражение, которое вы используете для вычисления GMST, находится вверху страницы A-26:

Λ знак равно ЧАС 0 + Δ ЧАС + ю * ( т Δ т )
The Δ ЧАС термин занимает один от GMST до GAST. Отбросив этот термин, выражение для GMST будет
(1) ЧАС знак равно ЧАС 0 + ю * ( т Δ т )
куда
(2) ЧАС 0 знак равно 24110.54841 + 8640184.812866 Т ты + 0,093104 Т ты 2 6.2 × 10 6 Т ты 3 звездное время по Гринвичу в полночь, в секундах времени (3) ю * знак равно 7.2921158553 × 10 5 + 4.3 × 10 15 Т ты - звездная скорость вращения Земли в радианах. / второй т Δ время дня UTC в секундах и Δ т разница между UT1 и UTC.

Обратите внимание, что в уравнении (1) есть несоответствие единиц измерения. Уравнение (2) дает результат в звездных секундах, а уравнение (3), умноженное на время суток, дает результат в радианах. Последнее необходимо преобразовать в звездные секунды. Для этого просто умножьте оба члена в уравнении (3) на 86400 2 π :

(4) ю * знак равно 1.00273790935 + 5.9 × 10 11 Т ты - звездная скорость вращения Земли в звездных секундах. / UT секунда

Применив это к 01 января 2019 года, 08:00:00 UTC, мы получим следующее:

  • Юлианская дата в полночь UTC 01 января 2019 г. 2458484,5 , или 2451545 + 6939,5 . См. сноску 1 для объяснения этого соглашения.
  • Разделение остатка 6939,5 на 36525 дает Т ты : Т ты знак равно 6939,5 / 36525 знак равно 0,1899931553730322 .
  • Применение уравнения (2) дает среднее звездное время по Гринвичу в полночь: ЧАС 0 знак равно 1665686.527373333 звездные секунды.
  • Применяя уравнение (4) и умножая на т знак равно 8 * 3600 секунды дает еще 28878,85178960284 звездных секунды к приведенному выше. Как насчет Δ т , он же dUT1? Я проигнорировал его (т. е. обработал его так, как если бы он был равен нулю). См. сноску 2.
  • 1665686,527373333 + 28878,85178960284 = 52965,37916293584 (по модулю 86400). Это среднее звездное время в секундах. Преобразование в часы, минуты и секунды дает 14:42:45,4. 0,4 секунды являются поддельными, потому что я проигнорировал dUT1.

Сноски:

  1. Существует проблема с использованием дат по юлианскому календарю для выражения времени, когда важна высокая точность. Проблема в том, что добавление 2,45 миллиона и изменение времени с полудня 1 января 2000 года приводит к потенциальным проблемам с усечением. Следующая представимая дата по юлианскому календарю после полуночи 1 января 2000 года — это 40 микросекунд после полуночи. Сам я стараюсь держаться на пару порядков в стороне от уровня квантования, что означает проблемы для дат на миллисекундном уровне.

    Почти каждый научный пакет, поддерживающий даты по юлианскому календарю, либо использует пару чисел с двойной точностью, либо использует какую-то модифицированную дату по юлианскому календарю, например, время с 12 часов дня 16 ноября 1858 года (опускает первые 2,4 миллиона в дате по юлианскому календарю), время с 12 часов дня 23 года. Май 1968 г. (без учета первых 2,44 миллиона) или время, прошедшее с J2000.

  2. Семестр Δ т в уравнениях (2) и (4) более известен как dUT1. В этом разница между UT1 (время, использующее среднее вращение Земли в качестве часов) и UTC (время, которое работает с той же скоростью, что и атомные часы, но иногда с дополнительными секундами, чтобы синхронизировать UT1 и UTC). Эти високосные секунды | УТ1 универсальное глобальное время | < 0,9 секунды . Просто игнорируйте Δ т термин, если это так, но помните, что доли секунды бессмысленны.

Спасибо за исчерпывающий ответ, он действительно помог! Я, наконец, нашел проблему, которая вызывала неправильное преобразование координат, и, к сожалению для этого форума, она попала в область неправильного преобразования единиц измерения и знаковых операций. Я планирую загрузить свой код C++, чтобы внести небольшой вклад, но я хотел бы знать, какая будет текущая/подходящая модель для использования, если не эта устаревшая. Не могли бы вы предоставить ссылку?
@CarlesAraguz -- Две ссылки! Одной из них является конвенция Международной службы вращения Земли и систем отсчета (IERS), описанная в Техническом примечании 36 IERS . Обратите особое внимание на главы 4 и 5. Другой — это программное обеспечение с открытым исходным кодом Standards of Fundamental Astronomy (SOFA), поддерживаемое Международным астрономическим союзом (IAU) на iausofa.org . Если вы покопаетесь, вы увидите множество функций на C и Fortran, а также несколько «поваренных книг » .
просто вопрос @David Hammen В уравнении (3), чтобы преобразовать из радианов в звездные секунды, выражение не следует умножать на 86164/2π, где 86164 - количество секунд в одном звездном дне? (t−Δt) находится в звездных секундах (даже если Δt игнорируется), поскольку t(UTC) и Δt(UTC-UT1). Таким образом, результат не должен быть по модулю 86164? Извините, но я не мог ответить с комментарием
@binghy - Умножение на 86164 2 π было бы неправильно. ( т Δ т ) дает секунды UT1, а не звездные секунды. (Если бы вы уже знали время в звездных секундах, игра была бы окончена; весь смысл этого упражнения состоит в том, чтобы преобразовать время UTC в звездное время.) Умножение значения в единицах радианы UT секунда от 86400 UT секунд / солнечный день 2 π радианы / звездная революция преобразует это значение в единицы звездные обороты солнечный день . Это эквивалентно единицам звездных секунд за секунду UT.

Я вычислил GMST, используя метод, описанный в http://aa.usno.navy.mil/faq/docs/GAST.php . Это должен быть авторитетный источник с точностью до 0,1 секунды.

В псевдокоде:

midnight = floor(2458484.833333) + 0.5            // J0 = 2458484.5
days_since_midnight = 2458484.833333 - 2458484.5  // = 0.333333
hours_since_midnight = 0.333333 * 24              // H = 8.0
days_since_epoch = 2458484.833333 - 2451545.0     // D = 6939.833333
centuries_since_epoch = days_since_epoch / 36525  // T = 0.190002
whole_days_since_epoch = 2458484.5 - 2451545.0    // D0 = 6939.5

GMST = 6.697374558 
     + 0.06570982441908 * whole_days_since_epoch 
     + 1.00273790935 * hours_since_midnight
     + 0.000026 * centuries_since_epoch**2        //=470.712605328

GMST_hours = 470 % 24 // = 14
GMST_minutes =  floor(0.712605328 * 60) //=42(.7563197)
GMST_seconds =  0.7563197*60 // =45.38

Этот расчет согласуется с онлайн-калькулятором. Метод здесь (или как описано по ссылке) должен быть прост в реализации.

Джеймс. Незначительная ошибка в вашем псевдокоде: в вашем окончательном расчете для GMST вы показываете переменную hours_since_epoch. Это должно быть hours_since_midnight.
@RobertSmith вылечен.