pyephem,libnova,stellarium,JPL Horizo​​ns在月球RA/DEC上意见不一致？

Question

MINOR EDIT:我在下面说JPL的Horizo​​ns库不是开源的.实际上,它是,它可以在这里找到:http://naif.jpl.nasa.gov/naif/tutorials.html

在2013-01-01 00:00:00 UTC在北纬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的Horizo​​ns库不是开源的,但其他三个是.难道不应该有人解决这些库中的差异并合并它们吗？这是我的主要抱怨.stellarium/pyephem/libnova库作者在如何进行这些计算方面有根本的区别,还是只需要合并他们的代码？

• 我也意识到可能还有其他原因导致计算结果不同,并希望在纠正这些可能的错误时提供任何帮助:

  • Pyephem和Libnova可能正在使用日期的纪元而不是J2000

  • 月球足够近,观察者位置可以影响其RA/DEC(视差效应).

  • 我正在使用Perl的Astro :: Nova和Python的pyephem,而不是这些库的原始C实现.但是,如果这些差异是由使用Perl/Python引起的,那么在我看来这很重要.

• 我的代码(带原始结果):

  • 首先,Perl和Astro :: Nova:

#!/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 stellarium result (snapshot): 

- The JPL Horizons result (snapshot): 

[JPL Horizo​​ns需要POST数据(不是真的,但是假装),所以我无法发布URL].

• 我还没有将它们联系起来(懒惰),但我相信在stackoverflow上有许多未解决的问题可以有效地减少这个问题(精确天文库的不一致性),包括我自己的一些问题.

• 我在玩这个东西:https://github.com/barrycarter/bcapps/tree/master/ASTRO

Answer 1

我不知道Stellarium在做什么,但我想我知道其他三个.你是对的,只有Horizo​​ns使用J2000而不是这个明显的,特定于语言环境的观察的时代.您可以通过单击"表格设置"旁边的"更改"并从"1.天体测量RA&DEC"切换到"2.表观RA和DEC",使其与PyEphem达成密切协议.

与Libnova的区别有点棘手,但我深夜的猜测是Libnova使用UT代替Ephemeris Time,所以为了让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

这至少比以前更接近.请注意,您可能还希望在PyEphem代码中执行此操作,如果您希望忽略折射,就像您要求Horizo​​ns一样; 虽然对于这个特殊的观察我并没有看到它有任何区别:

e.pressure = 0

由于不同的程序使用不同的公式来预测行星的位置,因此任何剩余差异可能(但不是绝对;可能还有其他错误来源,我现在没有发生).PyEphem使用旧的但流行的VSOP87.Horizo​​ns使用了更新近 - 而且确切 - DE405和DE406,如其输出中所述.我不知道其他产品使用什么型号的太阳能系统.