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

标签 astronomy

轻微的编辑:我在下面说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
  • 最佳答案

    我不知道恒星在做什么,但我想我对其他三个都了解。您是正确的,只有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。我不知道其他产品使用的太阳能系统型号。

    关于astronomy - pyephem,libnova,stellarium,JPL Horizo​​ns在月球RA/DEC上存在分歧?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16293146/

    相关文章:

    javascript - 将给定观察者位置的太阳路径转换到谷歌地图上

    python - 使用 Python 的耦合微分方程

    algorithm - 给定一个日期时间,计算太阳直接在头顶的纬度/经度坐标

    c - Long double 足够大,可以像太阳-冥王星那样存储一个白色毫米精度的距离吗?

    python - 无法导入 pyspeckit

    astronomy - 破解 FITs 图像标题

    javascript - 如何使用javascript计算太阳下点的纬度(即太阳赤纬)?

    c# - 将世界坐标系转换为笛卡尔坐标的问题

    python - 确定天空中的 eclipse