pyephem, libnova, stellarium, JPL Horizons nie zgadzają się na księżycu RA/DEC?

Question

Drobna edycja: poniżej podaję, że biblioteka JPL's Horizons nie jest open source. Właściwie, to jest, i jest dostępna tutaj: http://naif.jpl.nasa.gov/naif/tutorials.html

Na 2013-01-01 00:00:00 UTC 0 stopni szerokości geograficznej północnej, 0 stopni na wschód szerokości geograficznej, wysokości poziomu morza, co jest J2000 epoki rektascensją i deklinacja księżyca?

Niestety, różne biblioteki podają nieco inne odpowiedzi. Przeliczone do stopni, podsumowanie wyników (RA pierwszy):

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] 

Moje pytanie: dlaczego? Uwagi:

• Zdaję sobie sprawę, te różnice są małe, ale:

  • używam pyephem i libnova obliczyć Słońce/Księżyc wzrost/set, a te czasy mogą być bardzo wrażliwe na stanowisko w wyższe szerokości geograficzne (np. słońce o północy).

  • Rozumiem, że biblioteka JPL Horizons nie jest open source, , ale pozostałe trzy są. Czy ktoś nie powinien interpretować różnic w tych bibliotekach i łączyć je? To jest moja główna skarga . Czy autorzy biblioteki stellarium/pyephem/libnova mają podstawową różnicę w sposobie wykonywania tych obliczeń, czy też potrzebują tylko scalić swój kod?

• ja też sobie sprawę, że może być inne powody Obliczenia inna i będzie wdzięczna za każdą pomoc w uzupełnianiu tych ewentualne błędy:

  • Pyephem i Libnova mogą używać epokę data zamiast J2000

  • Księżyc jest na tyle blisko, że lokalizacja obserwatora może wpłynąć na jego RA/DEC (efekt paralaksy).

  • Używam Perl's Astro :: Nova i Python's pyephem, a nie oryginalne implementacje C tych bibliotek. Jeśli jednak te różnice są spowodowane użyciem Perla/Pythona, to jest to ważne w mojej opinii.

• Mój kod (w/surowe wyniki):

  • pierwsze, Perl i 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 Horizons wymaga danych POST (nie bardzo, ale udawać), więc nie mógł umieścić URL].

• I nie je (leniwy) powiązane, ale wierzę, że istnieje wiele pytań bez odpowiedzi na StackOverflow, które skutecznie redukują do pytanie (niespójność precyzyjnych bibliotek astronomicznych), tym niektóre z moich pytań .

• gram w te rzeczy pod adresem: https://github.com/barrycarter/bcapps/tree/master/ASTRO

Answer 1

Nie mam pojęcia, co robi Stellarium, ale myślę, że wiem o pozostałych trzech. Masz rację, że tylko Horizons używa J2000 zamiast epoki-daty dla tej pozornej, specyficznej dla lokalizacji obserwacji. Możesz go zamknąć w ścisłej zgodności z PyEphem, klikając "zmień" obok "Ustawienia tabeli" i zmieniając z "1. Astrometryczny RA & DEC" na "2. Pozorny RA & DEC."

Różnica w stosunku do Libnova jest trochę trudniejsza, ale moje późniejsze przypuszczenia wskazują, że Libnova używa UT zamiast czasu Ephemeris, więc aby PyEphem dał taką samą odpowiedź, którą musisz przekonwertować z jednego razu na drugi:

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 

This wyjścia:

141.320681918 9.77023197401 

Która jest, co najmniej, znacznie bliżej niż poprzednio. Zauważ, że możesz również chcieć to zrobić w swoim kodzie PyEphem, jeśli chcesz, aby ignorował refrakcję, tak jak prosiłeś Horyzonty; chociaż dla tej konkretnej obserwacji nie widzę to żadnej różnicy:

e.pressure = 0 

Wszelkie resztkowa różnica jest prawdopodobnie (ale nie na pewno, mogą istnieć inne źródła błędów, które nie są występujące na mnie teraz) ze względu na różne programy używające różnych formuł do przewidywania, gdzie będą planety. PyEphem używa starego, ale popularnego VSOP87. Horizons używa znacznie nowszych - i dokładniejszych - DE405 i DE406, jak podano w jego wynikach. Nie wiem, jakie modele układu słonecznego używają inne produkty.