Keplerelemente der großen Planeten

[h_c_greier]

ich suchte eine einfache Planetentheorie, die ich A. auf dem HP49G zum Laufen bringe und B. in Excel und Co. in einer Zeile mit maximal 150 Zellen unterbringe.

OK, jetzt ist mal klar worum es überhaupt geht!

150 Zeilen? Hm, alleine die Tabellen fressen da schon das meiste weg. Außerdem ist "Zeilen" keine sinnvolle Angabe, weil welche Sprache? Ich kann meinem JS Code auch so komprimieren, dass man nix mehr erkennen kann und auch keine Leerzeichen drin vorkommen. Das ist dann ein Minimum an "Zeilen", genau genommen ist es nur eine einzige Wurst.
Und die ganzen kleinen Sub-Routinen, die man braucht, nehmen auch Platz ein (Ganzzahldivision, arctan2, keplerSolve, usw.)
Aber egal, du möchtest das mit einem Taschenrechner (TR) tun, in welcher Sprache? Soweit ich gesehen habe verwendet der eine Kombi von RPN mit LISP, genannt RPL, also ganz was Eigenes. Da bin ich überfragt.

Aus einem oskulierenden Elementesystem kann ich keine Planeten-Positionen über einige Jahrhunderte hinweg berechnen und sie sind damit für mein Vorhaben ungeeignet.

Wieso das? Die oskulierenden Elemente nimmt man ja genau deswegen, weil sie für einen bestimmten Zeitraum gelten, und für diesen Zeitraum kann man dann aus diesen die Positionen berechnen. Montenbruck umgeht das Problem, indem er für die äußeren Planeten "nur" Tabellen angibt (im Abstand von 400 Tagen), das sind aber zu viele Zahlen, um sie in ein Programm mit dem TR zu stecken. Außerdem sagt Montenbruck auch, dass seine oskulierenden Daten bezogen auf die Ekliptik und den Frühlingspunkt von J2000 sind. (S.140)

Ich dachte klargemacht zu haben, dass nicht ICH ein Problem mit der Keplergleichung habe, sondern das Tabellenkalkulationsprogramm. Kann ich auf saubere Programm-Bausteine wie DO .... UNTIL ... END zugreifen wie im HP49G, gibt es bei den kleinen Exzentrizitäten der großen Planeten keine Probleme.

Na dann ist das ja geklärt, du kannst die wahre Anomalie ν über die iterative Lösung der Kepler-Gleichung mit deinem Gerät berechen.

Ich verwende nun die Elemente von Meeus, S. 200 ff., "Orbital Elements for the mean equinox of the date"

Das solltest du nicht tun, weil man nur für die inneren Planeten halbwegs vernünftige Daten bekommt. Meeus lässt sich nicht darüber aus, welche Korrekturterme man für Jupiter-Neptun anbringen müsste. Durch die Störungen werden die Positionen vor allem von Jupiter und Saturn recht ungenau.

Standish macht eben genau das, er bringt für Jupiter-Uranus Störungsterme an. Aber mit seinen 2000er Koordnaten möchtest du ja nichts machen. Ich denke nicht, dass man die Störungsterme von Standish "herüberholen" kann, weil diese ja genau auf dessen J2000 Koordinaten abgestimmt sind.

Meeus bringt nur ein Beispiel für Merkur, er rechnet aber auch nur dessen Elemente aus, und er rechnet nicht weiter zur Länge, Breite, Radius usw...

Was mich zu weiteren Fragen bringt:
=> Welche Genauigkeit strebst du an?
=> Welche Daten sollen am Ende herauskommen?
(o) Sphärisch l,b,r oder rektangular x,y,z
(o) heliozentrisch ekliptikal
(o) geozentrisch ekliptikal
(o) geozentrisch äquatorial
(o) was Anderes....

Du kannst mal versuchen, nach dieser Seite (Tutorial) deine Werte zu berechnen. Der Autor gibt an, eine Genauigkeit von 1-2 Bogenminuten zu haben, er verwendet für die äußeren Planeten auch einige Korrekturen. Wenn das für den TR geht wäre das ein gangbarer Weg.

cs,
harald

--

 

[P_E_T_E_R]

Du kannst mal versuchen, nach dieser Seite (Tutorial) deine Werte zu berechnen.

Hallo Harald, vielen Dank - in der Tat ein sehr detailliertes und klares Tutorial für "back to the basics".

Ultras könnten ja sogar noch einen Schritt weiter gehen und die Berechnungen ganz ohne Taschenrechner nur mit Stift und Papier durchführen, wie einstmals Kepler!

Gruß, Peter

 

[Ehemaliges Mitglied 77903]

Hallo Sternfreund hcgreier,

Warum keine oskulierenden Elemente für Langfristvorhersagen? Siehe mein Bild. Standish braucht auch keine Zusatzterme, wenn man zwischen 1800 und 2100 bleibt. Ansonsten nehme ich die Genauigkeit, die ich bekomme, ohne den Rechenaufwand weiter aufzublähen.

Bis demnächst, R.M.

 

[h_c_greier]

Siehe mein Bild...

Aus dieser Grafik werde ich nicht schlau.
Es gibt halt nunmal keine "mittleren" Elemente für die äußeren Planeten, aus oben erwähnten Gründen. Das heißt es gibt sie schon, nur kann man daraus keine genauen Positionsdaten berechnen. Mach mal mit Meeus weiter und schau, wie weit die Daten abweichen. Kommt ja drauf an, welche Genauigkeit man haben will. Diese Frage hast du ja noch nicht beantwortet.
Und "Langfristvorhersagen", was soll das heißen? T = ± 10?? Das ist wohl keine so gute Idee.

Übrigens mit den Daten von Schlyter (Link oben) kann man ganz gut leben, so für 1900-2100 würde ich sagen. Hab es damit berechnet und verglichen mit meiner Astronomie-Software. Übrigens gibt Schlyter auch ein sehr kurze Umrechnungsmethode zwischen den Epochen an: Präzession

Das muss man aber laut seinen Aussagen nur machen, wenn man in (und nicht von) J2000 oder J1950 umrechnen will.
"If one wishes the position for today's epoch (useful when computing rising/setting times and the like), no corrections need to be done."

cs,
harald

--

 

[h_c_greier]

Just quick & dirty,

Daten-Vergleich: Planetenpositionen Bahnelemente ⇔ VSOP87.

Die Daten von Schlyter sind gar nicht mal schlecht! Für Planetengrafiken geht sowas immer. Was auffällt sind die relativ schlechten Radiusvektoren bei den äußeren Planeten. War irgendwie auch zu erwarten.

cs,
harald

--

 

[Ehemaliges Mitglied 77903]

Hallo Sternfreund hcgreier,

ich sah mir das von Ihnen verlinkte Tutorial an und stelle fest, dass dieser Autor unter "orbital elements" immer oskulierende Elemente versteht, obwohl das Wort osculating im ganzen Text nicht vorkommt. Ich erkenne das daran, dass er die Elemente für jedes Datum neu berechnet ("d" ist bei ihm ein Zeitargument Tage vor/nach irgendwann, bei Meeus heißt das meistens "T"). Ich gebe einen Auszug aus dem Papier:

10. The orbital elements of the planets. To compute the positions of the major planets, we first must compute their orbital elements:

Mercury:

N = 48.3313_deg + 3.24587E-5_deg * d (Long of asc. node)
i = 7.0047_deg + 5.00E-8_deg * d (Inclination)
w = 29.1241_deg + 1.01444E-5_deg * d (Argument of perihelion)
a = 0.387098 (Semi-major axis)
e = 0.205635 + 5.59E-10 * d (Eccentricity)
M = 168.6562_deg + 4.0923344368_deg * d (Mean anonaly)

...........

Mars:

N = 49.5574_deg + 2.11081E-5_deg * d
i = 1.8497_deg - 1.78E-8_deg * d
.........usw. Auszug Ende.

Das ist aber genau das, was an meinem Problem vorbeigeht. Der rechnerische Aufwand ist immens und dann kann ich gleich irgendeine x-beliebige Viel-Term-Theorie wie VSOP nehmen, die alle auf die eine oder andere Art das gleiche machen. Ich kriege das auf dem HP49G nicht gelaufen und in einer Zeile mit 150 Zellen ebensowenig. Didaktisch geht der Autor mehr als ungeschickt vor, wenn er die Elementberechnung ausgerechnet am Mond demonstriert und bei den Planeten dann darauf verweist - nur dass man dann halt von geozentrisch auf heliozentrisch umdenken müsse.

Die Beschäftigung mit dem Papier hat mir trotzdem genützt, weil ich wieder rekonstruieren konnte, woher ich meine Formeln damals eigentlich nahm. Im Prinzip machte ich keinen Fehler, nur dass man A. trigonometrische Formeln bekanntlich mit ihren Beziehungs- und Komplementärwinkel-Theoremen so umbauen kann, dass sie völlig anders aussehen, aber immer noch das gleiche bedeuten, und dass man B. Zwischenschritte zusammenführen kann, was zu einer Formel weniger und einer vermehrten Kompliziertheit der übrigbleibenden Formel führt.

Außer dass ich die mittleren (!) Meeus´schen Elemente für "date" (!) verwende, ändert sich also nichts. Die geringe Genauigkeit ist mir bekannt und ich kann auch nur zwischen 1800 und 2050 arbeiten, beides stört bei meinen Anwendungen aber nicht.

Bis demnächst, R.M.

 

[h_c_greier]

@ R.M,

zu P.Schlyter => Das ist kein Paper eines Wissenschaftlers, sondern einfach eine Webseite.

ich sah mir das von Ihnen verlinkte Tutorial an und stelle fest, dass dieser Autor unter "orbital elements" immer oskulierende Elemente versteht, obwohl das Wort osculating im ganzen Text nicht vorkommt

Aha, soso! Auch Meeus bezeichnet seine Elemente als "mean elements" (also böse Elemente ), und sie haben Polynomform, nämlich

elementXY = a0 + a1·T + a2·T² + a3·T³

Siehe "Algorithms 2. Auflage" Seite 209 bzw. "Algorithms 1. Auflage" Seite 197.

Jetzt erklären Sie mal bitte warum die Meeus'schen Elemente "mean" sind und die Schlyter'schen nicht?

Das ist aber genau das, was an meinem Problem vorbeigeht. Der rechnerische Aufwand ist immens und dann kann ich gleich irgendeine x-beliebige Viel-Term-Theorie wie VSOP nehmen

Wirklich? Also bei mir hat der Code von Schlyter 182 Zeilen, schön ausgeschrieben, ausführlich kommentiert und auch optisch mit vielen Leerzeilen. Wenn ich das JavaScript mit einem Minimizer komprimiere, bekomme ich ca. 20 "Zeilen", wobei das ja genau genommen nur 1 "Zeile" ist:

Was nicht verschwiegen werden darf sind Subroutinen wie "range" (Winkel im Intervall 0-360°) und eigene Winkelfunktionen, die Argumente in Grad akzeptieren und arctan2, das kommt dann noch dazu. Aber auch das sind Ein- oder Zweizeiler. Einfacher wird es leider nicht.

Wenn das alles jetzt nicht in Ihren HP49G passt, kann niemand etwas dafür, nicht Schlyter, nicht Meeus, die Zahnfee oder der Mork vom Ork.

Didaktisch geht der Autor mehr als ungeschickt vor, wenn er die Elementberechnung ausgerechnet am Mond demonstriert und bei den Planeten dann darauf verweist - nur dass man dann halt von geozentrisch auf heliozentrisch umdenken müsse.

Recht machen kann man Ihnen schwerlich was, oder?
Kleiner Tipp: Man mache es besser und poste es dann hier herein!

Schlyter rechnet das für Merkur vor mit seinem "Testdatum" 19.4.1990 00:00 (TD), und zwar hier.
Und gleich danach kommen die "Perturbations" für Jupiter, Saturn und Uranus.
Also ich finde das durchaus nachvollziehbar.

cs,
harald

--

 

[Auriga_HH]

Was war ich doch damals bescheiden. In den Siebzigern habe ich mir die Stellungen der 5 hellen Planeten von 1960 bis zum Jahr 2000 ausgerechnet und ausgedruckt. Benutzt habe ich damals einen DEC-Firmenrechner mit der Interpretersprache MUMPS, dürfte niemand kennen. Die Programme sahen aus wie "Kuddls Flüche" im Comic.

Und ja, da gab es GOTO, aber mich alten Assembler-Programmierer hat das nicht abgeschreckt. Assembler kennt sowas ja auch, aber für eine so schnelle Programmiersprache war GOTO zu langsam, da hieß es JUMP.

Zum Thema zurück. Meine Grundlagen wahren Paul Ahnerts Chronologische Tafeln, ein Zusammenstellung von Tabellen für die Jahre -1500 bis +2499. Sinus und Co konnte dieser Rechner nicht, daher habe ich mir passende Tabellen anlegen müssen.

Für die Berechnung der Anomalie habe ich überall eine Formel gefunden, wo links und rechts das Element E angegeben war. Mit meiner Realschulbildung konnte ich damit nichts anfangen. Von Iterierungen hatte ich nie gehört. Gelöst habe ich das provisorisch, indem ich ab der Nullpunkte mit Sinuswerten gearbeitet habe, was erstaunlich genau war. Ich war auch nicht so anspruchsvoll, mir reichte die Elongation zur Sonne und die ekliptikale Breite auf ein Zehntel Grad genau. Ich wollte ja nur keine Konjunktionen verpassen. Die Genauigkeit fand ich später in den Astro-Jahrbüchern bestätigt.

Der erste Erfolg dieser Berechnungen war meine Beobachtung der Venus am selben Tag als Abend- wie auch als Morgenstern als sie im Frühjahr 1977 rund 8 Grad nördlich der Sonne durch die untere Konjunktion lief.
Leider habe ich die Zettel mit den Berechnungen nicht aufgehoben.

 

[h_c_greier]

Hallo Helmut,

Sinus und Co konnte dieser Rechner nicht, daher habe ich mir passende Tabellen anlegen müssen.

Wow wie sahen diese Tabellen aus? Sowas wie Arrays und für jeden Grad den sin/cos-Wert?

Für die Berechnung der Anomalie habe ich überall eine Formel gefunden, wo links und rechts das Element E angegeben war

Was meinst du mit "überall"? Im besagten Werk von Ahnerts?

Leider habe ich die Zettel mit den Berechnungen nicht aufgehoben.

Uh, schade. Hab von Assembler, MUMPS usw. keine Ahnung. Wäre cool gewesen wenn du deine "Zettel" zeigen hättest können.

cs,
harald

--

 

[Specht]

...es gibt sie wirklich, ich hab es immer geahnt...

 

[Auriga_HH]

Die heutigen Programmierer sollen sich nicht so anstellen. While, break, continue ... alles auch nur nett verkleidete GOTO's. Gute Programmierer aus früheren Zeiten schafften es auch mit GOTO's spaghettifrei zu programmieren.

 

[Auriga_HH]

Hallo Harald

Damals war ich Mitglied in der "Öffentlichen Bücherhalle", für Schüler sehr günstig. Alles Astronomische habe ich von dort. Da habe ich auch die Formeln mit dem "E" auf beiden Seiten gefunden, in welchen Büchern weiß ich heute natürlich nicht mehr. Aber die Sinus-Tabelle habe ich aus einem Mathe-Buch für das Programm aufbereitet. Ja, es war ein Wert je Zehntel Grad mit 5 Stellen hinter dem Komma.

Meine Zettel waren ganz übersichtlich, denn es sollte ein Jahr auf eine Seite passen. Deshalb hatte ich für jede Woche eine Zeile, die etwa so aussah:

17.03.1977 ............-18,4 .... +0,1 .................. +16,8 .... +5,1 .............. +78,7 .... -1,7 ................ +142,0 .... +0,8 ............... -120,4 .... -0,3

Vorn das Datum, danach Elongation und ekliptikale Breite für Merkur, Venus, Mars, Jupiter und Saturn. Die Zahlen hier sind reine Fantasie, es geht nur um das Layout. Die Punkte waren allerdings nicht dabei, aber Foren schaffen es ja immer noch nicht, mehrere Leerzeichen nacheinander abzubilden.

 

[Auriga_HH]

...nee, Helmut, das war jetzt wirklich keine üble Anspielung auf jemand oder etwas. Oder gar böse gemeint. Das mit GOTO ist eher so ein "running gag" seit über 40 Jahren, bitte nicht missverstehen...

Das habe ich auch nicht so aufgefasst, ich habe ja noch selbst den Wandel mitbekommen. Aber trotzdem, es war für mich leichter, ein fremdes Assembler-Programm zu analysieren, als eine eigene Excel-Tabelle nach einem Jahr.

 

[h_c_greier]

Die heutigen Programmierer sollen sich nicht so anstellen. While, break, continue ... alles auch nur nett verkleidete GOTO's. Gute Programmierer aus früheren Zeiten schafften es auch mit GOTO's spaghettifrei zu programmieren.

Das mag schon sein! Ich habe mich mit der Springerei nie so angefreundet. War froh, dass irgendwann mal Subroutinen möglich waren, in Pascal hießen die glaub ich "procedures", wenn ich mich richtig erinnere. Strukturierteres Arbeiten. Aber klar, gute Programmierer GOTOen überall hin...

cs,
harald

--

 

[Specht]

Hallo R.M. (@w_m_fr_arajna ),

es gibt von Meeus noch ein älteres Werk (Astronomical Formulae for Calculators), geschrieben in der Zeit der (und für die) programmierbaren Taschenrechner. Dort findet man im Kapitel "Principal Perturbations" die wichtigsten Störungsterme, auch für Jupiter und Saturn! Mit ihnen erreicht man auch über den Weg der Kepler-Ellipsen eine ordentliche Genauigkeit bei überschaubarem Umfang.

Die Anzahl der Störungsterme kann man ja an die geforderte Genauigkeit und den freien Speicherplatz anpassen, ebenso kannst du dir dein gewünschtes Äquinoktium ja frei wählen und/oder ggf mit den bekannten Formeln umrechnen.

Einen "Königsweg" gibt es in der Ephemeridenrechnung aber leider nicht. Hohe Genauigkeiten über längere Zeiträume erreicht man nur mit einer großen Anzahl von Termen. Diese sind aber nur nötig, wenn man damit bestimmte Sachen weiterrechnen will, z.B. die genauen Stellungen der Jupiter- und Saturnmonde, oder Finsternisberechnungen.

Für praktische Anwendungen reichen in fast allen Fällen Näherungen mit wenigen Termen. Beispiele hierzu wären z.B. eine selbstprogrammierte drehbare Sternkarte, eine Monduhr mit eingezeichneten Phasen oder geozentrisch äquatoriale Koordinaten zum Einstellen an den Teilkreisen einer parallaktischen Montierung.

 

[astrowolf67]

Das Buch gibt's als PDF

https://www.agopax.it/Libri_astronomia/pdf/Astronomical%20Algorithms.pdf

CS
Wolfgang

 

[h_c_greier]

Hi Wolfgang,

ähm, bist du dir sicher dass das koscher ist?
Frag nur für einen Freund.

cs,
harald

--

 

[astrowolf67]

Hi Harald,

keine Ahnung, was sollte da nicht stimmen? Virenscanner hat jedenfalls nicht angeschlagen

CS
Wolfgang

 

[h_c_greier]

Hallo Volker,

Gerade mal nachgesehen. Jetzt steht der Schmöker schon so lange im Regal rum aber dieses Kapitel ist mir nie aufgefallen....

Die Anzahl der Störungsterme kann man ja an die geforderte Genauigkeit und den freien Speicherplatz anpassen, ebenso kannst du dir dein gewünschtes Äquinoktium ja frei wählen und/oder ggf mit den bekannten Formeln umrechnen.

Ich fürchte das sind immer noch zu viele Terme für unseren Sternfreund R.M.
Jupiter geht über 3 Seiten und Saturn über 4 1/2 Seiten. Sicherlich kann man da kleinere Terme weglassen.

Mich wundert, dass das in den "Algorithms" nicht mehr drinnen steht!?

cs,
harald

 

[hhh]

HP Calculator Literature

Dort findet man auch Skripten zur Astronomie und vieles mehr. Soweit ich weiß eine seriöse Seite, das gilt hoffentlich auch für die Downloads dort

 

[Auriga_HH]

Was sind denn Störungssterne? Die "Allwissende Müllhalde" sagt mir da nichts Gescheites.

 

[Ehemaliges Mitglied 77903]

Hallo Sternfreunde,

fürchte das sind immer noch zu viele Terme für unseren Sternfreund R.M.

zu Beginn, d.h. so ca. 2008 bis 2013, experimentierte ich herum mit radikal verkürzten Termreihen der VSOP-Theorie. Das beanspruchte mein Rechnerlein mindestens so stark wie die Kepler-Elemente und die Ergebnisse waren schlechter oder umgekehrt: Als ich auf Kepler umstellte, wurde es besser - bei den Planeten Merkur bis Mars "gut", bei Jupiter und Saturn "ausreichend". Ohne tiefere Fachkenntnis geistern mir da Begriffe durch den Kopf wie "langsame Konvergenz" der VSOP-Theorie und vermutlich aller anderen Viel-Term-Theorien. D.h.: Allzuviel kann man da nicht weglassen...

Bis demnächst, R.M.

 

[P_E_T_E_R]

Störungsterme

Was sind denn Störungssterne?

 

[P_E_T_E_R]

VSOP-Theorie

Vielleicht zum allgemeinen Verständnis: VSOP

 

[Auriga_HH]

Ja, lesen sollte man schon können.

 

[Ehemaliges Mitglied 77903]

Hallo Sternfreunde,

in diesem thread wurde alles behandelt, was man braucht, um mit EINFACHEN Theorien Planetenorte zu erzeugen. M.E. sind Kepler-Elemente der einzig gangbare Weg. Dabei kann man sich wie ich mit einfachen Elementen begnügen, nur zwischen 1800 und 2050 arbeiten und bei den Gasplaneten merklich verringerte Präzision in Kauf nehmen. Die Fehler können bei Saturn einige Zeit- und bis 10 Bogenminuten erreichen.

Warum das alles, wo es doch an jeder Netz-Ecke präzise Orte gibt?

Mein Hauptanliegen ist ein jährliches Planeten-Längen-Diagramm, dem ich, wenn es einmal erstellt ist, mit Augenschein ohne Rechnen Planetenorte entnehme. Zur Erstellung des Diagramms benötige ich 204 Stützpunkte = 204 Planetenorte: Je 55 für Me und Ve, je 28 für So und Ma und je 19 für Ju und Sa. Ich müsste also eine präzise Theorie 204mal anwerfen und jedes Mal das zugehörige Stützdatum eingeben. Bei so etwas macht man Fehler und wird müde.

Der im Vergleich damit erheblich verringerte Rechenaufwand mit Keplerelementen ermöglicht mir, die 204 Punkte in meinen graphischen Vorstellungen entsprechenden Zeitintervallen auf einmal zu erzeugen und weiter zu verarbeiten. Entweder ich drucke die Orte als Liste aus und arbeitete mit Lineal und Stift weiter (beispielsweise für nicht druckerfähige Großformate zum Wandaushang) oder ich lasse mir vom PC eine unbeschriftete Graphik-Datei erstellen, die ich DIN-A 4 ausdrucken und mit geringerem Aufwand mit konventionellen Schreibwerkzeugen fertigstelle. Zur Illustration setze ich eine solche Graphik für 2025 hierher, die ich provisorisch beschriftete und um 90° so drehte, wie man sie zuletzt lesen soll.

Ich erzeuge mit Hilfe der Randmarken ein Basisgitter (ekl.Länge quer und nach links laufend, Zeitfortschritt im Jahr senkrecht nach unten), verbinde die Stützpunkte zu glatten Kurven, benenne sie und ergänze unten astronomisch verstandene und auf Präzession korrigierte (andernorts erzeugte und deshalb hier fehlende) Sternbildgrenzen.

Eine mit PC und Drucker erzeugte Stützpunktmarke hat Ausmaße von etwa 0,1 bis 1 mm, was im DIN-A-4-Diagramm 2 bis 4 Zeit- oder 30 bis 60 Bogenminuten entspricht. Bei den größeren Formaten zum Wandaushang wird das natürlich besser, zumal wenn man das heute immer schwieriger zu bekommende DIN-A-3-Millimeterpapier verwendet. Keine online-Anwendung und kein Stellarium ersetzen mir die Dienste einer solchen ein Jahr gültigen, papiergebundenen Graphik.

Bis demnächst, R.M.

 

[h_c_greier]

Der Rechenaufwand verringert sich durch die Verwendung der reinen Elemente natürlich. Wie schon gesagt sind dann auch die Daten für die äußeren Planeten nicht so genau. Für eine Darstellung in einer Grafik wie beschreiben ist das ausreichend, man will sich ja nur einen groben Überblick verschaffen.

Zum geposteten Diagramm:
Die Länge wird hier senkrecht aufgetragen, der Jahreslauf waagerecht. OK.
Allerdings kann man in dem Diagramm schwerlich etwas Gescheites erkennen, wenn man die Punkte nicht verbindet.

Für den gegebenen Zeitraum sind die äußeren Planeten schon mal bis zu 1 Grad(!) daneben.
Ich habe mir den Zeitraum 1800-2100 mal angesehen und die Abweichungen für die äußeren Planeten Jupiter, Saturn, Uranus und Neptun berechnet. Die Bahnelemente gelten für das Äquinoktium des Datums (Meeus). Es wurde die volle VSOP87D zum Vergleich herangezogen. Während Jupiters und Saturns Differenzen um die 0 herum schwanken, ist die Differenz von Uranus durchgehend positiv und die Differenz von Neptun durchgehend negativ. Die Berechnungen wurden im Abstand von 10 Tagen durchgeführt, macht vom 1.1.1850 bis zum 10.1.2100 9133 Datenpunkte pro Planet.
Die Differenzen sind in den folgenden Grafiken in Bogenminuten angegeben.

Jupiter:

Saturn:

Uranus:

Neptun:

[Quelle: selbst erstellte Grafiken]

cs,
harald

--

 

[Ehemaliges Mitglied 77903]

Hallo Sternfreunde,

ich ergänze den Scan meines voll ausgearbeiteten 2025-Diagramms - die kopfstehende Bleistiftnotiz links oben hat mit dem Diagramm nichts zu tun. Der rote Kreis markiert die Stelle, an der ich mit der Lupe mass, dass mein dünnster Bleistiftstrich 0,3mm breit ist. Im Diagramm entsprechen 360° ekliptikaler Länge 256mm auf dem Papier. Damit entspricht ein Strich der maximalen Präzision auf dem Papier 25, ein dickerer Farbstift-Strich mindestens 60 Bogenminuten.

Sternfreund hcgreier gab oben für mehrere äußere Planeten schöne Diagramme mit den Abweichungen der ekliptikalen Kepler-Längen von ebensolchen VSOP-Längen von 1800 bis in unsere Zeit. Ich unterlegte sie mit einem grauen Balken der Breite, die etwa 25 Bogenminuten entspricht. In den Jahren 2000 +/- 50 Jahre deckt dieser meinem feinsten Bleistift-Strich entsprechende Balken alle Abweichungen zu.

Die zwei nicht mehr freisichtigen, äußeren Gasplaneten nahm ich nicht ins Diagramm auf, weil sich ihre Kurven auf dem Papier immer mehr senkrechten Geraden nähern, die wenig interessant sind und die Übersichtlichkeit beeinträchtigen.

Bis demnächst, R.M.

 

[h_c_greier]

Oh, ich schrieb "... den Zeitraum 1800-2100 ...", tatsächlich gelten die Grafiken für 1850-2100.

cs,
harald

--

 

[h_c_greier]

Ich habe jetzt nochmal Jupiter und Saturn betrachtet, über einen längeren Zeitraum von 1600-2400. Es ist schon erstaunlich, wie gut der Algorithmus von P. Schlyter hier im Vergleich zu Meeus ist. Fairerweise muss man dazu sagen, dass die Daten von Meeus die reinen Bahnelemente ohne Korrekturen sind.

In Anbetracht der wenigen Korrekturen, die Schlyter seinen Elementen hinzufügt, ist die Verbesserung - hier die heliozentrische ekliptikale Länge - beachtlich! Die Differenzen zur Full VSOP87D sind in Bogenminuten dargestellt.

Jupiter:

Saturn:

[Quelle: selbst erstellte Grafiken]

cs,
harald

--