Pyephem преобразование (Alt, Az) в (Ra, Dec) и обратно не соответствует внутреннему

Я обнаружил, что когда я конвертирую (Alt, Az) в (Ra, Dec) и затем возвращаюсь с PyEphem, я не понимаю, с чего я начал. Ниже приведен простой пример.

import ephem
print ephem.__version__
# '3.7.3.4'

gbt = ephem.Observer()
gbt.long = '-79:50:23.4'
gbt.lat = '38:25:59.23'
gbt.pressure = 0 # no refraction correction.
gbt.epoch = ephem.J2000
# Set the date to the epoch so there is nothing changing.
gbt.date = '2000/01/01 12:00:00'

# Should get the north pole right?
ra, dec = gbt.radec_of(0, '38:25:59.23')
# Not the north pole... error might be abberation.
print dec
# 89:59:30.5

# Now check internal consistancy by reversing the calculation.
pole = ephem.FixedBody()
pole._ra = ra
pole._dec = dec
pole._epoch = ephem.J2000
pole.compute(gbt)
# Should get what I started with right?
alt = pole.alt
# Not what I started with... error unknown.
print alt
# 38:26:26.7

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

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

Источник

2 ответа

Решение

Результат, который вы получаете, отключен из-за аберрации и нутации. Если вы должны были скомпилировать PyEphem самостоятельно и закомментировать строки 271 и 272 строк circum.h тогда вы обнаружите, что вы получите именно тот результат, который ожидаете - с этими изменениями код будет выглядеть так:

    /* correct EOD equatoreal for nutation/aberation to form apparent 
     * geocentric
     */
    /* nut_eq(mjed, &ra, &dec); */
    /* ab_eq(mjed, lsn, &ra, &dec); */
    op->s_gaera = ra;
    op->s_gaedec = dec;

Когда вы просите PyEphem "вернуться назад" от наблюдаемого RA и перейти в положение неба позади них, он просто меняет преломление (которое вы уже отключили) и прецессию, чтобы получить ответ.

Почему это останавливается там? Почему он не пытается обратить нутацию и аберрацию? (Помимо практической причины: эти величины оцениваются с помощью дорогих полиномов, которые нельзя легко перевернуть!)

Причина, по которой он не пытается выполнить обратную компенсацию нутаций и аберраций, состоит в том, что он не знает дальности до объекта, который находится в RA, и dec, о котором вы спрашиваете. Если вы спрашиваете об этом RA и dec, потому что вы видели, например, спутник, проходящий над головой, тогда аберрация не будет иметь значения - спутники Земли движутся в той же релятивистской системе отсчета, что и Земля - ​​и нутация также не будет иметь значения, поскольку вы не будете интересоваться, где "идеальный" полюс Земли указывает - вас будет интересовать, куда указывал полюс в ту ночь, когда вы смотрели вверх и наблюдали за спутником, пролетающим над головой.

Поэтому, не зная, является ли объект, который вы видели, спутником Земли, или Луной, или планетой в другом релятивистском каркасе Солнечной системы, или чем-то еще дальше, библиотека "libastro" делает самую простую вещь и останавливается там вместо того, чтобы придумывать ответ с обратными эффектами, которые могут даже не относиться к вашей ситуации. Однако я буду помнить об этом, когда подхожу к следующей версии PyEphem и думаю о том, radec_of() методы могут не подходить.

Источник

Моя версия 4.1. Я только что протестировал код и получил тот же результат.

      alt:38:26:26.7

Затем я отрегулировал входной альт-угол на 10 футов от вехи. Тогда это дало гораздо лучший результат.

      ra, dec = gbt.radec_of(0, '38:35:59.23')
alt: 38:35:59.2

Может быть, в поул-позиции точность падает естественно. А когда он находится далеко от столба, точность возвращается к норме.

Источник
Другие вопросы по тегам