TheiaSim

SRMeister

Registriertes Mitglied
Bernhard, das Problem momentan ist folgendes: In der Literatur findet man die Angabe, dass für eine über Mrd. Jahre reproduzierbare Integration die Zeitschrittweite so eingestellt werden muss, dass der innere Planet eine Umrundung der Sonne in ca. 10 - 20 Zeitschritten macht. Das würde bedeuten, wir müssten etwa 10 Tage einstellen.
Momentan ist aber 1 Jahr eingestellt. Daher kommen die extremen Fehler.
Diese Grundeinstellungen haben die SCATR Programmierer genommen, da sie die Oortsche Wolke plus die 4 Gasriesen simuliert haben, wo Jupiter der innerste ist und 1/10 der Periode eben 1 Jahr ist.
Um die Periode auf 10 Tage einzustellen, musst du den letzten Wert in der erste Zeile in theia_param.in, der momentan 10 ist, auf 360 anheben.
Ich habe das probiert und die Ergebnisse sehen vielversprechend aus. Es werden über die 1 Mio Jahre nurnoch ca. 5% der TPs aus dem System geschleudert.

Zur Problematik mit dem Mond: soweit ich den algorithmus richtig verstanden habe, sucht er für jeden Körper selbstständig den dominierenden Gegenspieler.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Um die Periode auf 10 Tage einzustellen, musst du den letzten Wert in der erste Zeile in theia_param.in, der momentan 10 ist, auf 360 anheben.
Das ist ein korrekter Hinweis, aber es sind falsche Zahlen ;) . Parameter drei in Zeile eins ist die Schrittweite dt in Tagen. Parameter 4 ( = tinc = t_increment) gibt die Änderung der Schrittweite an, falls die Schrittweite angepasst wird (adaptive stepsize). Ich habe Parameter drei also auf 10 (Tage) und Parameter 4 auf 0.1 gesetzt. Damit bleiben Mond und Mars dann auch nach einer Millionen Jahre auf vernünftigen Bahnen.
 

Bernhard

Registriertes Mitglied
Also nehmen wir doch 1 Mondmasse für das grösste Fragment. Und dann vielleicht noch vier mit 0.1 Mondmassen dazu.
Frage zum besseren Verständnis: Wie kann aus so einer Anfangsverteilung der heutige Mond mit einer Mondmasse entstehen? Es müsste bei dem Entstehungsprozess des Mondes eine ganze Menge an Material (=0.4 Mondmassen) den Mond wieder verlassen. Kann man diesen Masseverlust über Meteoriteneinschläge erklären?
 

Bynaus

Registriertes Mitglied
@Bernhard: Mit unserem Mond haben die Fragmente nichts zu tun. Die Fragmente sind Trümmer von Theia, die zu schnell unterwegs sind, als dass sie im Erde-Mond-System verbleiben könnten. Sie segeln also weiter und umkreisen die Sonne. Die wichtigste Frage hinter diesem Projekt ist, was denn eigentlich mit diesen Trümmern passiert.

In der Zwischenzeit bildet sich aus denjenigen Trümmern, die das Erde-Mond-System (ich nenne es jetzt so, obwohl sich der Mond zu diesem Zeitpunkt erst noch bilden muss) nicht verlassen haben, eine Scheibe rund um die Erde. Aus dieser Scheibe verklumpt sich dann, nach ein paar 100 bis 1000 Jahren vielleicht (? man weiss es nicht so genau) der Mond. Das brauchen wir alles nicht direkt zu simulieren, weil das andere Modelle schon mit viel höherer Auflösung tun. Uns interessiert nur, was mit der ~Marsmasse an Trümmern geschieht, die das Erde-Mond-System verlassen und die Sonne umkreisen. Es geht um folgende Fragen:

1) Wieviel kehrt zur Erde zurück? Je nach dem müsste man das in isotopischen Mischrechnungen zwischen Erde und Theia nämlich berücksichtigen (solche Rechnungen macht man, weil man die Ähnlichkeit der Isotopie des Mondes und der Erde erklären will)
2) Wieviel landet auf anderen Planeten oder allenfalls im Asteroidengürtel? Das wird uns eine Ahnung geben, ob wir in unserer Meteoritensammlung auch Trümmer von Theia erwarten sollten.
3) Welche Auswirkungen haben die grössten Trümmer auf die Bahnen der Benachbarten Planeten? Wenn sich z.B. herausstellen würde, dass die Bahn der Venus dadurch stets viel exzentrischer wird als beobachtet, könnte man dieses Szenario ausschliessen bzw. die Masse des grössten Fragments nach oben begrenzen. Vielleicht stellt sich ja auch heraus, dass das grösste Fragment immer mit dem Mars kollidiert - dann ist es vielleicht für das Borealis-Becken verantwortlich? (ich spinne jetzt nur rum, um zu zeigen, wohin es führen könnte - so etwas zu belegen wäre natürlich eine ganz andere Aufgabe).
 

SRMeister

Registriertes Mitglied
Das ist ein korrekter Hinweis, aber es sind falsche Zahlen ;)

Parameter 3 (dt) ist die Schrittweiter außerhalb von 300 AU (Siehe "rcrit" in param.in). Da haben die Autoren berechtigterweise 10 Jahre vorgegeben (3600 stand da).
Außerhalb von "rcrit" wird der Wisdom Holman Integrator verwendet, der sich auf das Barycenter bezieht.
Innerhalb von "rcrit" also unter 300AU wird ein Mixed-Variable-Symplectic Integrator namens RMVS3 verwendet. Die Zeitschritte in diesem Bereich ergeben sich aus "Wert 3" geteilt durch "Wert 4". Deswegen muss Wert 4 auch ein Integerwert sein, da sonst keine runde Teilung möglich ist.
readme.first schrieb:
dt is the timestep used when particles are far from the Sun
tinc is the fraction of dt used as an integration step when particles
are near the Sun (must be integer)
Ich versuche das mal zu übersetzen:
dt ist der Zeitschritt, der benutzt wird, wenn die Partikel weit von der Sonne entfernt sind.
tinc ist der Bruchteil von dt, der als Integrationsschritt verwendet wird, wenn die Partikel der Sonne nah sind. (Muss ein Integer sein)

Ich habe mir so meine Gedanken gemacht, ob wir vllt. davon profitieren können. Da wir keinen Kuipergürtel haben, könnten wir den Bereich hinter Neptun, sagen wir mal, ab 35 AU, als den "äußeren Bereich" festlegen. Dort wären dann Zeitschritte gemäß dt = Periode/10 von ca. 15 Jahren sinnvoll. Dort sind ja sogut wie nie irgendwelche Teilchen außer Pluto. Und im inneren Sonnensystem nehmen wir dann 10 Tage. Was hälst du davon?
 

Bernhard

Registriertes Mitglied
Da wir keinen Kuipergürtel haben, könnten wir den Bereich hinter Neptun, sagen wir mal, ab 35 AU, als den "äußeren Bereich" festlegen. Dort wären dann Zeitschritte gemäß dt = Periode/10 von ca. 15 Jahren sinnvoll. Dort sind ja sogut wie nie irgendwelche Teilchen außer Pluto. Und im inneren Sonnensystem nehmen wir dann 10 Tage. Was hälst du davon?
Das passt schon. Ich hatte meine Informationen direkt aus dem Quelltext abgeleitet und dabei scheinbar einiges missverstanden. Als nächsten Schritt sollte man jetzt noch die Vorgaben von Byanus mit den fünf massiven Teilkörpern berücksichtigen. Wir können dabei auch gerne parallel arbeiten, weil das relativ schnell gemacht ist. Ein paar Extra-Simulationen mit unterschiedlichen Startwerten können auch nicht schaden.

@Bynaus: Falls Du mit der Software nicht weiter kommst und trotzdem mittesten willst, empfehle ich die Installation von Visual Studio 2010 und den Intel Composer. Du hättest dann die gleiche Software wie wir und mindestens 30 Tage Zeit (wegen des Intels Compilers), um damit zu experimentieren. Wenn das dann auch nicht funktioniert, müsstest Du wohl oder übel das Betriebssystem neu installieren :rolleyes: .
 

ralfkannenberg

Registriertes Mitglied
Ergebnis: Mond und Mars verlassen das Sonnensystem und vagabundieren irgendwo bei 1.0e5 bis 1.0e6 AU durch das freie All :confused: .
Hallo zusammen,

mein Kompliment - inzwischen seid Ihr so weit, dass Ihr bereits mit den ersten Testläufen Fehler in den Anfangsbedingungen eruieren könnt. Klasse !!

Ich glaub', das wird bald spannend :)


Freundliche Grüsse, Ralf
 

Bernhard

Registriertes Mitglied
Um die Periode auf 10 Tage einzustellen, musst du den letzten Wert in der erste Zeile in theia_param.in, der momentan 10 ist, auf 360 anheben.
Hallo SRMeister,

rechne das vielleicht auch selber noch mal nach, aber bei mir "diffundiert" der Mond bei diesen Einstellungen aus dem Sonnensystem.
 

Bernhard

Registriertes Mitglied
Also nehmen wir doch 1 Mondmasse für das grösste Fragment. Und dann vielleicht noch vier mit 0.1 Mondmassen dazu. Ich würde darüber hinaus die Bahnen (Abstrahlwinkel & Geschwindigkeit) dieser Fragmente einigermassen ähnlich setzen, innerhalb eines Dec/Rect Winkels von nicht mehr als 15°. Das heisst, in jeder Simulation könnte zuerst eine Hauptrichtung festgelegt werden, um die dann die tatsächlichen Fragmentbahnen geringfügig variiert werden. Die Geschwindigkeit der Trümmer sollte sich im Bereich zwischen 1 und 1.4 * v_esc bewegen.
Guten Morgen,

ich habe das versuchsweise mal mit einer sehr kleinen Schrittweite (par3 = 10, par4 = 0.1) und 200 masselosen Trümmern gerechnet. Die Ergebnisse sehen vom Überfliegen her so aus, als würden sich sämtliche Trümmer über die Erdbahn verteilen (mit Masse auf jeden Fall und ohne Masse mit Fragezeichen, weil ich nicht alle durchsuchen konnte). Inwieweit die Trümmer zusammenklumpen oder sich gleichmäßig verteilen kann ich im momentan nicht sagen. Keines der Trümmer hat das Sonnensystem verlassen.

Ich zweifle momentan auch ein wenig an manchen Informationen aus der Readme.first-Datei, weil diese Dateien nicht unbedingt immer aktuell sein müssen.
 

Bynaus

Registriertes Mitglied
Hallo Bernhard,
Ich hab das Programm noch nicht zum Laufen gekriegt, aber ich arbeite daran (wenn auch langsam...). Aber das klingt schon mal interessant - wie verteilen sie sich denn über die Erdbahn? Es müsste ja vermutlich auch solche geben, deren Bahnen diejenigen der anderen Planeten kreuzen? Kannst du mal ein Video davon (falls möglich?) auf YouTube laden (bzw. mir per Mail zukommen lassen)?

Die "Selbstverklumpung" der Trümmer würde ich jetzt mal ignorieren. Es geht ja erst mal darum, wo sie am Ende alle hinkommen. Wichtig wäre in diesem Zusammenhang die Implementierung von Kollisionen mit den Planeten und allenfalls dem Asteroidengürtel.
 

Bernhard

Registriertes Mitglied
Kannst du mal ein Video davon (falls möglich?) auf YouTube laden (bzw. mir per Mail zukommen lassen)?
Da muss ich aktuell leider passen, obwohl mich das selber sehr interessieren würde. Ich hatte ein wenig gehofft, dass das SRMeister machen würde, denn die Cpp-Schnittstellen sind ja jetzt vorhanden.

Wichtig wäre in diesem Zusammenhang die Implementierung von Kollisionen mit den Planeten und allenfalls dem Asteroidengürtel.
Ich muss mir da den Quelltext nochmal genau ansehen, ob so etwas nicht bereits implementiert ist. Falls man Kollisionen mit Asteroiden berechnen will, muss man diese bei den Startbedingungen definieren und das macht das Programm dann mehr und mehr rechenintensiv.

@SRMeister: Wie sieht es denn mit einem weiteren YouTube-Clip aus? Könntest Du so etwas mit dem vorhandenen Material machen? Die drei Parameter-Dateien kann ich Dir gerne zuschicken.
 

Bynaus

Registriertes Mitglied
Falls man Kollisionen mit Asteroiden berechnen will, muss man diese bei den Startbedingungen definieren und das macht das Programm dann mehr und mehr rechenintensiv.

Man könnte die Asteroiden ja als masselos annehmen und nur als "Zielkörper" (die mit ihrer Querschnittsfläche einfangen) in die Simulation einbauen. Aber ich würde sagen, das hat vorerst eine geringere Priorität.
 

Bernhard

Registriertes Mitglied
Kannst du mal ein Video davon (falls möglich?) auf YouTube laden (bzw. mir per Mail zukommen lassen)?
Hallo Bynaus,

ich werde in der verbleibenden Zeit, wo der Intel Composer bei mir noch läuft versuchen eine Visualisierung der SCATR-Ergebnisse zu programmieren. Die Library von SRMeister enthält dazu bereits recht brauchbare Funktionen.

@SRMeister: Könntest Du mir mal den gesamten Quelltext zur Erstellung der Library schicken? Besser wäre natürlich der gesamte Code Deiner Visualisierungstools. Ich würde mir dann alles mal durchsehen, damit wir hier bei der Interpretation der bereits vorhandenen Ergebnisse weiter kommen.
Gruß
 

Bernhard

Registriertes Mitglied
ich habe das versuchsweise mal mit einer sehr kleinen Schrittweite (par3 = 10, par4 = 0.1) und 200 masselosen Trümmern gerechnet. Die Ergebnisse sehen vom Überfliegen her so aus, als würden sich sämtliche Trümmer über die Erdbahn verteilen (mit Masse auf jeden Fall und ohne Masse mit Fragezeichen, weil ich nicht alle durchsuchen konnte). Inwieweit die Trümmer zusammenklumpen oder sich gleichmäßig verteilen kann ich im momentan nicht sagen. Keines der Trümmer hat das Sonnensystem verlassen.

Ich zweifle momentan auch ein wenig an manchen Informationen aus der Readme.first-Datei, weil diese Dateien nicht unbedingt immer aktuell sein müssen.
Der Debugger zeigt, dass der Wert par4=0.1 tatsächlich sehr schlecht gewählt ist. Die Position beispielsweise von Merkur friert damit einfach ein.

EDIT: Mit par3 = 10.0 und par4 = 1.0 bekommt man halbwegs vernünftige Werte. Weitere Tests mit dem Debugger zeigen, dass par3 die Schrittweite in Tagen sein sollte. Anders lassen sich die Ergebnisse nach 1, 2, 3, .... Schritten eigentlich nicht erklären.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Weitere Tests mit dem Debugger zeigen, dass par3 die Schrittweite in Tagen sein sollte. Anders lassen sich die Ergebnisse nach 1, 2, 3, .... Schritten eigentlich nicht erklären.
Mir ist dabei noch nicht klar, ob es besser ist die Schrittweite und den Teiler tinc generell klein zu wählen (z.B. 10 Tage und 1) oder beide groß. Da bei unseren Rechnungen der Teiler praktisch immer verwendet (alle relevanten Distanzen sind kleiner als 300 AU) wird, sollte diese Frage schon geklärt werden. Bei kleinen Schrittweiten sollte der Rechenfehler eigentlich kleiner sein, als bei großen Schrittweiten.

Viele und zum Teil wichtige Dokumenationen zum SCATR-Code und einige Papers zur Entstehung des Mondes findet man übrigens auf der akademischen Seite von Jack Wisdom:

http://groups.csail.mit.edu/mac/users/wisdom/

EDIT: Habe gerade gesehen, dass bei einer Simulation der wichtigsten Planeten mit Erdmond mit dt,tinc = (3600.0, 360.0) der Erdmond nicht von der Erde gebunden wird. Bei (10.0, 1.0) entfernt sich der Erdmond auf etwa 2,7 AU.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Hallo Bynaus und SRMeister,

ich habe heute unseren alten Code (s. Position der Planeten) so erweitert, dass der dortige Integrator zu einem symplektischen Integrator wird. Es waren dazu nur ein paar kleinere Anpassungen nötig. Als Anleitung habe ich diesen Wikipedia-Artikel verwendet: http://en.wikipedia.org/wiki/Symplectic_integrator . Die Mittelpunktsregel nennt sich dann Verlet-Methode. Der Programmablauf wird dadurch mindestens um einen Faktor 1.8 schneller!! Wir könnten vorerst also auch mit diesem Code weitermachen. Der ist im Vergleich zum SCATR-Code zwar noch immer eine "lahme Krücke", aber vielleicht bleibt der Mond bei diesem Programm ja zur Abwechslung mal auf seiner Bahn um die Erde :) . Mein Rechner braucht für eine Millionen Jahre knapp 27 Stunden Rechenzeit. Eine Berechnung über 100.000 Jahre wäre mit knapp 3 Stunden problemlos machbar. Ich denke, ich werde so eine Simulation in den nächsten Tagen versuchsweise mal laufen lassen.
Gruß
 

Bynaus

Registriertes Mitglied
Okay. Könnte es nicht sein, dass der Mond seine Bahn verlässt, weil ein Umlauf eben "nur" ein Monat dauert, die Zeitschritte bei der Berechnung also einen grossen Bruchteil seiner Umlaufszeit ausmachen? Der Mond ist in dieser Simulation in dem Sinn nicht so besonders wichtig, er hatte sich ja anfangs noch gar nicht gebildet und später wird er (wegen dem geringen Querschnitt) nur sehr wenige der Trümmer auffangen können. Wenn die Ergebnisse ohne Mond gut aussehen, dh zumindest die Planetenbahnen vernünftig berechnet werden, dann sehe ich keinen Grund, die Pferde umzusatteln.
 

Bynaus

Registriertes Mitglied
Ich war nun einige Tage auf Exkursion und während der langen Autofahrten hab ich u.a. über dieses Projekt ein bisschen nachdenken können. Ich weiss, dass meisten "Probleme" im Moment eher technischer Natur sind, aber ich versuche, hier eine gewisse Langzeitperspektive zu entwickeln. Für ein Programm, das die Bahnen von vorwiegend masselosen Teilchen durch das Sonnensystem simulieren kann, gibt es unterschiedliche Verwendungsarten, und ich hab grad ein paar Ideen für Projekte, die man dereinst damit realisieren könnte (die über die "TheiaSim" hinaus gehen, auf die ich zur Zeit aber noch nicht im Detail eingehen kann).

Ein möglicherweise wichtiger Punkt wäre, dass man für jedes (?) "fixe" Objekt im Sonnensystem (Planeten, Monde, grosse Asteroiden) wählen kann, ob man ihre Bahnen gemäss gravitativen Interaktionen rechnen will, oder ob man sie einfach als gravitativ auf die masselosen Teilchen agierende, aber nicht untereinander interagierende, "Zielkörper" auf festgelegten Bahnen bewegen will. Wenn die Rechenschritte sich dann zu sehr an die Umlaufzeiten annähern (Faktor 10-100?), sollte automatisch auf festgelegte Bahnen gewechselt werden. So kann man z.B. den Mond in der Simulation behalten: man lässt ihn einfach auf seiner bekannten Bahn um das Schwerezentrum des Erde-Mond-Systems kreisen.

Weiter wäre es wichtig, dass man für jedes "fixe" Objekt (gem. oben) einzeln festlegen kann, bei welcher Distanz ein masseloses Teilchen aus der Simulation entfernt werden soll. Bei der Erde ist z.B. eine Distanz von etwa 1000 km zur Oberfläche ein guter Wert, weil man da annehmen kann, dass die Bahn von masesarmen Teilchen durch die Interaktion mit der Exosphäre stark verändert wird (stärker, als man von der Gravitation alleine vermuten würde). Für einige der Projekte, die ich angedacht habe, wäre es auch wichtig, wenn man Geschwindigkeitsvektor und -richtung zum Zeitpunkt der Annäherung an die Erdoberfläche auf 1000 km (also dann, wenn das Teilchen aus der Simulation entfernt wird) speichern könnte.

Der letzte Punkt, der mir wichtig wäre, ist wohl bereits weitgehend realisiert: Ein Input-File, in dem die Positionen und anfänglichen Geschwindigkeiten (und Vektoren) aller zu simulierenden Teilchen gespeichert sind.
 

Bernhard

Registriertes Mitglied
Ich weiss, dass meisten "Probleme" im Moment eher technischer Natur sind, aber ich versuche, hier eine gewisse Langzeitperspektive zu entwickeln.
Hallo Bynaus,

ich habe mittlerweile mal probiert, das SCATR-Projekt mit Eclipse (Photran 7.0 mit Juno-Release) zu übersetzen, aber das hat leider nicht funktioniert. Eclipse liefert hier einige ziemlich kryptische Fehlermeldungen in den generierten Make-Dateien, was für mich auf irgendwelche internen Probleme von Eclipse hindeutet.

Der erweiterte Bulirsh-Stoer-Algorithmus liefert mittlerweile auch über eine Million Jahre ganz interessante Ergebnisse. Bei einer Schrittweite von 10 Tagen braucht das Programm nur einige Minuten für die Berechnung.
Gruß
 
Oben