Statistik
Besucher jetzt online : 112
Benutzer registriert : 21963
Gesamtanzahl Postings : 1082190
Der Astronomie-Chat ... Live Diskutieren, Fragen stellen, Kontakte knüpfen ... Jederzeit mit anderen Sternfreunden in Echtzeit plaudern ...
Benutzername:
Passwort:
Passwort speichern
Passwort vergessen?

 Alle Foren
 Astronomie - die Technik (Datenverarbeitung)
 Computer, Software und Programmierung
 Iterationsgrafiken für Kepler-Lösungen
 Neues Thema  Zum Thema antworten
 Druckversion
Autor Vorheriges Thema Thema Nächstes Thema  

Specht
Altmeister im Astrotreff

Deutschland
1284 Beiträge

Erstellt am: 16.12.2018 :  18:53:38 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo!

Die Keplergleichung E = M + e * sin(E) (E: exzentrische Anomalie, M: mittlere Anomalie, e: Bahnexzentrizität) wird meist iterativ mit zwei verschiedenen Lösungsmethoden gelöst. Die einfachste Methode ist, zunächst M in die rechte Seite der Gleichung für E einzusetzen. Man erhält so eine erste Näherung für E. Diese Näherung setzt man dann wieder rechts für E ein und wiederholt das, bis eine angestrebte Genauigkeit erreicht ist. Im Gradmaß muss man noch den Faktor 180°/pi berücksichtigen:

E´ = M + e * (180°/pi) * sin(E) (Methode I)

Für M=20° und e=0.3 erhält man so mit dem Startwert E=20° nach 16 Iterationsschritten den korrekten Wert E = 28.09469354° (jetzt mal übergenau bis zur achten Nachkommastelle).

Die zweite Methode ist etwas komplizierter:

E´ = E - (M - E + e * (180°/pi) * sin(E)) / (e * cos(E) - 1) (Methode II)

Damit erhält man den korrekten Wert für E im obigen Beispiel bereits nach der dritten Iteration.

Interessant ist, die nötige Anzahl an Iterationsschritten einmal grafisch über einer (e,M)-Ebene darzustellen. Methode I erfordert bei höheren Exzentrizitäten sehr viele Schritte, besonders auch bei Werten für M nahe Null oder 180°. Zwischen M = 90° (pi/2) für e=0 und M ≈ 32.7° (pi/2 - 1) für e=1 verläuft ein "Minimumgraben":



Die gleiche Grafik hier auch für Methode (II):



Sie ist damit für Programme wesentlich besser geeignet. Die Algorithmen zu den Grafiken entwickelte ich in den frühen Achtzigern noch auf einem C 64, der dann für eine ähnliche Darstellung ein paar Stunden brauchte...

salü, volker.

Bearbeitet von: am:

Heljerer
Senior im Astrotreff

Deutschland
230 Beiträge

Erstellt  am: 16.12.2018 :  20:05:37 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo Volker,

da hast du ja was schönes aus den 80er Jahren wieder ausgegraben. Damals habe ich mich auch intensiv mit numerischen Rechenmethoden - vor allem für nichlineare Gleichungssysteme und Differentiagleichungssysteme - beschäftigt. Deine Methode 2 ist ja nichts anderes als das Newton-Verfahren. Dass das schneller geht als Methode 1 ist ja völlig klar. In den 80er war das auch noch extrem wichtig, weil die Rechner langsam waren.

Ich verstehe noch nicht so ganz die Botschaft, die du uns vermitteln willst. Dass bessere numerische Methoden schneller sind als Brute Force? Das weiß ja schon der Volksmund: Wer es nicht im Kopf hat, muss es in den Beinen haben.

Gruß
Wolfgang

Bearbeitet von: Heljerer am: 16.12.2018 20:05:59 Uhr
Zum Anfang der Seite

Specht
Altmeister im Astrotreff

Deutschland
1284 Beiträge

Erstellt  am: 17.12.2018 :  21:44:36 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo Wolfgang!
Zitat:
Ich verstehe noch nicht so ganz die Botschaft, die du uns vermitteln willst. Dass bessere numerische Methoden schneller sind als Brute Force?
Nein, natürlich nicht. Aber so mancher Sternfreund, der Interesse an der berechnenden Astronomie findet und selbst gerne z.B. Koordinaten von Planeten berechnen will, bleibt gerne an der Kepler-Gleichung hängen. Nicht jedem fällt das leicht, Kepler selbst arbeitete mit Logarithmentabellen und rief die Mathematiker seiner Zeit auf, Lösungsmethoden für seine Gleichung zu erarbeiten. Hin und wieder etwas Klassisches zu thematisieren, finde ich in einem Forum nicht uninteressant.

Heute hat wohl die klassische Ephemeridenrechnung mit Bahnelementen ihre Bedeutung zumindest bei den Planeten verloren. Professionelle Programme arbeiten hier meist mit den Termen der VSOP-Theorien.

Sobald ein Programm fertig ist, verliert es für mich beinahe jeden Reiz. Mein erstes "Planetarium-Programm" lief mit 300 Sternen auf einem C64 unter "Simon´s Basic". Eine Berechnung dauerte knapp drei Minuten. Der Kampf mit dem Speicherplatz und die Verbesserung der Rechengeschwindigkeit auch nur um Sekunden (z.B. durch eigene neue Maschinensprache-Routinen für SQR, SIN und COS) machte mir enormen Spaß. Mit jeder neuen Computergeneration wuchsen die Möglichkeiten, arithmetische Koprozessoren kamen. Trotzdem macht es Spaß, in der eigenen Software auch heute noch das Rad immer wieder selbst neu zu erfinden...

salü, volker.

Bearbeitet von: am:
Zum Anfang der Seite

Specht
Altmeister im Astrotreff

Deutschland
1284 Beiträge

Erstellt  am: 19.12.2018 :  20:00:30 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo!

→Stick: Danke für dein Feedback per E-Mail - ich will hier kurz im Thema darauf eingehen, weil es vielleicht auch für andere interessant ist, die mit dem C64 Astronomiesoftware geschrieben haben (Thema C64, Assembler und Geschwindigkeit). Das Thema mit den Iterationsgrafiken stammt ja eigentlich aus dieser Zeit.

[specht]Große Planetariumprogramme ganz in 6510-Assembler zu schreiben, war mir wirklich zu umständlich, vor allem wegen der vielen Abstürze beim Austesten. Vor Simon´s Basic (SB) habe ich vor allem die Grafikroutinen damit gemacht. Als dann SB mit all seinen Möglichkeiten auf den Markt kam, war das für uns damals wirklich etwas wunderbares. Noch schneller ging es, als ich für verschiedene Funktionen neue, schnellere Routinen in Maschine schrieb, gerade für SQR (die C64-Routine dafür war erbärmlich) und ATN, die man mit SYS oder USR aufrufen konnte. Noch (erheblich) schneller ging es dann mit Näherungslösungen (x statt sin(x) bzw. 1-x²/2 statt cos(x) für kleines(!) x). Sternkoordinaten wie RA und DK wurden schon mit nur wenigen Dezimalen im Bogenmaß eingegeben, Spektraltyp und Leuchtkraftklasse mit nur einem Zeichen codiert. Der bedeutendste Geschwindigkeitssprung war allerdings die folgende Überlegung: die Höhe eines Sterns berechnet sich über den Arcussinus eines bestimmten Wertes. War dieser Wert negativ, so auch sein arcsin, d.h. er stand unter dem Horizont. So brauchte dieser nicht berechnet zu werden und erst recht nicht sein vor Winkelfunktionen wimmelnder Azimut. Das machte damals gleich einige Minuten Rechenzeit aus.[/specht]

Jüngere Amateure mögen jetzt schmunzeln, aber damals, die Zeit der ersten Heimcomputer wie VC20 oder C64, die hatte schon was. Der damalige, aus der Speichernot geborene Programmierstil spiegelt sich noch heute im Source Code mancher Programmierer wider.

salü, volker.

Bearbeitet von: am:
Zum Anfang der Seite

Specht
Altmeister im Astrotreff

Deutschland
1284 Beiträge

Erstellt  am: 27.12.2018 :  11:58:11 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo!

Nach einer Bitte zu den einzelnen schrittweisen Näherungen für E für das Beispiel (M=20°, e=0.3) habe ich diese mit einem alten Casio FX-730P einmal (übergenau) berechnet:

Methode I (Startwert 20°, siehe oben):

25.87889322° 28.09467924°
27.50237315° 28.09468976°
27.93750552° 28.09469254°
28.05306314° 28.09469328°
28.08367387° 28.09469347°
28.09177702° 28.09469352°
28.09392167° 28.09469354°
28.09448927°
28.09463948°

Methode II:

28.18682212°
28.09470780°
28.09469354°

In BASIC könnte man die Kepler-Gleichung z.B. mit einer Schleife lösen (hier im Gradmaß):

x=m
do
ea = m + 180/pi * e * sin(x) (METHODE I)
ea = x - (m - x + e * 180/pi * sin(x)) / (e * cos(x) - 1) (METHODE II)
if abs(x-ea) < 0.00001 then exit do
x=ea
loop
exan=ea

m steht darin für die mittlere Anomalie, e für die Bahnexzentrizität, ea ergeben die jeweiligen Näherungswerte für die exzentrische Anomalie. Die gewünschte Genauigkeit legt man in der if-Anweisung fest, die Variable exan enthält danach den korrekten Wert für die exzentrische Anomalie. Aufpassen sollte man, in welcher Form die Programmiersprache das Argument des Sinus bzw. Cosinus erwartet. Wird Bogenmaß erwartet, muss man erst noch mit pi/180 multiplizieren.

salü, volker.

Bearbeitet von: am:
Zum Anfang der Seite

Kalle66
Forenmeister im Astrotreff

Deutschland
10144 Beiträge

Erstellt  am: 27.12.2018 :  13:03:47 Uhr  Profil anzeigen  Antwort mit Zitat
Volker,
ich bin da jetzt nicht im Thema, welcher Algorithmus da am schnellsten ist und C64, joa das ist lange her ... insoweit ist Dein Beitrag eher zum Schmunzeln.
Mit Assembler programmierte ich seinerzeit Grafik-Grundfunktionen (Punkt in x/y setzen, Linie/Kreis zeichnen), denn im C64-Basic konnte man sowas ja sonst punktweise mitverfolgen, so langsam war das.
Wichtig bei iterativer Näherung war natürlich immer Geschwindigkeit, KO-Kriterium war immer Beachtung der Speicherkapazität. Da gibt es ja auch den Trade-off - mehr rechnen vs. Daten im Speicher vorhalten.

Die Komplexität/Schnelligkeit von Formeln misst man (meist) in Anzahl der Mulitiplikationen und Additionen, gemessen über die Anzahl der (durchschnittlichen) Interationen. Es ist nicht nur die Formel selbst, sondern auch, wie man sie im Code dann umsetzt. Ein schönes Beispiel ist die FFT, die im Restklassenring (Modulo) sehr schnell rechnet.

Mindestens so wichtig ist dabei auch das Festlegen des Abbruchkriteriums und des max. Fehlers (sprich der in Kauf zu nehmende Ungenauigkeit).

Keplerellipsen ... sind die nicht analytisch lösbar? Meines Wissens ist erst das 3-Körper-Problem analytisch nicht mehr lösbar. Die Kurvendiskussion für Kegelschnitte programmierte ich seinerzeit ('86) in meinen Basic-Taschenrechner Sharp-1401**, für die Abi-Klausur brauchte ich das dann schon nicht mehr ... wenn man es programmieren kann, kennt man ja den Algorithmus aus dem Eff-Eff ...



**den Sharp-1401 hatte ich von 1985 (damals schweineteuer) bis 2013, bis die LCD-Anzeige ihren Geist aufgab. 28 Jahre, ich glaub, das ist beim heutigen IT-Equipment nicht wiederholbar. Beim C64 auf dem Dachboden müsste ich erst mal gucken, ob der überhaupt noch angeht und ob ich noch einen TV finde, der auf Kanal 33-36 (war's doch, oder?) die Signale empfängt.


Zitat:
Der damalige, aus der Speichernot geborene Programmierstil spiegelt sich noch heute im Source Code mancher Programmierer wider.

Im Grunde ist das heute nicht anders. Nur im Source Code selbst muss man nicht "sparsam" sein. Es reicht, wenn der ausführbare Code das ist. Sparsamkeitkeit im Sourcecode ist meist eine Umschreibung für fehlende Dokumentation. Bei der Webprogrammierung hat das sogar System und nennt sich Obfuskation.

Der Ballast kommt eher vom nicht Nutzen diverser Bibliotheken. Und da landet man beim Problem, dass das Nachschlagen/Suchen nach bestehenden Lösungen manchmal zeitaufwändiger ist als das Selbstprogrammieren. Das Thema Datenschnittstellen kommt noch hinzu.

Kalle - Alles wird gut !
Meine Okulardatenbank im Astrotreff: hier
Termine Teleskoptreffen gibt es hier

Bearbeitet von: am:
Zum Anfang der Seite

Specht
Altmeister im Astrotreff

Deutschland
1284 Beiträge

Erstellt  am: 27.12.2018 :  19:41:47 Uhr  Profil anzeigen  Antwort mit Zitat
Hallo Kalle!

Nö, es ging hier eigentlich nicht um C64-Historie. Obwohl ein C64-Thema mal was Schönes für´s OT-Forum wäre. (Würde vielleicht sogar den Katzenthread hinter sich lassen... ) Es war halt der einzige Rechner, der zu jener Zeit auch komplexere Aufgaben lösen konnte. Wir verwendeten ihn sogar noch 1990 an der Uni als Protokollrechner (in der tragbaren SX64-Version).

Neben den von mir oben gezeigten Methoden existieren wohl um die 100 andere Lösungsmethoden für die Kepler-Gleichung. Bei Stellen wie e>0.98 und M<10° verhalten sich manche extrem seltsam. Beispielsweise wird das Konvergenzverhalten von Methode II dort sehr instabil und spielt bei noch höheren Exzentrizitäten komplett verrückt.

In der astronomischen Praxis spielt das aber keine Rolle. Methode II verwende ich bis heute als Funktion kepler(m,ex) in meinen Programmen. Das alte, oben erwähnte Planetariumprogramm habe ich über so ziemlich alle Computer- und Betriebssysteme weiterentwickelt. Screenshots verwende ich dann gerne mal hier als Karte.

Sharp PC-1401 - ja, da schlägt doch mein Retro-Herz gleich schneller! Den konnte ich mir damals noch nicht leisten. Vor Jahren ergatterte ich mal auf einem Flohmarkt das Nachfolgemodell PC-1450. Da konnte man die RAM-Karten dann noch auswechseln. Neuwertig für ganze 10 Euro (den konnte ich mir dann leisten... ). Ich arbeite neben dem schon oben erwähnten Casio FX-730P noch heute gern mit diesen Dingern.

Was mich hin und wieder dazu treibt, ein Thema über berechnende Astronomie zu öffnen, ist die Wahrnehmung, dass so mancher die fertigen Programme oder Apps langweilig findet. Viele möchten mal gern selbst z.B. eine Jupiter-Ephemeride berechnen. Endstation ist leider zu oft die Kepler-Gleichung...

salü, volker.

Bearbeitet von: Specht am: 27.12.2018 20:47:56 Uhr
Zum Anfang der Seite

G2-Astro
Meister im Astrotreff

Deutschland
461 Beiträge

Erstellt  am: 27.12.2018 :  21:14:32 Uhr  Profil anzeigen  Besuche G2-Astro's Homepage  Antwort mit Zitat
Hallo Volker,

gute Idee, vielleicht gibt es ja noch mehr solcher Astroprogramme und Hilfe dazu diese auf heutige Rechner zu transportieren, damit man sie bei bedarf mal anwenden kann!

Ja, damals war fast jeder Mittelschüler, Gymnasiast, Elektriker, Fernsehtechnicker und Amateurfunker in der Lage, Rechner wie C64; Atari und ZX-Spectrum, die sich solche Computer besorgten auch programmieren, eine Bandbreite die man heute sucht!

Heute nur noch eine Handvoll von Informatikabsolventen, die bis zum Ende durchgehalten haben!

Auch weil bei der Leistung der ZPU´s Heute, sich damit Keiner mehr Alleine so leicht ein Programmierziel vorstellbar erfassen kann!

Wäre auch schön wenn es Heute dafür angepasste Software auf unseren Rechnern gäbe, mit der man so was noch selbst eingeben und ausprobieren könnte!

Ich hatte ca. 28 - 30 Astroprogramme auf dem ZX -Spectrum zum laufen gebracht. die mir sehr viel zum Verständnis von Himmelsbewegung und physikalischen Zusammenhänge vorführten.

So konnte ich eigene Hertzsprung-Russell sowie Farben- Helligkeit - Diagramme
( die aus festgestellten Auffälligkeiten bei den Helligkeiten von Antonia C. Maury und Annie J. Cannon dann daraus entwickelt wurde )
aus den Daten im Robert A. Naef " der Sternenhimmel " und Maiers - Handbuch für Sternfreunde erstellen!
Sowie eigene mit Phototransistor gemessene Sternhelligkeiten dort eingetragen!


Bei jeder Eingabe kam ein Pünktchen im Diagramm dazu.
So wurden auch für fast alle in den Büchern und Jahrbüchern veröffentlichten Doppelsterne, Umlaufbahnen auf den Monitor geplottet, und dann mit dem GP 50 Drucker auf Rollenpapier ausgedruckt, bei 1-2 Stunden Laufzeit.
Und fühlte sich dabei wie "klein Herzsprung"

Wer will, könnte Heute auch schon ab 8" Öffnung Exoplaneten jagen, Lichtkurven erstellen und damit Umlaufdaten ableiten!
Auch so eine angewandte Astronomie, kann Spass machen, für Fotojäger auch sicher ein lohnendes Betätigungsfeld!

Gruß Günter

www.G2-Astronomie.de
GSO 12" Dobson, C8-Orange, C8-Schmidtkamera, 140/500 - Comet-Catcher, MC100/1000 MAK; Skywatcher ED 80 PRO, Skw. 8" Dobson, Skw. 127 / 1500 MAK

Bearbeitet von: G2-Astro am: 27.12.2018 21:28:26 Uhr
Zum Anfang der Seite
  Vorheriges Thema Thema Nächstes Thema  
 Neues Thema  Zum Thema antworten
 Druckversion
Springe nach:
Astrotreff - Astronomie Treffpunkt © Astrotreff 2001 - 2019 Zum Anfang der Seite
Diese Seite wurde in 0.39 sec erzeugt. Snitz Forums 2000

Der Astrotreff bedankt sich für die Unterstützung von:



?