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 # 2013 年 1 月 1 日 0000 UTC 0N 0E 月亮的 RA/DEC 使用 Astro::Nova； # 1356998400 == 2013 年 1 月 1 日 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"; 结果：141.320712606865,9.76909442356909

- Second, Python and pyephem:

#!/usr/local/bin/python # 2013 年 1 月 1 日 0000 UTC 0N 0E 月亮的 RA/DEC 导入 ephem； e = ephem.Observer(); e.date = '2013/01/01 00:00:00'; 月亮 = ehem.Moon();月亮.计算（e）；打印moon.ra、moon.dec 结果：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. 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

这至少比以前更近了。请注意，如果您希望它像您要求 Horizo​​ns 那样忽略折射，您可能还希望在您的 PyEphem 代码中执行此操作；虽然对于这个特殊的观察，我认为它没有任何区别：

e.pressure = 0

任何残余差异都可能（但不是绝对的；可能还有其他我现在没有发生的错误来源）由于不同的程序使用不同的公式来预测行星的位置。 PyEphem 使用旧的但流行的 VSOP87。 Horizo​​ns 使用更新更近且更准确的 DE405 和 DE406，如其输出中所述。不知道其他产品用的是什么型号的太阳系。