TheiaSim
- Ersteller SRMeister
- Erstellt am
Bynaus
Registriertes Mitglied
Okay, hier mal ein Update aus meiner Sicht seit meiner letzten Wortmeldung hier.
Ich verstehe allerdings immer noch nicht ganz, was genau das Problem mit SCATR ist? Mal abgesehen davon, dass es in Fortran geschrieben ist. Ist es die schlechte Dokumentation? Die Sache mit Mond/Merkur? Letzteres liesse sich, wie SRMeister schon gesagt hat, dadurch lösen, dass man den Mond weglässt (spielt hier eh keine grosse Rolle) und den Merkur durch eine Keplerbahn abschätzt. Eventuell könnte man das sogar für alle (massereichen) Planeten machen.
Gemeint war hier natürlich die Hill-Sphäre der Planeten, nicht der Teilchen.
Ich stell mir das so vor:
- 8 massive Planeten (auf Keplerbahnen?), evtl. ein paar grosse Asteroiden im Gürtel (masselos, nur als "Zielkörper")
- X Teilchen mit bestimmten Ausgangspositionen, -koordinaten und -geschwindigkeitsvektoren ("Werte"). Diese Teilchen werden als masselos angenommen, sie interagieren also nicht miteinander, aber ihre Bahnen werden durch Planeten gravitativ beeinflusst.
- Sobald ein masseloses Teilchen sich einem Planeten (oder grossen Asteroiden) auf mehr als eine Hill-Sphäre nähert, werden seine Werte in ein lokales Koordinatensystem transformiert und mit sehr viel kürzerer Schrittweite gerechnet. Verfehlt es den Planeten, werden die Werte beim erneuten Erreichen des Hill-Radius an die ursprüngliche Simulation übergeben. Trifft es den Planeten (dh, es nähert sich auf weniger als einen bestimmten, kritischen Radius, der für jeden Planeten festgelegt werden kann), werden Trefferposition, Zeitpunkt sowie Bahnwerte zum Zeitpunkt der Kollision gespeichert und das Teilchen aus der Simulation entfernt.
- Sobald ein masseloses Teilchen sich der Sonne zu stark nähert, eine grosse Halbachse über einem bestimmten Wert erreicht oder das System ganz verlässt (Fluchtgeschwindigkeit rel. zur Sonne), wird es aus der Simulation entfernt.
Ich hab keine Ahnung, ob dafür SCATR wirklich nötig ist, oder ob ein anderer (etablierter) Integrator (z.B. Mercury?) es genauso tun würde.
Ich verstehe allerdings immer noch nicht ganz, was genau das Problem mit SCATR ist? Mal abgesehen davon, dass es in Fortran geschrieben ist. Ist es die schlechte Dokumentation? Die Sache mit Mond/Merkur? Letzteres liesse sich, wie SRMeister schon gesagt hat, dadurch lösen, dass man den Mond weglässt (spielt hier eh keine grosse Rolle) und den Merkur durch eine Keplerbahn abschätzt. Eventuell könnte man das sogar für alle (massereichen) Planeten machen.
Bernhard schrieb:
Gemeint war hier natürlich die Hill-Sphäre der Planeten, nicht der Teilchen.
Ich stell mir das so vor:
- 8 massive Planeten (auf Keplerbahnen?), evtl. ein paar grosse Asteroiden im Gürtel (masselos, nur als "Zielkörper")
- X Teilchen mit bestimmten Ausgangspositionen, -koordinaten und -geschwindigkeitsvektoren ("Werte"). Diese Teilchen werden als masselos angenommen, sie interagieren also nicht miteinander, aber ihre Bahnen werden durch Planeten gravitativ beeinflusst.
- Sobald ein masseloses Teilchen sich einem Planeten (oder grossen Asteroiden) auf mehr als eine Hill-Sphäre nähert, werden seine Werte in ein lokales Koordinatensystem transformiert und mit sehr viel kürzerer Schrittweite gerechnet. Verfehlt es den Planeten, werden die Werte beim erneuten Erreichen des Hill-Radius an die ursprüngliche Simulation übergeben. Trifft es den Planeten (dh, es nähert sich auf weniger als einen bestimmten, kritischen Radius, der für jeden Planeten festgelegt werden kann), werden Trefferposition, Zeitpunkt sowie Bahnwerte zum Zeitpunkt der Kollision gespeichert und das Teilchen aus der Simulation entfernt.
- Sobald ein masseloses Teilchen sich der Sonne zu stark nähert, eine grosse Halbachse über einem bestimmten Wert erreicht oder das System ganz verlässt (Fluchtgeschwindigkeit rel. zur Sonne), wird es aus der Simulation entfernt.
Ich hab keine Ahnung, ob dafür SCATR wirklich nötig ist, oder ob ein anderer (etablierter) Integrator (z.B. Mercury?) es genauso tun würde.
SRMeister
Registriertes Mitglied
Hallo Bynaus und Bernhard,
Warten wir mal Bernhard seine genaue Diagnose ab.
Nun zu den Punkten:
Nach erneutem recherchieren bin ich auf einen anderen, modernen "Zweig" von SWIFT gekommen, der sich Swifter nennt und mit "SyMBA" einen sehr guten, allgemein benutzbaren Integrator bietet, der außerdem codetechnisch mit SCATR nah verwand ist(wir sind also eingearbeitet) da beide auf SWIFT basieren. Außerdem wurde dieser Integrator in der Literatur öfter erwähnt als SWIFT oder SCATR. Der Code zu SyMBA basiert auf dieser Arbeit die 79 mal zitiert wurde.(Hier zum PDF)
Meiner Einschätzung nach sollte man dem vielleicht eine Chance geben. Der bietet bis auf die Sache mit der Oortcloud das selbe wie SCATR, ist aber wohl um einiges genauer. Das hilft vllt. bei der Sache mit der Kollisionserkennung:
Also die Sache mit dem Mond erübrigt sich ja, aber wenn der Integrator kollisionen nicht richtig erkennen kann, obwohl dass so dokumentiert ist, haben wir natürlich ein Problem. Das ist Bernhard sein Befund, ich habe dazu noch keine Untersuchung vorgenommen. Ich denke es ist auch relativ schwer, einen Testfall zu konstruieren.
Warten wir mal Bernhard seine genaue Diagnose ab.
Ich denke mittlerweile, es wird uns kaum möglich sein, einen anderen bekannten Integrator soweit zu modifizieren. Das würde nur mit einem Eigenen klappen.
Nun zu den Punkten:
Da es leider nur 2 Kategorien von Körpern gibt (masselos, massiv), kann man masselose Objekte nicht mit anderen masselosen kollidieren lassen. Eine Anpassung des Integrators scheint auch hier kaum möglich. Das stellt aber kein großes Problem dar, man kann auch ein paar massebehaftete Objekte in den Asteroidengürtel setzen.
Okay, dies sind dann die "Theiatrümmer". Bernhard sein Algorithmus erzeugt die ja bereits erfolgreich.
Okay, im Prinzip funktioniert SCATR genau so wie du es beschreibst. Es sollte also bereits jetzt prinzipiell in etwa so laufen. An diesem Punkt hat Bernhard bedenken. Ich kann dazu wie gesagt noch keine Aussage treffen.
Okay, genau so funktioniert SCATR, wobei man für die einzelnen Kriterien grenzwerte vorgeben kann.
Im Prinzip ist SCATR eine Erweiterung von SWIFT. SWIFT ist mMn ein sehr verbreiteter Integrator. SCATR ermöglicht, das äußere Sonnensystem in größeren Zeitschritten als das Innere zu berechnen, was man braucht um große Mengen von Objekten in der Oortcloud zu simulieren. Insofern hast du recht, SCATR ist nicht wirklich nötig.
Nach erneutem recherchieren bin ich auf einen anderen, modernen "Zweig" von SWIFT gekommen, der sich Swifter nennt und mit "SyMBA" einen sehr guten, allgemein benutzbaren Integrator bietet, der außerdem codetechnisch mit SCATR nah verwand ist(wir sind also eingearbeitet) da beide auf SWIFT basieren. Außerdem wurde dieser Integrator in der Literatur öfter erwähnt als SWIFT oder SCATR. Der Code zu SyMBA basiert auf dieser Arbeit die 79 mal zitiert wurde.(Hier zum PDF)
Meiner Einschätzung nach sollte man dem vielleicht eine Chance geben. Der bietet bis auf die Sache mit der Oortcloud das selbe wie SCATR, ist aber wohl um einiges genauer. Das hilft vllt. bei der Sache mit der Kollisionserkennung:
Außerdem ist es auch open source.
Zuletzt bearbeitet:
Bernhard
Registriertes Mitglied
Das Erstpaper zu Symba ist frei zugänglich: http://iopscience.iop.org/1538-3881/116/4/2067
Oops. Sehe gerade dass SRMeister einen Link bereits angegeben hat. Das Paper gefällt mir ebenfalls recht gut und es finden sich darin auch die Ansätze, die ich bereits in unserem BSSI-Code verwendet habe. Falls der Code beschafft werden kann, wäre ich daran interessiert.
Oops. Sehe gerade dass SRMeister einen Link bereits angegeben hat. Das Paper gefällt mir ebenfalls recht gut und es finden sich darin auch die Ansätze, die ich bereits in unserem BSSI-Code verwendet habe. Falls der Code beschafft werden kann, wäre ich daran interessiert.
Zuletzt bearbeitet:
Bernhard
Registriertes Mitglied
Hallo SRMeister,
ich habe SyMBA versuchsweise als Visual Studio Solution eingerichtet. Leider gibt es da etliche Probleme mit der Programmstruktur, die ich nicht auf die Schnelle beheben kann. Ohne die beiden Ordner fxdr und/oder fxdr_2.1c fehlt in den io-Dateien die Header-Datei fxdr.inc und ich habe keine Ahnung wie man in Fortran-Dateien Header-Dateien so includiert dass man keine Positionierungsfehler bekommt. Mit den beiden Ordnern kommt es zu sehr vielen Fehlermeldungen und noch mehr Warnings. Schaue Dir das bitte auch mal an. Vielleicht kommst Du ja besser mit dem Code zurecht.
ich habe SyMBA versuchsweise als Visual Studio Solution eingerichtet. Leider gibt es da etliche Probleme mit der Programmstruktur, die ich nicht auf die Schnelle beheben kann. Ohne die beiden Ordner fxdr und/oder fxdr_2.1c fehlt in den io-Dateien die Header-Datei fxdr.inc und ich habe keine Ahnung wie man in Fortran-Dateien Header-Dateien so includiert dass man keine Positionierungsfehler bekommt. Mit den beiden Ordnern kommt es zu sehr vielen Fehlermeldungen und noch mehr Warnings. Schaue Dir das bitte auch mal an. Vielleicht kommst Du ja besser mit dem Code zurecht.
ralfkannenberg
Registriertes Mitglied
Hallo Bynaus,Das sind erfreuliche Neuigkeiten, SRMeister. SyMBA ist mir auf jeden Fall sehr sympathisch!Offenbar kann man sowohl massive als auch masselose Partikel simulieren.
jetzt bist Du auch in der Sonntags-Zeitung erwähnt. Ob man dazu gratulieren soll ist allerdings eine andere Frage ...
Freundliche Grüsse, Ralf
Bernhard
Registriertes Mitglied
Hallo Ralf,
wird dort auch das Astronews-Forum erwähnt oder sogar dieses Thema hier? Ich bin momentan etwas ratlos bezüglich Deines Beitrages.
Gruß
Bernhard
Registriertes Mitglied
Hallo Ralf,
vielen Dank für die PN. Dein Postfach ist zur Zeit übrigens so voll, dass man Dir gar nicht mehr antworten kann. Nur zur Info.
Gruß
Bynaus
Registriertes Mitglied
Ja, es geht im Moment vieles bezüglich des Mondes, und Journalisten fragen öfter mal an (insb. bei meinem Doktorvater in Zürich), wie man denn das alles deuten müsse. Ich hab auch einen längeren populärwissenschaftlichen Artikel geschrieben, der nächstes Jahr publiziert werden wird. Aber mit dem Forum hier und dem TheiaSim-Projekt hat das alles nichts zu tun.
Bernhard
Registriertes Mitglied
Ich habe mich gerade zu den Jacobi-Koordinaten vorgearbeitet (s. Wisdom/Holman). Ziemlich trockene Materie aber auch interessant.und wann erhellt man uns?
Bernhard
Registriertes Mitglied
Hallo Bynaus und SRMeister,
ich habe aktuell einige Ideen zu den "close encounters" und wie man das eventuell in den SCATR-Code einbauen könnte. Mir schwebt dazu eine bestimmte "Gruppierung" der Hamilton-Funktion aus Punkt 3 der zentralen Veröffentlichung von J. Wisdom und M. Holman (1991) =[WH91] vor.
Als erste wichtige Übungsaufgabe möchte ich dazu das System Erde-Mond durch deren Schwerpunktskoordinate und den Relativabstand ersetzen. Damit sollte dieses Subsystem als separates Zwei-Körper-Problem in der Hamilton-Funktion erscheinen. Anschließend kann man dann das verbleibende (n-1)-Körper-Problem gemäß [WH91] lösen. Man kann dann testen, wie gut man das Sonnensystem selbst (inklusive Erde-Mond-System) simulieren kann. Sollte das gut funktionieren, kann man dieses erweiterte Prinzip auf den SCATR-Code anwenden, um massive Testkörper berücksichtigen zu können. Je nachdem, ob sich ein massiver Testkörper innerhalb oder außerhalb einer Hill-Sphäre eines Planeten befindet, müsste dann im Programm mit unterschiedlichen Hamilton-Funktionen gerechnet werden. Die konkreten Koordinatentransformationen (z.B. Heliozentrisch->Jacobi o.ä.) werden dadurch dann zeitabhängig, je nachdem welches Subsystem gerade aktiv ist.
Gruß
ich habe aktuell einige Ideen zu den "close encounters" und wie man das eventuell in den SCATR-Code einbauen könnte. Mir schwebt dazu eine bestimmte "Gruppierung" der Hamilton-Funktion aus Punkt 3 der zentralen Veröffentlichung von J. Wisdom und M. Holman (1991) =[WH91] vor.
Als erste wichtige Übungsaufgabe möchte ich dazu das System Erde-Mond durch deren Schwerpunktskoordinate und den Relativabstand ersetzen. Damit sollte dieses Subsystem als separates Zwei-Körper-Problem in der Hamilton-Funktion erscheinen. Anschließend kann man dann das verbleibende (n-1)-Körper-Problem gemäß [WH91] lösen. Man kann dann testen, wie gut man das Sonnensystem selbst (inklusive Erde-Mond-System) simulieren kann. Sollte das gut funktionieren, kann man dieses erweiterte Prinzip auf den SCATR-Code anwenden, um massive Testkörper berücksichtigen zu können. Je nachdem, ob sich ein massiver Testkörper innerhalb oder außerhalb einer Hill-Sphäre eines Planeten befindet, müsste dann im Programm mit unterschiedlichen Hamilton-Funktionen gerechnet werden. Die konkreten Koordinatentransformationen (z.B. Heliozentrisch->Jacobi o.ä.) werden dadurch dann zeitabhängig, je nachdem welches Subsystem gerade aktiv ist.
Gruß
SRMeister
Registriertes Mitglied
ich hätte eh gedacht, dass es so gemacht wird. sehr merkwürdig das ganze. Wozu soll man Jacobicoord. einführen, wenn man sie letztendlich nicht voll ausnutzt.
Soweit ich das verstehe, sollte das System selbst ohne merklichen Mehraufwand erkennen können, welcher Körper sich in welcher Hillsphäre befindet und die Berechnung entsprechend anpassen.
Soweit ich das verstehe, sollte das System selbst ohne merklichen Mehraufwand erkennen können, welcher Körper sich in welcher Hillsphäre befindet und die Berechnung entsprechend anpassen.
Bernhard
Registriertes Mitglied
Wenn man "nur" die Stabilität der Planetenbahnen oder des Sonnensystems als Ganzes über sehr große Zeitskalen (> 1 Millionen Jahre) untersuchen will ist das auch ohne Planetenmonde ein sehr interessanter Ansatz. Der Programmieraufwand fällt durch Vernachlässigung sämtlicher Monde, wie gesagt, deutlich geringer aus. J. Wisdom et al haben sich darüberhinaus auch noch mit einer Vereinfachung der Störterme beschäftigt um Rechenzeit zu sparen (Faktor 1000).
Bernhard
Registriertes Mitglied
Ich habe gerade zwei kleinere Fehler in dem C++-SCATR-Code gefunden. Die Fehler waren in den Dateien, welche die Systemwechsel Jacobi <-> Heliozentrisch, bzw. Jacobi <-> Schwerpunkt berechnen. Ich werde als nächstes versuchen hier sämtlich cpp-Dateien fehlerfrei zu bekommen. Im Prinzip ist das eine Art Übungsaufgabe, weil die Rücktransformation Jacobi -> "euklidisch" in [WH91] nicht angegeben ist. Google hilft da auch nicht unmittelbar weiter, so dass man das selber ausrechnen muss. Ohne die Rücktransformation kommt man im Thema ab hier aktuell nicht wirklich weiter.
Gruß
Gruß
Bernhard
Registriertes Mitglied
Die Transformation von den Jacobi-Koordinaten in die kartesischen Koordinaten kann man iterativ mit den zwei folgenden Formeln ausrechnen:
[tex]
\mathbf{x}_{n-1} = \frac{M-m_{n-1}}{M}\;\mathbf{x}'_{n-1}\;+\;\mathbf{x}'_0
[/tex]
sowie
[tex]
\mathbf{x}_{i-1} = \mathbf{x}_{i}\; -\; \mathbf{x}'_{i}\; +\; \frac{\eta_{i-2}}{\eta_{i-1}}\; \mathbf{x}'_{i-1}
[/tex]
wobei M die Gesamtmasse aller n Körper ist.
[tex]
\mathbf{x}_{n-1} = \frac{M-m_{n-1}}{M}\;\mathbf{x}'_{n-1}\;+\;\mathbf{x}'_0
[/tex]
sowie
[tex]
\mathbf{x}_{i-1} = \mathbf{x}_{i}\; -\; \mathbf{x}'_{i}\; +\; \frac{\eta_{i-2}}{\eta_{i-1}}\; \mathbf{x}'_{i-1}
[/tex]
wobei M die Gesamtmasse aller n Körper ist.
Bernhard
Registriertes Mitglied
Nachdem die Transformation in Jacobi-Koordinaten und wieder zurück aufgeschrieben ist, kann man sich die Lösung des Anfangwertproblems des Zwei-Körper-Problems genauer ansehen. Der SCATR-Code (alternativ auch das Buch von Danby) zeigt jedoch schon beim Überfliegen, dass dieses Thema deutlich komplexer ist, als man vielleicht vermutet. Die Lösung der Kepler-Gleichung (s. zugehöriger Wiki-Artikel) ist da nur die Spitze eines beeindruckenden "Eisberges", der dafür sorgt, dass alle Erhaltungssätze des Zwei-Körper-Problems berücksichtigt werden.
Gruß
Gruß