astronomy - pyephem，libnova，stellarium，JPL Horizo​​ns在月球RA/DEC上存在分歧？

Question

轻微的编辑:我在下面说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数据(不是真的，而是假装的，所以我
无法发布网址]。

我没有链接他们(懒惰)，但我相信有很多人
关于stackoverflow的未解决问题，有效地减少为
这个问题(精密天文资料库的不一致)，
包括我自己的一些问题。

我在以下位置玩这个东西:https://github.com/barrycarter/bcapps/tree/master/ASTRO

Answer 1

我不知道恒星在做什么，但我想我对其他三个都了解。您是正确的，只有Horizo​​ns才使用J2000，而不是该特定于区域设置的明显观察日期。您可以通过单击“表设置”旁边的“更改”并将其从“1. Astrometric RA＆DEC”切换到“2. Apparent 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。我不知道其他产品使用的太阳能系统型号。