10

軽微な編集: 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 ライブラリがオープン ソースでないことは理解できますが、他の 3 つのライブラリはオープン ソースです。誰かがこれらのライブラリの違いを解決してマージするべきではありませんか? これが私の主な不満です。stellarium/pyephem/libnova ライブラリの作成者は、これらの計算を行う方法に根本的な違いがありますか?それとも、コードをマージする必要があるだけですか?

  • また、計算が異なる他の理由がある可能性があることも認識しており、これらの考えられるエラーを修正するための助けをいただければ幸いです。

    • Pyephem と Libnova は、J2000 の代わりに日付のエポックを使用している可能性があります

    • 月は、観測者の位置が赤経/赤緯 (視差効果) に影響を与えるほど十分に近いです。

    • これらのライブラリの元の C 実装ではなく、Perl の Astro::Nova と Python の pyephem を使用しています。ただし、これらの違いが Perl/Python を使用することによって引き起こされる場合、それは私の意見では重要です。

  • 私のコード（生の結果付き）：

    • まず、Perl と Astro::Nova:
#!/ビン/perl

# 2013 年 1 月 1 日 0000 UTC 0N 0E の月の赤経/赤緯
Astro::Nova を使用します。
# 1356998400 == 2013 年 1 月 1 日 0000 UTC
$jd = アストロ::ノヴァ::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 の月の赤経/赤緯
エフェムをインポートします。e = ephem.Observer(); e.date = '2013/01/01 00:00:00';
月 = ephem.Moon(); moon.compute(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 を投稿できませんでした]。

4

1 に答える 1