kleiner planetarer Simulator

Bernhard

Registriertes Mitglied
Mal wieder ein kleines Update
Hallo Kibo,

damit die Dateien bei Sourceforge übersichtlich bleiben, wäre es gut, wenn Du auch bei den Quelltexten im Dateinamen immer eine Versionsnummer angeben würdest. Sonst weiß man irgendwann nicht mehr, welcher Quelltext zu welcher "exe" gehört. Sourceforge hätte sogar eine brauchbare Versionsverwaltung für den Quelltext, aber ich weiß leider nicht, wie man dort ein Repository anlegt.
MfG
 

Bernhard

Registriertes Mitglied
Prima. Sourceforge hat übrigens auch einen ganz guten Support. Soll ich mal nachfragen, ob ich das Projekt komplett an Deinen Account abgeben kann?
 

Boogi

Registriertes Mitglied
Hi Kibo,

habe gerade Deinen Simulator ausprobiert. Finde ich klasse, dass Du Dich mit so was beschäftigst!
Allerdings bin ich nicht mit dem Programm zurecht gekommen (ich habe Version 1.10 oder 1.9.1 oder 1.1.9.4 verwendet. Wieso gibt's so viele Versionsnummern?)

- Nach dem Laden der Planeten habe ich 4 Sonnen, die aber 2x in der Liste auftauchen.
- Ich sehe aber nur eine Sonne.
- Nichts bewegt sich, obwohl die Simulation läuft.
- Die Steuerung der Blickrichtung ist äh... hakelig.
- Bewegungen mit WASD scheinen keinen Effekt zu haben.
- Das Mausrad scheint keinen Effekt zu haben.
- Was mache ich mit dem Kamera-Menü? Wieso kann ich dort keine Körper einstellen, auf die die Kamera dann zeigen soll?
- Wieso ging mein Browser auf, als ich Dein Programm laufen hatte?

Vielleicht bin ich auch nur zu doof dafür...

Gruß
Boogi
 

Kibo

Registriertes Mitglied
Hallo Boogi,

Zunächst solltest du immer die neueste Version verwenden, die nächst Ältere liegt nur da falls die neue Macken hat. Dieses Programm befindet sich noch in der Entwicklung und ist dementsprechend auch noch nicht auf Anwenderfreundlichkeit getrimmt, das ändert sich natürlich nach und nach wenn die großen Baustellen geschlossen sind.
Die Kameraausrichtung kann man NUR mit der Maus verändern, um das zu tun muss man in den Renderbereich klicken. Die Simulation läuft relativ realitätsnah ab. Das bedeutet Körper die sehr weit weg sind, bewegen sich auf dem Bildschirm eben nur ein bisschen und sind auch sehr klein. Wir reden hier über Entfernungen von hunderttausenden von Kilometern. Das ist auch wahrscheinlich der Grund, warum du kaum eine Veränderung bemerkst wenn du versuchst dich zu bewegen. Man muss entsprechend der Entfernung auch eine relativ Große Geschwindigkeit wählen, sonst dauert eine Reise von Planet zu Planet, wie in der Realität auch mal Jahre. Am einfachsten verändert man seine Geschwindigkeit mit dem Scrollrad, du kannst deine Position und Geschwindigkeit im Renderbereich unten links ablesen.

Ich werde deine Kritik ernst nehmen und die Startwerte umgehend anpassen, sodass beim Erststart ein System erstellt wird, in dem man auch was sehen kann und in dem Man auch gleich eine Geschwindigkeit hat von der man auch was merkt:).

mfg
 

Boogi

Registriertes Mitglied
Ok... hab's jetzt hinbekommen. Aus irgend einem Grund stand in der planeten.txt Müll. Deshalb waren auch die Sonnen doppelt vorhanden. Keine Ahnung warum.

Noch ein paar Ideen:
- Resetknopf für die Grafik: Die Kamera wird so eingestellt, dass alles im Blick ist.
- Wenn ich beispielsweise die Zeitschrittweite ändere wird die Kamera geändert. Warum?
- Die Maus läuft falsch rum, Wenn ich nach links fahre, dann will ich auch nach links schauen.
- Unser Planetensystem als default wäre cool.
Mehr fällt mir grad nicht auf...

Gruß
Boogi
 

Kibo

Registriertes Mitglied
So, du kannst ja jetzt mal auf "neueste Version" klicken:)

Das mit der Maus müsste zumindest am Anfang in Ordnung sein, bei bestimmten Bewegungen kippt die Kamera einfach um. Die ausrichtung der Kamera ändert sich nach der Position der Maus zum Zeitpunkt des Klickens das ist nicht unbedingt gewollt aber jetzt auch nicht so schlimm und nicht so einfach zu beseitigen.

mfg
 
Zuletzt bearbeitet:

Kibo

Registriertes Mitglied
Die Ladezeit der Settings.ini war zu kurz für deinen PC eingestellt, hab das ganze jetzt etwas konservativer eingestellt sodass es jetz gehen müsste.
Also einmal noch "neueste Version" und am besten alle vorherigen Dateien (also settings.ini, planeten.txt, alte exe) löschen damit es sauber neu erstellt wird.
 

Bernhard

Registriertes Mitglied
(nein noch nichts mit symplektischen Integrator, das dauert noch^^).
Hallo Kibo,

ohne den Quelltext genauer angesehen zu haben, brauchst Du für den symplektischen Integrator als Vorbereitung eine Funktion, die als Eingabewerte alle Positionen und Geschwindigkeiten aller Körper und die Schrittweite dt (in Sekunden) bekommt. Diese Funktion soll dann die neuen Positionen und Geschwindigkeiten aller Körper nach dt Sekunden ausrechnen. Du kannst, falls noch nicht gemacht, den vorhandenen Runge-Kutta-Code entsprechend anpassen, dass es genau so eine Funktion gibt.

Für den symplektischen Integrator braucht man so eine Funktionsschnittstelle dann zweimal mit unterschiedlicher Funktionalität und unterschiedlichem Wert für die Schrittweite. EDIT: Die erste Funktion beschreibt dann die kinetische Energie aller Körper und kann sehr leicht programmiert werden. Die zweite Funktion beschreibt die potentielle Energie aller Körper und kann relativ leicht aus der im ersten Absatz beschriebenen Funktion des Runge-Kutta-Codes abgeleitet werden.
MfG
 
Zuletzt bearbeitet:

Kibo

Registriertes Mitglied
Hallo Bernhard,

Soll ich mal nachfragen, ob ich das Projekt komplett an Deinen Account abgeben kann?
Kannst du machen, musst du aber nicht :)

Für den symplektischen Integrator braucht man so eine Funktionsschnittstelle dann zweimal mit unterschiedlicher Funktionalität und unterschiedlichem Wert für die Schrittweite.
Danke für den Tip, der SI kommt wenn ich mein Buch durchgearbeitet habe ;)
 

Kibo

Registriertes Mitglied
Update auf 1.11

Features:

Man kann festlegen wie lange die Simulation laufen soll

beseitigte Bugs:

Fehlerhafte Ausgabe der simulierten Zeit
Geschwindigkeitsslider entfernt das zu großer Störfaktor
Stabileres Management der settings.ini


Sourceforge
 
Zuletzt bearbeitet:

Kibo

Registriertes Mitglied
Zu meinem großen Erstaunen und unter Zuhilfenahme einiger auf Youtube zur Verfügung gestellter Seminare eines gewissen Jörn Loviscach, Prof. für Ingenieurmathematik und technische Informatik, habe ich gerade festgestellt, dass das in meinem Programm implementierte Eulerverfahren bereits symplektisch ist.

Anscheinend hab ich das wohl unwissentlich durch Trial-and-Error so implementiert.
Eine kleine Umänderung der verwendeten Variablen hin zum normalen expliziten Euler führte erwartungsgemäß zu wesentlich instabileren Bahnverläufen.:)
 

Bernhard

Registriertes Mitglied
Hallo Kibo,

Zu meinem großen Erstaunen und unter Zuhilfenahme einiger auf Youtube zur Verfügung gestellter Seminare eines gewissen Jörn Loviscach, Prof. für Ingenieurmathematik und technische Informatik, habe ich gerade festgestellt, dass das in meinem Programm implementierte Eulerverfahren bereits symplektisch ist.
Tolles Video. In der Wikipedia wird das gleiche hier: http://en.wikipedia.org/wiki/Symplectic_Euler_method beschrieben.

Ich habe die Dateien auf sourceforge.net neu sortiert und die aktuellen Parameterdateien neu hochgeladen. Den aktuellen Code habe ich so in eine zip-Datei gepackt, dass beim Entpacken automatisch ein neuer Ordner angelegt wird. Der Unterordner ist wichtig, falls man in einen Ordner entpackt, der bereits viele Dateien enthält.

Zusätzlich hätte ich noch eine Idee für eine neue Version. Beim Drücken auf den Start-Button sollte das Raster gleich so eingeblendet werden, dass man die Bahnen sofort sieht, ohne dass man die Kamera mit der Maus erst positionieren muss. Die Position der Kamera wird über die Datei settings.ini sowieso schon vorgegeben. Ein erneutes Positionieren mit der Maus stört deswegen.
MfG
 
Zuletzt bearbeitet:

Kibo

Registriertes Mitglied
Hi Bernhard,

Dein Vorschlag ist gut, ich arbeite im Moment am Leapfrog. Wird noch etwas dauern bis das richtig läuft denk ich.
In der dann neuen Version wird's auch den nicht symplektischen Euler zum Vergleich geben.

mfg
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
In der dann neuen Version wird's auch den nicht symplektischen Euler zum Vergleich geben.
Interessant ist bei der Simulation der vier Sonnen ein Vergleich zwischen Runge-Kutta und Euler bei einer Schrittweite von 86400 Sekunden (=1Tag). Runge-Kutta wird da sehr schnell instabil, während das symplektische Eulerverfahren stabil bleibt.
 

Bernhard

Registriertes Mitglied
ich arbeite im Moment am Leapfrog.
Der ist bei gleicher Genauigkeit im Vergleich zum Bulirsch-Stoer-Verfahren fast schon aberwitzig schnell. Ich teste das momentan an den Mondephemeriden und mache dabei Berechnungen über ein Jahr. Bei einer Schrittweite von 400 s braucht das Verlet-Verfahren (=Leapfrog) 8s Rechenzeit, während ich Bulirsch-Stoer nach über zwei Minuten abgebrochen habe. Bei einer Schrittweite von 86400s braucht BS ca. 4s, während man Verlet mit einer separaten Armbanduhr nicht mehr messen kann :) .

Nach welcher Anleitung gehst Du vor? Ich würde da nach wie vor die englische Wikipedia-Seite mit k=2 empfehlen. Es ist übrigens ganz interessant die dortige Anleitung auch für k=1 etwas genauer anzusehen. Man erhält das symplektische Euler-Verfahren aus dem von Dir verlinkten Clip nämlich nur mit einem (naheliegenden) kleinen Trick.
MfG
 

Bernhard

Registriertes Mitglied
Bei einer Schrittweite von 86400s braucht BS ca. 4s, während man Verlet mit einer separaten Armbanduhr nicht mehr messen kann :) .
Hallo Kibo,

nachdem jetzt der lästige Fehler bei der Umrechnung in RA und DEC geklärt ist, habe ich nochmal das Verlet-Verfahren gegen BS antreten lassen und gesehen, dass Verlet bei großen Schrittweiten wie 86400s sehr ungenau wird. Bei Simulationen über ein Jahr muss man also wissen, welche Schrittweite am besten zu wählen ist. Dann sind beide Verfahren in etwa gleich schnell. Bei einer Schrittweite von 1000s bekommt man mit dem Leapfrog über ein Jahr sehr gute Ergebnisse.
MfG
 
Oben