pyephem, libnova, stellarium, JPL Horizons는 달의 RA/DEC에 동의하지 않습니까?

Question

사소한 편집 : JPL의 Horizons 라이브러리는 오픈 소스가 아닙니다. 실제로, 여기에 있습니다 : http://naif.jpl.nasa.gov/naif/tutorials.html

위도 0도에서 북위 0도, 0도 동쪽 위도, 해발 고도, J2000 신기원 적중률은 얼마입니까? 과 달의 적위?

슬프게도 다른 라이브러리는 약간 다른 답변을 제공합니다. 도에 를 변환, 요약 된 결과 (RA 첫번째) :

Stellarium: 141.9408333000, 9.8899166666 [precision: .0004166640, .0000277777] 
Pyephem: 142.1278749990, 9.8274722221 [precision .0000416655, .0000277777] 
Libnova: 141.320712606865, 9.76909442356909 [precision unknown] 
Horizons: 141.9455833320, 9.8878888888 [precision: .0000416655, .0000277777] 

내 질문 : 왜? 참고 :

• 나는이 차이가 작은 알지만 :

  • 나는 태양/달 상승/세트를 계산하기 위해 pyephem 및 libnova를 사용하고 이 배의 위치에 매우 민감 할 수있다 고위도 (예 : 한밤중의 태양).

  • JPL의 Horizons 라이브러리는 오픈 소스가 아니기 때문에 이지만 다른 3 가지는 있습니다. 누군가이 라이브러리에서 차이점을 찾아서 병합해서는 안됩니까? 내 메인 불만입니다. stellarium/pyephem/libnova 라이브러리 작성자가 이 계산을하는 방법의 근본적인 차이점이 있거나 코드를 병합하기 만하면됩니까? 나는 또한 계산 다른 다른 이유가있을 수 있습니다 실현, 이러한 가능한 오류를 정류에 어떤 도움을 주셔서 감사합니다 것

• :

  • Pyephem 및 Libnova이 시대의를 사용하고있을 수 있습니다

    날짜 대신 J2000

  • 달이 충분히 가까워서 관찰자 위치가 RA/DEC (시차 효과)에 영향을 미칠 수 있습니다.

  • 저는 Perl의 Astro :: Nova와 Python의 pyephem을 사용하고 있습니다.이 라이브러리의 원래 C 구현은 이 아닙니다. 그러나이 차이점이 Perl/Python을 사용하여 발생하면 에서 중요합니다.

• 내 코드 (원시 결과/w) :

  • 첫째, Perl과 천체 :: 노바 :

 

#!/bin/perl 

# RA/DEC of moon at 0N 0E at 0000 UTC 01 Jan 2013 
use Astro::Nova; 
# 1356998400 == 01 Jan 2013 0000 UTC 
$jd = Astro::Nova::get_julian_from_timet(1356998400); 
$coords = Astro::Nova::get_lunar_equ_coords($jd); 
print join(",",($coords->get_ra(), $coords->get_dec())),"\n"; 

RESULT: 141.320712606865,9.76909442356909 

- Second, Python and pyephem: 

 
#!/usr/local/bin/python 

# RA/DEC of moon at 0N 0E at 0000 UTC 01 Jan 2013 
import ephem; e = ephem.Observer(); e.date = '2013/01/01 00:00:00'; 
moon = ephem.Moon(); moon.compute(e); print moon.ra, moon.dec 

RESULT: 9:28:30.69 9:49:38.9 

- The JPL Horizons result (snapshot): 

은 [JPL 호라이즌 (정말,하지만 척) POST 데이터를 요구한다, 그래서 나는 URL을 게시 할 수 없습니다].

• 내가 그들을 (게으른)에 연결하지 않은,하지만 난 내 자신의 몇 가지 질문을 포함하여 많은 답이 효과적으로 에이 질문 (정밀 천문학적 인 라이브러리의 불일치를) 감소 유래에 대한 질문, 가 생각

  . 나는 스텔라 리움이 무엇을하고 있는지 모른다는 https://github.com/barrycarter/bcapps/tree/master/ASTRO

Answer 1

,하지만 난 다른 세에 대해 알고 있다고 생각 :

난에이 물건 승 재생하지거야. Horizons만이 명백한 로케일 특정 관찰을 위해 기원일 대신 J2000을 사용하고 있다는 것이 맞습니다. '테이블 설정'옆의 '변경'을 클릭하고 'Astrometric RA & DEC'에서 '2. Apparent RA & DEC'로 전환하여 PyEphem과 긴밀한 협의를 할 수 있습니다.

Libnova와의 차이점은 좀 더 까다 롭습니다.하지만 늦은 밤 추측은 Libnova가 Ephemeris Time 대신 UT를 사용하므로 PyEphem이 한 번에 다른 것으로 변환해야하는 동일한 대답을 제공하게 만드는 것입니다.

import ephem 
moon, e = ephem.Moon(), ephem.Observer() 
e.date = '2013/01/01 00:00:00' 
e.date -= ephem.delta_t() * ephem.second 
moon.compute(e) 
print moon.a_ra/ephem.degree, moon.a_dec/ephem.degree 

이 출력 :

, 적어도 이전보다 훨씬 가까운

141.320681918 9.77023197401 

. Horizons에게 요청한 것처럼 굴절을 무시하기를 원한다면 PyEphem 코드에서이 작업을 수행 할 수도 있습니다. 때문에에 (지금 나에게 발생하지 않는 오류의 다른 소스가있을 수 확실히 아니지만)

e.pressure = 0 

잔여 차이는 아마도이 특정 관찰 나는 그것이 어떤 차이를 만들어보고 있지 않다하더라도 다른 프로그램은 행성이 어디에 있는지 예측하기 위해 다른 수식을 사용합니다. PyEphem은 오래되었지만 인기있는 VSOP87을 사용합니다. Horizons는 출력에서 ​​언급 한 것처럼 훨씬 더 최근의 정확한 DE405 및 DE406을 사용합니다. 나는 다른 제품들이 사용하는 태양계의 모델을 모른다.