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 дюймов.

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


python astronomy coordinate-transformation pyephem
person kiyo    schedule 15.08.2012    source источник
comment
Вы уверены, что нет путаницы между планетографическими и планетоцентрическими широтами?   -  person DarenW    schedule 11.09.2012
comment
Еще одно дикое предположение, что с эпохой какие-то проблемы. Возможно, _epoch следует установить перед _ra и _dec из-за некоторых (недокументированных?) внутренних вычислений, которые происходят. OTOH, это безумие, поскольку по умолчанию используется J2000. Тем не менее, высокоточная астрономия требует некоторой паранойи, так что это следует перепроверить.   -  person DarenW    schedule 11.09.2012
comment
Смешение планетографии и планетоцентрической широты могло бы объяснить первую проблему, но я не думаю, что это объясняет, почему они внутренне не согласованы. Этого нет в документации, но кто-нибудь знает, какие числа должны быть указаны в каких координатах? Ра и дек, конечно, были бы планетоцентрическими. Широта, долгота, альт и аз планетографические?   -  person kiyo    schedule 12.09.2012

Ответы (1)


arrow_upward
3
arrow_downward

Полученный результат неверен из-за аберрации и нутации. Если бы вы сами скомпилировали 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 и склонении, потому что видели, например, спутник, проходящий над головой, то аберрация не имеет значения — спутники Земли движутся в той же релятивистской системе отсчета, что и Земля — и нутация также не имеет значения, поскольку вы не будете интересуйтесь, куда указывает «идеальный» полюс Земли — вас должно интересовать, куда указывал полюс в ту конкретную ночь, когда вы смотрели вверх и наблюдали за спутником, пролетающим над головой.

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

person Brandon Rhodes    schedule 19.09.2012
comment
Спасибо за объяснение. Разве pole = ephem.FixedBody() не означает, что это далекий источник? - person kiyo; 07.01.2013
comment
Да, FixedBody действительно обрабатывается как удаленный источник. Но вызов radec_of() не знает, что его спрашивают о фиксированном теле, поэтому он не выполняет всю «удаленную» обработку. - person Brandon Rhodes; 09.01.2013