pyephem, libnova, stellarium, JPL Horizons non sono d'accordo sulla luna RA/DEC?

Question

EDIT MINORE: Dico qui sotto che la libreria Horizons di JPL non è open source. In realtà, è, ed è disponibile qui: http://naif.jpl.nasa.gov/naif/tutorials.html

A 2013-01-01 00:00:00 UTC a 0 gradi di latitudine nord, 0 gradi est latitudine, livello di elevazione del mare, qual è il J2000 quest'epoca ascensione retta e declinazione della luna?

Purtroppo, le diverse librerie danno risposte leggermente diverse. Convertito per gradi, i risultati riassunti (RA): prima

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] 

La mia domanda: perché? Note:

• Mi rendo conto che queste differenze sono piccole, ma:

  • Io uso pyephem e libnova per il calcolo del sole/luna rise/set, e questi tempi possono essere molto sensibile alla posizione in latitudini più elevate (ad esempio, il sole di mezzanotte).

  • Posso capire che la libreria Horizons di JPL non è open source, ma gli altri tre lo sono. Non dovrebbe qualcuno risolvere le differenze in queste librerie e unirle? Questo è il mio reclamo principale . Gli autori delle librerie stellarium/pyephem/libnova hanno una differenza fondamentale in come eseguire questi calcoli, oppure fanno hanno solo bisogno di unire il loro codice?

• realizzo anche ci potrebbero essere altri motivi i calcoli sono differente, ed apprezzerei tutto l'aiuto nella rettifica questi possibili errori:

  • Pyephem e libnova possono utilizzare l'epoca di la data invece di J2000

  • La luna è abbastanza vicina che la posizione dell'osservatore può influire sul suo effetto di parallasse RA/DEC.

  • Sto usando il python di Perl Astro :: Nova e Python, non le implementazioni originali C di queste librerie. Tuttavia, se queste differenze sono causate dall'uso di Perl/Python, ciò è importante in la mia opinione.

• Il mio codice (w/risultati grezzi):

  • In primo luogo, Perl e 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 richiede dati POST (non proprio, ma finta), così ho non poteva inviare un URL].

• io non li (pigro) hanno messo in relazione, ma credo che ci sono molte domande senza risposta su StackOverflow che riducono efficacemente a questa domanda (inconsistenza di precisione biblioteche astronomiche), tra cui alcune delle mie domande .

• sto giocando w questa roba a: https://github.com/barrycarter/bcapps/tree/master/ASTRO

Answer 1

Non ho idea di quello che sta facendo Stellarium, ma penso che so gli altri tre. Hai ragione sul fatto che solo Horizons sta usando J2000 invece dell'epoca di data per questa apparente osservazione specifica locale. Puoi metterlo in stretto accordo con PyEphem facendo clic su "modifica" accanto a "Impostazioni tabella" e passando da "1. Astrometrica RA & DEC" a "2. Apparente RA & DEC".

La differenza con libnova è un po 'più complicato, ma la mia tarda notte ipotesi è che libnova utilizza UT invece di Ephemeris tempo, e in modo da rendere PyEphem dare la stessa risposta è necessario convertire da un tempo all'altro:

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 

Questo uscite:

141.320681918 9.77023197401 

che è, almeno, molto più vicino di prima. Nota che potresti anche voler farlo nel tuo codice PyEphem se vuoi che ignori la rifrazione come hai chiesto a Horizons; anche se per questo particolare l'osservazione non sto vedendo la situazione sia diversa:

e.pressure = 0 

eventuale differenza residua è probabilmente (ma non sicuramente, ci potrebbero essere altre fonti di errore che non si stanno verificando a me in questo momento) a causa della diversi programmi che utilizzano formule diverse per prevedere dove saranno i pianeti. PyEphem usa il vecchio ma popolare VSOP87. Horizons usa il molto più recente - e preciso - DE405 e DE406, come dichiarato nel suo output. Non so quali modelli del sistema solare usano gli altri prodotti.