Bahnsimulation für Planeten usw

SRMeister schrieb:

Integrationsschritte mit dem BS-Algorithmus können gut und gerne 1 Jahr oder mehr sein, man muss eben vorher abschätzen ob in dem Zeitraum irgendwas passiert.

Zum Vergrößern anklicken....

Ich habe heute Nachmittag "unseren" Integrator mal auf eine Zeitspanne von 1 Millionen Jahre bei einer Schrittweite von einem Tag losgelassen, weil 1000 Jahre in ein paar Sekunden berechnet wurden. Nach einer halben Stunde habe ich dann abgebrochen. Vielleicht kann Bynaus hier sinnvolle Werte bezüglich der Rechengenauigkeit und Gesamtzeit vorgeben?

Die Kalenderfunktionen kommen mit diesen Zeitspannen schon lange nicht mehr klar (da ist bei 2057 Schluss), aber das ist vorerst nicht wirklich wichtig.

Wenn alle Teilchen auf ihren eigenen kreisförmigen (kaum exzentrischen) Bahnen dahinschweben, kann man schon vorher voraussagen, dass nicht viel passieren wird

Zum Vergrößern anklicken....

Nun, bei den Ausgangsbedingungen wird das aber selten der Fall sein: Die Teilchen sind mit einer ziemlich grossen Relativgeschwindigkeit zur Erde unterwegs (immerhin etwa 1/3 von deren Orbitalgeschwindigkeit), das dürfte zu ziemlich exzentrischen Bahnen führen.

Es wäre vielleicht interessant, die Startverteilung mit der Zielverteilung in Relation zu setzen. Also vielleicht auf einem Startbild farblich markieren, welche Asteroiden später in welchem Bereich landen. So oder so ähnlich.

Zum Vergrößern anklicken....

Ja, das wäre mit Sicherheit interessant.

Noch eine allgemeine Bemerkung: Es lohnt sich vielleicht, mal kurz zu überlegen, ob man einige der bestehenden Integratoren (z.B. den erwähnten "Mercury"-Code von J. Chambers) irgendwie einbeziehen kann. Der Vorteil ist, dass ein solcher in der Wissenschaftswelt bekannt und zudem gut dokumentiert ist. Wenn wir einen von Grund auf selbstgebastelten Code benutzen, wird man diesem nicht so trauen bzw. man (ein Reviewer) wird fordern, dass wir erst mal separat demonstrieren sollten, dass der Code überhaupt zuverlässig funktioniert. Vielleicht kommen wir damit durch, wenn wir sagen, dass wir mal ganz generell "erste Überlegungen" in Richtung einer solchen Trümmersimulation machen wollen. Aber vielleicht sollte man es auch gleich von Anfang an "richtig" machen.

EDIT:

Vielleicht kann Bynaus hier sinnvolle Werte bezüglich der Rechengenauigkeit und Gesamtzeit vorgeben?

Zum Vergrößern anklicken....

Nun, wenn ich mal irgend eine Zahl nennen soll, dann wären z.B. 10'000 Fragmente (masselos) und 100 Asteroiden (mit 1 Promille der Mondmasse?) und vielleicht 10 grosse Asteroiden (10 Prozent der Mondmasse?), integriert über einige Millionen Jahre (oder so lange, bis die meisten Fragmente eliminiert sind) ein sehr guter Anfang. Wie gesagt, das ist jetzt nur mal über den Daumen gepeilt - ich habe keine Ahnung, ob das realistisch ist. Wenn es kein Problem ist, kann das gut erweitert werden.
Ich muss aber mal nachschlagen, welche Massenverteilung man bei Kollisionstrümmern eigentlich erwartet - dh, wenn ihr mir sagt, wieviele massereiche Trümmer man in etwa simulieren kann, kann ich nachschlagen, welche Masse diese realistischerweise haben sollten.

Ich habe mir den Mercury schonmal früher angeschaut. Leider ist der in Fortran geschrieben, da hab ich nicht wirklich durchgeblickt.
Ansonsten scheint der ja ganz gut zu sein, ich denke es ist nicht unrealistisch dass wir den so in etwa nachbauen können.

Bynaus schrieb:

Nun, wenn ich mal irgend eine Zahl nennen soll, dann wären z.B. 10'000 Fragmente (masselos) und 100 Asteroiden (mit 1 Promille der Mondmasse?) und vielleicht 10 grosse Asteroiden (10 Prozent der Mondmasse?), integriert über einige Millionen Jahre (oder so lange, bis die meisten Fragmente eliminiert sind) ein sehr guter Anfang. Wie gesagt, das ist jetzt nur mal über den Daumen gepeilt - ich habe keine Ahnung, ob das realistisch ist. Wenn es kein Problem ist, kann das gut erweitert werden.

Zum Vergrößern anklicken....

Ich könnte in unser Programm eine neue Klasse CFragment einbauen und das Trümmerfeld als unabhängige, verlinkte Liste implementieren. Die Fragmente würde ich dann mit Masse abspeichern, wegen F = m*a. Die gravitative Wirkung der Trümmer auf die Planeten würde ich aber vernachlässigen. Das Programm würde damit in zwei sehr übersichtliche Teile zerfallen:
a) Das Sonnensystem mit Sonne-Erde-Mond-Planeten usw., das für sich alleine berechnet werden kann
b) Das Trümmerfeld, welches durch das Gravitationsfeld von a) beschleunigt wird.

Ich habe mir den Mercury schonmal früher angeschaut. Leider ist der in Fortran geschrieben, da hab ich nicht wirklich durchgeblickt. Ansonsten scheint der ja ganz gut zu sein, ich denke es ist nicht unrealistisch dass wir den so in etwa nachbauen können.

Zum Vergrößern anklicken....

Ist das nicht eine gewaltige Arbeit? Letztlich ist es natürlich kein absolutes must, sich an ein bestehendes Programm anzulehnen bzw. dieses zu verwenden.

Man kann ein Programm auch validieren, in dem man z.B. die gleiche Ausgangssituation in Mercury und im eigenen Programm laufen lässt und die Ergebnisse vergleicht.

wegen F = m*a

Zum Vergrößern anklicken....

Nun, m kürzt sich ja auf der anderen Seite (F kommt ja letztlich aus GmM/R^2) wieder raus, also a = GM/R^2.

a) Das Sonnensystem mit Sonne-Erde-Mond-Planeten usw., das für sich alleine berechnet werden kann
b) Das Trümmerfeld, welches durch das Gravitationsfeld von a) beschleunigt wird.

Zum Vergrößern anklicken....

Das klingt in meinen Ohren sehr vernünftig.

Hallo alle,

erst mal möchte ich mich dafür entschuldigen, dass ich mich so spät melde. Ich komme aufgrund von Zeitmangel im Moment nicht so oft dazu, bei Astronews vorbeizuschauen. Ebenfalls deswegen kann ich zu eurem Projekt fürs Erste Nichts beitragen. Ich möchte nur sagen, dass ich aufgrund dieses Artikels diesen Thread eröffnet habe, welcher sich eben auf Bynaus Arbeit bezieht. Tja so ein Zufall

mit freundlichen Grüßen

Bynaus schrieb:

Nun, m kürzt sich ja auf der anderen Seite (F kommt ja letztlich aus GmM/R^2) wieder raus, also a = GM/R^2.

Zum Vergrößern anklicken....

Stimmt. Die Masse spielt dann bei den Testkörpern keine Rolle.

Bynaus schrieb:

Da wir nicht wissen, in welche Richtung das Material davongeschleudert wurden, würde ich vorschlagen, eine sphärische Wolke von Trümmern zu simulieren, die sich radial mit anfänglich v = 1 - 1.4 * v_esc von der Position der Erde entfernen. Dann kann man ja immer noch die Fragmente so durchnummerieren, dass man am Ende weiss, welches am Anfang in welche Richtung ausgesandt wurde. Hier wären so viele Fragmente wie möglich zu simulieren (mal sehen, wie viele hier mitmachen und Orbits beitragen könnten).

Zum Vergrößern anklicken....

Das klingt machbar und ich werde versuchen, das heute inklusive Zufallsgenerator einzubauen. Als Parameter soll dann nur die Anzahl der Fragmente vorgegeben werden.

SRMeister schrieb:

Ich habe mir den Mercury schonmal früher angeschaut. Leider ist der in Fortran geschrieben, da hab ich nicht wirklich durchgeblickt.
Ansonsten scheint der ja ganz gut zu sein, ich denke es ist nicht unrealistisch dass wir den so in etwa nachbauen können.

Zum Vergrößern anklicken....

Ich habe mir den mercury-code mal runtergeladen und werde demnächst mal drüber schauen. vielleicht kann man damit wirklich vergleichs-simulationen machen, wie Bynaus vorschlägt. Man müsste dann den output so ausschreiben, dass man z.B. relative abweichungen aufzeigen kann, um die ergebnisse zu untermauern. weiterhin sollten tests absolviert werden, die die (in-)stabilität des integrators aufzeigen, wenn die zeitschritte zu groß gewählt sind.

der mercury-code nutzt (auf den ersten blick in die einzeilige beschreibung auf der homepage) einen symplektischen integrator. das könnte möglichen referees ein dorn im auge sein, sofern der vergleichscode sowas nicht hat.

ismion schrieb:

das könnte möglichen referees ein dorn im auge sein, sofern der vergleichscode sowas nicht hat.

Zum Vergrößern anklicken....

Dann hätten wir ein Problem mit der hauseigenen Lösung, weil dort nämlich keine Hamilton-Mechanik, sondern direkt die newtonsche Mechanik mit ihren zweiten Ableitungen integriert wird. Sollte hier ein "Update" gewünscht werden, können wir gleich den mercury-code verwenden, respektive nach C übersetzen. Linux bietet hier Übersetzungstools.

nimm meine aussage nicht allzu "ernst", da ich als doktorand (noch) keine erfahrung mit referees gemacht habe :-D
ich habe halt nur während des studiums (aus persönlichem interesse) festgestellt, dass die tendenz eher zu symplektischen integratoren geht. aber vielleicht habe ich auch nur einen kleinen einblick erhalten und meine vorstellugn ist falsch.

wenn dein übersetzungstool auch Fortran 77 nach C übersetzen kann, dann sollte das einfach sein ;-) Habe gerade mal in den Source-Code geschaut. Schön altes Fortran und der komplette code in einer Datei