Hallo Kalle,
in meinen Programmen wird so ziemlich alles abgefangen und überprüft, was zu einem Problem führen könnte. Falsche Daten, mathematische Singularitäten, auch das von dir genannte Problem und noch vieles mehr, doch dies gehört ja eigentlich nicht mehr in diesen Thread...
Schöne Grüße, Volker.
Hi Kalle,
ich hätte doch schwören können, dass jetzt noch was von dir kommt. [;)]
Ole Römers Gruß wurde schon vernommen. Die Berücksichtigung der Lichtlaufzeit ist natürlich sehr wichtig und wird bei diesen Berechnungen zuallererst vorgenommen. Ist aber hier doch wirklich selbstverständlich. [:)]
Schöne Grüße, Volker.
Hallo!
Auf mehrfachen Wunsch (und weil das Thema der Koordinatentransformationen bestimmt wiederkommen wird), habe ich heute die Transformationsformeln etwas lesbarer editiert.
Schöne Grüße, Volker.
Ja, natürlich!
Bei der EphRech fängt man gewöhnlich beim ZKP an und gerät dann immer mehr in den Bann der Störungsrechnungen. Man muss auch nicht zwingend die VSOP87-Terme benutzen. Der Vorgänger von "Astronomical Algorithms" hieß "Astronomical Formulae for Calculators" (auch von J.Meeus) mit jeder Menge analytischer Störungsterme. Das Ziel war immer Bogensekundengenauigkeit.
Für die Auf- und Untergangsrechnung habe ich vor Jahren einmal einen eigenen Stützstellenalgorithmus mit Ausgleichspolynom entwickelt. Brachte dann echte Auf- und Untergangszeiten mit Genauigkeiten unter einer Minute. Ist natürlich beobachtungstechnisch völliger Unsinn, aber es funktioniert...
Noch einen schönen Abend, Volker. [:)]
Hallo Daniel!
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">TD=11:30 Uhr + 2 = 13:30 Uhr?<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Nein, das stimmt natürlich nicht. Je genauer du Ephemeriden berechnen willst, desto schwieriger wird die Materie und viele kleine Dinge müssen beachtet werden. Spielt die Genauigkeit keine so große Rolle, kann man <i>näherungsweise</i> UT=TD setzen. Ich erwähnte es eigentlich nur, um Differenzen deiner Ergebnisse zu erklären. Ich denke, es liegt hauptsächlich an den benutzten Bahnelementen. Da fehlen dann doch einige wichtige Störungsterme.
Wenn man aber z.B. Schattendurchgänge von Jupitermonden selbst berechnen will, muss man sowas wie ΔT natürlich beachten, auch sämtliche Störungen und noch einige richtig fiese Dinge mehr.
Noch etwas zur julianischen Tageszählung: Wenn man das "von Hand" rechnet, kann man sowohl UT benutzen als auch TD. Im ersten Fall erhält man den Beobachtungszeitpunkt zur gegebenen Weltzeit, im zweiten Fall zur gegebenen Dynamischen Zeit. Der Unterschied zwischen TD und UT ist- wie schon oben gesagt- etwa eine Minute.
Schöne Grüße, Volker. [:)]
Hallo!
Wenn Hartwig in Guide 11:30 UT eingibt, berechnet das Programm die Koordinaten α und δ auch für 11:30 UT. Die Umrechnung in TD erfolgt intern über ein Näherungspolynom für ΔT in TD.
Wenn du Ephemeriden zum Zeitpunkt 11:30 selber rechnest, erhälst du die Koordinaten korrekt zum Zeitpunkt 11:30 TD, also um 11:29 UT (wenn ΔT +60sec ist).
Grüße, Volker.
Hallo Daniel!
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Ach die Zeitdifferenz... Beim äquatorialem rotierenden KOS, wo der Nullpunkt=(Primär)äquinoktium ist, erübrigt sich das doch, oder?<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Leider nicht. Wenn du die Bahnelemente aus dem Montenbruck nimmst, musst du den Beobachtungszeitpunkt in TDT angeben. Die TDT wird gerne auch abgekürzt als TD oder TT. Planetariumprogramme machen das intern, da wird nur MEZ oder UT in die Maske eingegeben. Auch alle Terme der VSOP87 gelten exakt zum jeweiligen Zeitpunkt TD.
Zwischen UT und TD besteht der Zusammenhang TD = UT + ΔT
ΔT ist keine Konstante. Sie wird aus Beobachtungen abgeleitet. Dann benutzt man Schätzwerte für die nächsten Jahre. Zwischen 2004 und 2010 betrug ΔT etwa +65 sec.
Grüße, Volker.
Hallo Daniel,
das sieht gut aus! Glückwunsch! Wenn das Ergebnis stimmt, sollte der Rechenweg richtig sein. Die Unterschiede in den Koordinaten können auf mehrere Dinge zurückzuführen sein:
-Anderes Äquinoktium. Planetariumprogramme und Jahrbücher verwenden gerne 2000.0 statt aktuell, obwohl aktuell hier besser wäre, auch wegen der Auf- und Untergangsrechnung. Kann man leicht mit einer Präzessionsrechnung angleichen.
-Ich weiß nicht, ob Stellarium die kompletten VSOP87-Terme oder möglicherweise andere numerische Algorithmen verwendet.
-Anbringung der Korrektur für die Nutation. Oft wird nicht erwähnt, ob die Nutation berücksichtigt wurde.
-Etwas ungenaue Erdbahnkoordinaten. Die Erdbahn sollte bei Koordinatentransformationen möglichst exakt sein.
-In den Berechnungen wurden evtl. keine Störungsterme berücksichtigt. Das macht sich vor allem bei Mars, Jupiter und Saturn deutlich bemerkbar. Hier könnte die Verwendung von oskulierenden Bahnelementen helfen.
-Wurde ΔT=TD-UT berücksichtigt? Wichtig!
Schöne Grüße, Volker.
Hallo Daniel,
du hast erwähnt, dass du den Montenbruck benutzt (ich nehme mal an, die "Grundlagen der Ephemeridenrechnung"). Darin ist auch die Newcombsche Sonnentheorie beschrieben. Diese Theorie kann man auch zur genauen Ermittlung der Größen der Erdbahn benutzen (mit Störungen!). Man braucht bei der errechneten Länge nur einen Unterschied von 180° zu berücksichtigen, bei der errechneten Breite ändert man einfach das Vorzeichen.
Besser als die "Grundlagen der Ephemeridenrechnung" von Oliver Montenbruck finde ich das Buch "Astronomical Algorithms 2nd Edition" von Jean Meeus. Hier werden die Zusammenhänge m.E. klarer dargestellt. Hier findet man auch Lösungen für Jupiter- und Saturnmondstellungen. Auch eine verkürzte VSOP87-Theorie ist für alle Planeten enthalten. So kann man auch numerisch sehr genaue Ephemeriden berechnen. Wirklich interessant und empfehlenswert.
Zur Zeit versuche ich, bezüglich den VSOP87-Termen eine Mitte zu finden, die genauer ist als die von Meeus vorgestellte verkürzte Version, aber trotzdem bei weitem weniger Terme enthält als die komplette VSOP87-Theorie. Ziemlich trocken, aber sehr interessant.
Schöne Grüße, Volker. [:)]
Hallo Daniel!
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Übrigens ist die Inklination der Ebene der Erde ebenfalls um i=0+0.0131*T. Als Bahnelemente verwende ich die von Montenbruck welche ab JD2000.0 gelten.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Leider ist das nicht (ganz) richtig. Diese Bahnneigung der Erde gilt nur auf die Ekliptik 2000.0 bezogen. Es heißt nicht, dass diese Beziehung <i>ab</i> dem Jahr 2000 gilt. Es handelt sich hier um eine Standardepoche, um eine Norm zu finden, die mit Sternkarten der Epoche 2000.0 übereinstimmt. Vor 1984 war dies 1950.0. Für eine korrekte Ephemeride müssen Bahnelemente der <i>gleichen</i> Standardepoche verwendet werden. Für die Ekliptik des Datums gilt für die Erde stets: i=0°
Wenn du mit i ungleich 0° rechnest, ist natürlich B=arcsin(sin(u)*sin(i))
Schöne Grüße, Volker. [:)]
Hallo Daniel,
die ersten Anfänge gehen zurück bis in meine Studienzeit an einem C-64! An meinen aktuellen Programmen schreibe ich, wenn es nachts mal nicht klar ist in meiner Freizeit. Die Schreibzeit für mein Planetariumprogramm betrug etwa 10 Jahre. Eigener griechischer Zeichensatz, drei verschiedene Zahlensätze, alte Symbole für die Sternzeichen, alles vom Milimeterpapier in Matrizen übertragen, richtig was für echte Freaks, alles in Visual Basic 6. Da musst du das Rad fast immer wieder selbst erfinden, aber mit VB6 sind sehr gute Darstellungen des Sternenhimmels möglich.
Übrigens sind die Transformationsformeln die Ergebnisse der Anwendung von Drehmatrizen. Leichter wird´s also nicht.
Schöne Grüße, Volker.
Hallo Daniel,
ich glaube, dein Problem liegt bei den Erdkoordinaten L, B und R. Sie müssen separat berechnet werden, bevor man die Formeln benutzt:
R=1-e*cos(E)
ich nenne die Länge des Perihels (omega mit Schlange) jetzt nur omega:
L=omega+2*atn(sqr((1+e)/(1-e))*tan(E/2))
B=0 (keine Bogensekundengenauigkeit erforderlich)
Die von dir verwendete Formel für l (ekliptikale Länge) ist für die Planeten (ohne Erde) hergeleitet. Sie berechnet l, wenn der Bahnebenenparameter u und die Bahnneigung i des Planeten bekannt sind. u=omega(ohne schlange)+wahre Anomalie v.
b[=arcsin(sin(u)*sin(i))] muss auch in diese Formel eingesetzt werden (ekliptikale Breite)
Dies hilft sicher weiter. Häufige Fehlerquellen: Verwechselung DEG-RAD im sin/cos, Klammerfehler, julianisches Datum falsch.
Wenn nichts mehr geht: liegenlassen, an einem anderen Tag nochmal drangehen, eine feine Tasse Tee, einen Mathe-Meister fragen (obwohl das Thema im Mathe-LK und sogar im Mathestudium für Naturwissenschaftler meist nicht berührt wird). [;)]
Schöne Grüße, Volker.
Hallo Daniel,
lass dir Zeit! Bei Vergleichen auch auf die Epoche der Bahnelemente achten (2000.0 oder aktuell). Programme wie RedShift oder Stellarium arbeiten meist mit einer mehr oder weniger verkürzten numerischen VSOP87-Version. Auch Kommastellen in diesen Programmen deuten nicht auf die entsprechende Genauigkeit! GUIDE 9.0 rechnet (auf Wunsch anklickbar) mit den kompletten VSOP87-Termen (viele tausend!).
Gut sind tabellarische oskulierende Bahnelemente, besonders für Jupiter und Saturn, die beim Zweikörperproblem Störungen schon berücksichtigen. Für die Elemente der Planeten Merkur bis Mars kann man vernünftige Bahnelemente auch zeitlich als Gleichung entwickeln. Bei meinem Programm komme ich so bis fast zur Bogensekundengenauigkeit. Ich bin jedoch zur Zeit dabei, eine verkürzte VSOP87-Version zu implementieren, um nicht immer die aktuellsten Bahnelemente einbauen zu müssen.
Viel Spaß und schönes WE, Volker. [;)]
Noch eine Anmerkung zu den Formeln:
Wenn man nicht absolut korrekt rechnen muss (wie beispielsweise bei der VSOP87-Planetentheorie), kann man die heliozentrisch ekliptikale Breite B der Erde gleich Null setzen. Die Formeln verkürzen sich dann entsprechend.
Grüße, Volker.
Hallo Daniel,
du hast jetzt alle nötigen Umformungen (die steuern übrigens mein selbstgeschriebenes Planetariumprogramm seit über 10 Jahren), trotz allem habe ich alle noch mal neu hergeleitet.
Ich hoffe, keinen Tippfehler gemacht zu haben, da ich heute morgen nur eine Tasse Tee hatte. [:D]
Viel Spaß beim Rechnen, Volker.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">...hier noch die Umrechnung Bahnebene->heliozentrisch ekliptikal:
cos(b)*cos(l-ak)=cos(u); ak:Länge des aufst.Knotens
cos(b)*sin(l-ak)=sin(u)*cos(i)
sin(b)=sin(u)*sin(i)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Umgeformt ergibt sich:
b=arcsin{sin(u)*sin(i)}
tan[(l-ak)/2]=[sin(u)*cos(i)]/[cos(b)+cos(u)]
Mit diesem kleinen Trick bekommst du nach dem Auflösen der Gleichung sofort (l-ak), und zwar ohne Fallunterscheidungen als -180°<(l-ak)<180°! ak ist ja als Bahnelement bekannt und wird zum Schluss hinzuaddiert. Alles klar?
Schöne Grüße, Volker. [;)]
Du hast 2 Formeln, einmal mit sin(l-ak), einmal mit cos(l-ak). Dich interessiert die Größe l, mit beiden Formeln lässt sie sich jedoch nicht eindeutig auflösen (Fallunterscheidungen). Also berechnest du tan((l-ak)/2)=... und erhälst l-ak ohne Fallunterscheidungen.
Diesen kleinen mathematischen Trick habe ich in den folgenden Umformungen für lam und ra auch verwendet.
Ich schreibe es kurz für dich um und poste es dann.
Grüße, Volker.
Hallo Daniel,
hier die letzten Formeln:
se:Schiefe der Ekliptik
dk:Deklination
ra:Rektaszension
dk=arcsin{sin(se)*cos(bet)*sin(lam)+cos(se)*sin(bet)}
tan(ra/2)=[cos(se)*cos(bet)*sin(lam)-sin(se)*sin(bet)]/[cos(dk)+cos(bet)*cos(lam)]
Wie stets: -180°<ra<180° ohne Quadrantenproblem! Bei negativen Werten können 360° addiert werden.
Grüße, Volker.
...habe doch glatt delta vergessen:
delta=sqr{r^2+R^2-2*r*R*[cos(b)*cos(B)*cos(l-L)+sin(b)*sin(B)]}
Den dritten Teil mit den endgültigen Formeln zu Rektaszension und Deklination habe ich jetzt auch noch mal hergeleitet. Kommt später. Übrigens erreiche ich mit aktuellen Bahnelementen Genauigkeiten <5" !
Schöne Grüße, Volker.
Hallo Larry,
das ist ja schön, wie du das zu erklären versuchst, aber leider auch praxisfern. Zeichnungen, heftige Formeln, Vorzeichen im Auge behalten und viele Programmiersprachen sind gar nicht nötig. Auch die Konvergenz der Keplergleichung ist kein Problem, wenn man iterativ richtig zu Werke geht.
Hallo, weiter geht´s.
Nach der Berechnung der ekliptikalen Koordinaten folgt die Umrechnung ins geozentrisch ekliptikale KOS. Dazu benötigt man auch die heliozentrischen Erdkoordinaten. Auf keinen Fall solltest du jetzt in kartesische Koordinaten umwandeln!
Ich habe heute morgen die Formeln noch einmal hergeleitet. Für die geoz.ekl.Breite bet und Länge lam gilt:
bet=arcsin{[r*sin(b)-R*sin(B)]/delta}
tan(lam/2)= [r*cos(b)*sin(l)-R*cos(B)*sin(L)]/[delta*cos(bet)+r*cos(b)*cos(l)-R*cos(B)*cos(L)]
Wie oben erhälst du automatisch -180°<lam<180° ohne Quadrantenproblem!
R,B,L: heliozentrisch ekliptikale Erdkoordinaten
delta,lam,bet:geozentrisch ekliptikale Planetenkoordinaten
r,b,l:heliozentrisch ekliptikale Planetenkoordinaten
Schöne Grüße, Volker.
0°<v<360° muss nicht sein,
wenn v<0, einfach 360° hinzuaddieren! (ist aber unnötig)
Grüße, Volker.
...hier noch die Umrechnung Bahnebene->heliozentrisch ekliptikal:
cos(b)*cos(l-ak)=cos(u); ak:Länge des aufst.Knotens
cos(b)*sin(l-ak)=sin(u)*cos(i)
sin(b)=sin(u)*sin(i)
Wenn du zur Berechnung von l-ak die Funktion Tangens(x/2)=sin(x)/(1+cosx) verwendest, bekommst du (l-ak) wieder ohne Fallunterscheidung direkt als -180°<(l-ak)<180° !
Grüße, Volker.
Hallo!
Mit der exzentrischen Anomalie E, der Exzentrizität e und der großen Halbachse a bestimmt man den Radius r=a*(1-e*cos(E)). Mit E und e bestimmt man dann die wahre Anomalie v. Mit v und omega (Winkel Knoten-Planet) berechnet man das Argument der Breite u=omega+v. Mit u, r und der Bahnneigung i haben wir schon die Koordinaten der Bahnebene des Planeten.
Die Fallunterscheidung ist unnötig, denn tan(v/2)=sqr((1+e)/(1-e))*tan(E/2) liefert -180°<v<180° !
Dann kann man diese Koordinaten in das gewünschte KOS (z.B. geozentrisch äquatorial) umrechnen.
Schöne Grüße, Volker.
