pyephem, libnova, stellarium, JPL Horizons stimmt nicht mit Mond RA / DEC überein?

8

MINOR EDIT: Ich sage unten, dass JPLs Horizons-Bibliothek nicht Open Source ist. Tatsächlich ist es, und es ist hier verfügbar: Ссылка

Am 01.01.2013 00:00:00 UTC bei 0 Grad nördlicher Breite, 0 Grad östlicher Breite Breitengrad, Meeresspiegelhöhe, was ist die J2000 Epoche Rektaszension und Deklination des Mondes?

Leider geben verschiedene Bibliotheken leicht unterschiedliche Antworten. Umgewandelt zu Abschlüssen, die zusammengefassten Ergebnisse (RA zuerst):

%Vor%

Meine Frage: Warum? Hinweise:

  • Ich erkenne, dass diese Unterschiede klein sind, aber:

    • Ich benutze pyephem und libnova, um Sonne / Mond zu berechnen Diese Zeiten können sehr empfindlich für die Position in höheren Breiten sein (zB Mitternachtssonne).

    • Ich kann verstehen, dass die Horizons-Bibliothek von JPL nicht Open Source ist, aber die anderen drei sind. Sollte nicht jemand das ausarbeiten Unterschiede in diesen Bibliotheken und fusionieren sie? Das ist meine Hauptsache Beschwerde. Haben die Autoren der stellarium / pyephem / libnova Bibliothek? ein grundlegender Unterschied, wie man diese Berechnungen macht oder tut Sie müssen nur ihren Code zusammenführen?

  • Ich erkenne auch, dass es andere Gründe für die Berechnungen geben könnte anders und würde jede Hilfe bei der Behebung dieser Probleme zu schätzen wissen mögliche Fehler:

    • Pyephem und Libnova verwenden möglicherweise die Epoche des Datums anstelle von J2000

    • Der Mond ist nah genug, dass der Beobachter seinen Standort beeinflussen kann RA / DEC (Parallaxeneffekt).

    • Ich benutze Perls Astro :: Nova und Pythons Pyephem, nicht die ursprüngliche C-Implementierungen dieser Bibliotheken. Wenn diese jedoch Unterschiede entstehen durch die Verwendung von Perl / Python, das ist wichtig in meine Meinung.

  • Mein Code (mit rohen Ergebnissen):

    • Zuerst Perl und Astro :: Nova:
%Vor% %Vor% %Vor% %Vor%

%Vor%

[JPL Horizons benötigt POST-Daten (nicht wirklich, sondern vorgeben), also ich konnte keine URL posten].

  • Ich habe sie nicht verbunden (faul), aber ich glaube, es gibt viele unbeantwortete Fragen zu Stackoverflow, die effektiv zu reduzieren diese Frage (Inkonsistenz von astronomischen Präzisions-Bibliotheken), einschließlich einiger meiner eigenen Fragen.

  • Ich spiele w dieses Zeug bei: Ссылка

barrycarter 30.04.2013, 05:58
quelle

1 Antwort

9

Ich habe keine Ahnung, was Stellarium tut, aber ich denke, ich weiß von den anderen drei. Sie haben Recht, dass nur Horizons für diese scheinbare, ortsspezifische Beobachtung J2000 statt der Epoche verwendet. Du kannst es in enge Übereinstimmung mit PyEphem bringen, indem du neben "Table Settings" auf "change" klickst und von "1. Astrometric RA & amp; DEC" auf "2. Apparent RA & amp; DEC." Umschaltest.

Der Unterschied zu Libnova ist ein bisschen komplizierter, aber meine nächtliche Vermutung ist, dass Libnova UT anstelle von Ephemeridenzeit verwendet, und damit PyEphem die gleiche Antwort gibt, die Sie von einer Zeit zur anderen konvertieren müssen:

%Vor%

Dies gibt aus:

%Vor%

Das ist zumindest viel näher als vorher. Beachten Sie, dass Sie dies möglicherweise auch in Ihrem PyEphem-Code vornehmen möchten, wenn Sie die Refraktion ignorieren möchten, wie Sie Horizons gefragt haben; Aber für diese spezielle Beobachtung sehe ich keinen Unterschied:

%Vor%

Irgendeine Restdifferenz ist wahrscheinlich (aber nicht definitiv; es könnte andere Fehlerquellen geben, die mir gerade nicht vorkommen) aufgrund der verschiedenen Programme, die verschiedene Formeln verwenden, um vorherzusagen, wo die Planeten sein werden. PyEphem verwendet den alten, aber beliebten VSOP87. Horizons verwendet die wesentlich aktuelleren - und genauesten - DE405 und DE406, wie in der Ausgabe angegeben. Ich weiß nicht, welche Modelle des Sonnensystems die anderen Produkte verwenden.

    
Brandon Rhodes 02.05.2013, 04:12
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset GridLayout vs TableLayout