Bahnsimulation für Planeten usw

Bynaus

Registriertes Mitglied
Toll - muss ich mir mal im Detail ansehen... Die Aussage, es würden nur Gravitationskräfte berücksichtig, weshalb man jedes mögliche Objekt ("Meteore") simulieren könne, stimmt mich ein wenig nachdenklich: schliesslich spielen gerade bei "Meteoren" (ich nehme an, sie meinen Meteoroiden, die Vorgängerobjekte von Meteoriten) nicht-gravitative Kräfte wie die Sonnenstrahlung (Stichwort: Yarkovsky, YORP-Effekt) eine Rolle. Anderseits kann man diese Kräfte für gewisse Fragestellungen vielleicht auch einfach vernachlässigen...

Ein Klassiker in der Forschung ist das "Mercury"-Programm von John Chambers. Ich habs (bisher auch aus Mangel an Bedarf) noch nie ausprobiert, es soll angeblich einige Arbeit erfordern, bis es läuft.

Ich hätte allerdings durchaus eine Idee für ein (reales) Projekt, das man mit einem wirklich guten Simulations-Programm durchführen könnte... :)
 

julian apostata

Registriertes Mitglied
Hier hätte ich eine ganz simple Simulation zu bieten, mit der man alle nur denkbaren Planetenbahnen konstruieren kann, die aber nur 2 Angaben verlangt, nämlich

http://www.muenster.de/~breitens/referate/kepler/phys/kepler.htm#k4

a=die grosse Halbachse
e=Exzentrität

Wobei gilt

[TEX]a=\frac{r_1+r_0}{2}\qquad \varepsilon=\frac{r_1-r_0}{r_1+r_0}[/TEX]

Beispiel. Wir konstruieren eine Asteroidenbahn mit

r1=4AE
r0=1AE

Dann brauchen wir nur a=2,5 und e=0,6 eingeben.
 

SRMeister

Registriertes Mitglied
Bynaus, erzähl doch mal etwas detaillierter was dir vorschwebt.
Solange es nicht um Mio. oder Mrd. Jahre und Objekte geht lässt sich doch was Vorhandenes anpassen.
 

Bynaus

Registriertes Mitglied
Gerne. Ich wollte mal sehen, ob sich hier jemand für sowas überhaupt interessiert...

Also, mir geht es um folgendes: Vielleicht habt ihr mitbekommen, dass ich an einem Paper zur Mondenstehung (einer neuen Variation zum Giant Impact) beteiligt war (A hit-and-run Giant Impact scenario).

Demnach hätte sich der Mond auch aus einer "Streifschuss-Kollision" bilden können, wobei ein grosser Teil von Theia (dem Impaktor) in zertrümmerter Form das Erde-Mond-System verlässt. Man hat hier also fast eine Marsmasse an Trümmern, die nun im Sonnensystem herumfliegen. Die Frage ist, was nun damit geschieht, und ob man damit rechnen kann, dass ein Teil davon (wieviel?) im Asteroidengürtel landet. Mir schebt sowas vor wie die Simulation von masselosen Testkörperchen, die, sagen wir der Einfachheit halber, kugelsymetrisch und mit ca. 1 bis 1.4 * v_esc (v_esc=11 km/s rel. zum Erdmittelpunkt) vom Erde-Mond-System aus ins Sonnensystem (mit Planeten wie heute bekannt) geschleudert werden. Vielleicht könnte man auch ein paar grössere Brocken von bis zu einigen 100 km Durchmesser hinzu nehmen. Man könnte z.B. fragen, wieviel dieser Masse am Ende von der Erde akkretiert wird, wieviel man auf den Nachbarplaneten erwartet und wieviele im Asteroidengürtel enden.

Wenn sich ein paar interessierte finden und da auch was vernünftiges rauskommt, könnte man das sicher publizieren.
 

SRMeister

Registriertes Mitglied
Das klingt auf jedenfall sehr interessant.
Wie werden die Brocken denn ihre Exzentrizität los? Gabs zu dem Zeitpunkt denn noch eine nennenswerte Staubscheibe? Die müsste man dann noch mit einbeziehen.
So gesehen könnte man das auf alltäglichen PCs sicher simulieren, die Rechenschritte sind ja recht einfach dank der masselosen Partikel und sehr hohe Genauigkeit braucht man ja auch nicht.
Welche Zeiträume betrachtet man denn da? Denke so 100k Jahre sollten es schon mindestens sein aber das ist machbar.

Bernhard ist doch sicher auch wieder dabei?
Ich habe unser Programm in der Zwischenzeit auch etwas weiterentwickelt (vor allem vereinfacht und das GUI verbessert), darauf könnte man doch aufbauen... dann hätte es endlich mal ne Verwendung :)
 
Zuletzt bearbeitet:

Bynaus

Registriertes Mitglied
Wie werden die Brocken denn ihre Exzentrizität los?

Nun, das müssen sie so nicht - oder meinst du, im Asteroidengürtel? Ja, das könnte ein Problem sein, weil man dafür wohl nahe Vorbeiflüge an Hauptgürtelasteroiden braucht, die man dann entsprechend auch simulieren müsste (?). Es gibt ein Paper von Bottke et al. (2006), wo sie so einen "Implantations"-Prozess für gewisse Typen von Meteoriten vorschlagen - ich such das mal raus und kann es allen interessierten zukommen lassen.

Gabs zu dem Zeitpunkt denn noch eine nennenswerte Staubscheibe?

Schwierig zu sagen - vielleicht müsste man beide Fälle rechnen.

Welche Zeiträume betrachtet man denn da? Denke so 100k Jahre sollten es schon mindestens sein aber das ist machbar.

Ja, oder noch besser für längere Zeit. So lange halt, bis die meisten Partikel irgendwo ein Ende gefunden haben.

Ich frage mich, ob man allenfalls auch die oben erwähnten, nicht-gravitativen Kräfte einbeziehen müsste. Dann wirds allerdings gleich wieder etwas komplizierter mit der Rechnung (evtl. könnte man diese als konstante Kraft entgegen der Bewegungsrichtung modellieren? Dem müsste man mal nachgehen).
 

SRMeister

Registriertes Mitglied
Also die großen Asteroiden könnte man mit geringem Kostenaufwand einfügen, indem man denen einfach nur die Sonne als gravitativen Gegenpart gibt - so sind die fast kostenlos und der Rechenaufwand bleibt linear.
Die Trümmer selbst sind masselos, da steigt der Rechenaufwand ebenfalls nur linear.
Alle nicht-linearen teuren Körper sind die Planeten und ich denke da können wir auch ein paar weglassen.

Yarkovski und YORP kann man sicher in dem Bereich des Sonnensystems der uns interessiert, mit einer einfachen linearen Funktion vom Abstand von der Sonne abschätzen? Sonst nimmt man eine Lookup-Table.

So bleibt das Ganze auf normaler Hardware lösbar.

Ein Problem sind in meinen Augen die großen Integrationsschritte. Während der Integration kann keine Kollision erkannt werden - Hindernisse werden getunnelt. Man braucht also einen adaptiven Algorithmus und das wäre auch der Punkt wo ich gerne Bernhard im Bot hätte. Bei den Integrationsverfahren hat er ja den Großteil der Arbeit geleistet und das theoretische Wissen mitgebracht.
Man müsste also den BS-Algo adaptiv machen. Genug Paper dazu gibt es auf Arxiv, weil das ja der allgemein gängige Weg ist.
Ich kann außerdem damit dienen, das GUI so zu gestalten, dass du die Startbedingungen nach deinen Wünschen eingeben kannst und das Resultat in gewünschter Form angezeigt wird, zb als Diagramm, Exceltabelle, oder so.

Edit: YORP kann man wohl gleich ganz weglassen.
 

Bynaus

Registriertes Mitglied
Alle nicht-linearen teuren Körper sind die Planeten und ich denke da können wir auch ein paar weglassen.

Vielleicht könnte man bei diesen genauso verfahren wie bei den grossen Asteroiden? Schliesslich wollen wir nicht unbedingt die Bewegung der Planeten simulieren, sondern wir wollen sehen, was mit den Trümmern geschieht.

Ein Problem sind in meinen Augen die großen Integrationsschritte.

Ja, das ist in der Tat ein Problem. Selbst wenn wir nur den Bereich zwischen Merkur und dem dichtesten Teil des Asteroidengürtels nehmen, dann haben wir doch Umlaufzeiten von zwischen 80 Tagen und 3 Jahren.

Ich kann außerdem damit dienen, das GUI so zu gestalten, dass du die Startbedingungen nach deinen Wünschen eingeben kannst und das Resultat in gewünschter Form angezeigt wird, zb als Diagramm, Exceltabelle, oder so.

Klingt gut. Vielleicht wäre es auch interessant, wenn man erst eine Reihe von zufälligen Startbedingungen (von einem Programm) jeweils in ein File schreiben könnte. Diese Files könnten dann von verschiedenen interessierten Usern laufen gelassen werden - so bekämen wir evtl. sowas wie eine "Monte-Carlo"-Simulation hin.
 

ismion

Registriertes Mitglied
Alle nicht-linearen teuren Körper sind die Planeten und ich denke da können wir auch ein paar weglassen.

Könnte man nicht einfach die Planeten "indirekt" implementieren, indem man das Gravitationspotential in bestimmten Bereichen leicht abändert?
Ich bin nicht auf dem Stand, den ihr habt, bzgl. des Programmes, aber viel sollte sich ja nicht ändern, wenn ihr die einbaut. Zumindest zur Ausbildung des Asteroidengürtels sollten die wichtig sein, da sie ja schon eine "gravitative Abbremsung" bewirken, denke ich.


Yarkovski und YORP kann man sicher in dem Bereich des Sonnensystems der uns interessiert, mit einer einfachen linearen Funktion vom Abstand von der Sonne abschätzen? Sonst nimmt man eine Lookup-Table.

Was sind Yarkovski und YORP? :(

Ein Problem sind in meinen Augen die großen Integrationsschritte. Während der Integration kann keine Kollision erkannt werden - Hindernisse werden getunnelt. Man braucht also einen adaptiven Algorithmus und das wäre auch der Punkt wo ich gerne Bernhard im Bot hätte. Bei den Integrationsverfahren hat er ja den Großteil der Arbeit geleistet und das theoretische Wissen mitgebracht.
Man müsste also den BS-Algo adaptiv machen. Genug Paper dazu gibt es auf Arxiv, weil das ja der allgemein gängige Weg ist.

Adaptive zeitliche Integration ist immer ein Problem, finde ich, da dort die Synchronität der Simulation verloren geht. Was ich mal gemacht habe während meiner Masterarbeit war, Kollisionen über einen stochastischen Ansatz zu beschreiben. Das würde einiges erleichtern.
Oder eben ein Subgrid-Model, wo Kollisionspartner mit einem Subcycling-Algorithmus modelliert werden, sodass der globale Integrationsschritt erhalten bleibt. Da stellt sich dann nur die Frage, wie hoch der Aufwand ist, wenn viele Partikel kollidieren.

Gruß
Basti


Edit: YORP kann man wohl gleich ganz weglassen.
 

Bernhard

Registriertes Mitglied
Man müsste also den BS-Algo adaptiv machen. Genug Paper dazu gibt es auf Arxiv, weil das ja der allgemein gängige Weg ist.
Hallo zusammen,

da hat sich ja ein recht interessantes Thema ergeben!

@SRMeister: Ich würde hier lieber bei jedem Integrationsschritt prüfen, ob sich ein Fragment innerhalb einer Kugel mit definiertem Radius um jeden Planeten befindet. Das wäre leicht zu implementieren und wäre die passende Bedinung für einen Einfang eines Fragmentes. Man hätte dann für jeden Planeten einen "Fragmentzähler" und könnte am Ende der Simulation sagen, welcher Planet wieviele Fragmente eingefangen hat.

1) Für die Realisierung dieses Vohabens könnte SRMeister eine neue Programmversion (Branch) speziell für dieses Projekt anlegen und als Download verfügbar machen. Ich könnte mir da ein neues Thema im Bereich Software & Programmierung vorstellen, das dann einen entsprechenden Download-Link enthalten sollte. Könntest Du das einfach mal so anlegen Stefan?

2) Ich würde dann den erwähnten Zähler einbauen.

3) Anschließend könnte man in die verlinkte Liste die Fragmente einbauen. Man bräuchte dann nur noch die Startbedingungen für sagen wir mal 100 Fragmente für den Anfang. Es wäre schön, wenn eine dritte Person (eventuell Bynaus?) diese Startbedingungen festlegen würde.

4) Da das eigentliche Programm keinerlei Zufallskomponenten enthält, würde es genügen, das modifizierte Programm auf einigen PCs laufen zu lassen, um die nötige Redundanz bei den Daten zu erhalten. Ich denke drei bis vier unabhängige PCs würden da schon reichen.

Letztlich bliebe bei diesem Vorgehen dann nur noch zu klären, ob die gravitative Wirkung der Fragmente auf die Planeten berücksichtigt werden soll. Man könnte das in der angesprochenen Version aber recht leicht ausbauen und hätte dann nur noch Testkörper, deren Bahnen nur noch von der Sonne und den Planeten bestimmt werden. Die Notwendigkeit für eine adaptive Schrittweite sehe ich momentan noch nicht als gegeben :) .
Gruß
 

ismion

Registriertes Mitglied
Hallo zusammen,

da hat sich ja ein recht interessantes Thema ergeben!

@SRMeister: Ich würde hier lieber bei jedem Integrationsschritt prüfen, ob sich ein Fragment innerhalb einer Kugel mit definiertem Radius um jeden Planeten befindet. Das wäre leicht zu implementieren und wäre die passende Bedinung für einen Einfang eines Fragmentes. Man hätte dann für jeden Planeten einen "Fragmentzähler" und könnte am Ende der Simulation sagen, welcher Planet wieviele Fragmente eingefangen hat.

Hierbei musst Du bedenken, Bernhard, dass dann der Zähler in jedem Schritt die Anzahl der Fragmente innerhalb der Kugel ausgibt. Um eine Aussage über den Einfang eines Fragmentes machen zu können müsste man - meiner Meinung nach - noch ein paar Kriterien an die Fragmente stellen:
1) Deine Bedingung: Ist Fragment innerhalb des Kugelradius?
2) Ist v_fragment < v_esc,körper?
2.1) oder 3) Ist Energie des Systems Fragment-Körper < 0, sodass ein gebundener Zustand vorliegt?

Ist nur ein Brainstorming zu eurer Unterstützung, aber das würde die Auswahl einschränken und somit "vorbeirauschende" Fragmente außer acht lassen.

Gruß
Basti
 

Bernhard

Registriertes Mitglied
1) Deine Bedingung: Ist Fragment innerhalb des Kugelradius?
2) Ist v_fragment < v_esc,körper?
2.1) oder 3) Ist Energie des Systems Fragment-Körper < 0, sodass ein gebundener Zustand vorliegt?
Hi Basti,

aus Zeitgründen würde ich erst mal nur 1) implementieren. 2) Ist mir zu ungenau, weil das doch nur für radiale Bahnen gilt (?). Bei 2.1 weiß ich nicht, wie man das implementieren sollte.
Gruß
 

ismion

Registriertes Mitglied
Hi Basti,

aus Zeitgründen würde ich erst mal nur 1) implementieren. 2) Ist mir zu ungenau, weil das doch nur für radiale Bahnen gilt (?). Bei 2.1 weiß ich nicht, wie man das implementieren sollte.
Gruß

Man könnte bei 2.1 die kinetische und potentielle Energie ausrechnen und prüfen ob E_gesamt < 0. Das wäre ja der Fall, wenn E_kin < E_pot,gravitativ.

Genau so etwas fände ich schon mal ganz interessant. Es wären vorerst natürlich nur die echten Abstürze pro Planet.

Ja, das fände ich auch interessant. Könnte man das nicht sogar weitertreiben und angeben, wie viele Fragmente vom Planeten akkretiert werden? Geht natürlich nur, sofern die Planeten eine Ausdehnung haben und nicht als Punktmassen beschrieben werden.
 

Bernhard

Registriertes Mitglied
Man könnte bei 2.1 die kinetische und potentielle Energie ausrechnen und prüfen ob E_gesamt < 0. Das wäre ja der Fall, wenn E_kin < E_pot,gravitativ.
Stimmt. Das wäre ein guter Ansatz. Man müsste sich dabei aber noch überlegen, wie weit der Einflußbereich eines Planeten reicht, um Swing-by-Effekte an anderen Planeten auszuschließen.

Geht natürlich nur, sofern die Planeten eine Ausdehnung haben und nicht als Punktmassen beschrieben werden.
Klar. Der Radius des Planeten wird dann berücksichtigt.
 

Bynaus

Registriertes Mitglied
Ich will nur nochmals ein paar Erklärungen nachschieben, damit nicht vergessen geht, wohin das ganze sich (idealerweise) entwickeln sollte:

Wir wollen wissen:

1) wie viele Fragmente dieser Kollision (dh, welcher Bruchteil) landet auf welchen Planeten, etwa nach welcher Zeit? Insbesondere die Erde und der sich bildende Mond (den kann man wohl nach ein paar Jahrtausenden als gebildet annehmen) wären interessant, aber auch Merkur (weil man die Trümmer dort noch heute zusammenlesen könnte).
2) Welcher Bruchteil kollidiert mit einem Hauptgürtel-Asteroiden? (dh, wieviele Fragmente von Theia erwarten wir in Regolith-Brekzien (=Ansammlungen von Trümmern von der Oberfläche von Asteroiden)?)
3) Welcher Bruchteil der Trümmer endet in einer klassischen Asteroidengürtelbahn (und wo genau im Asteroidengürtel?)?

Ich würde hier lieber bei jedem Integrationsschritt prüfen, ob sich ein Fragment innerhalb einer Kugel mit definiertem Radius um jeden Planeten befindet.

Meinst du damit den Planetenradius? Dann verpassen wir die Kollision, wenn sie nicht exakt an der Grenze zwischen zwei Integrationsschritten geschieht. Oder verstehe ich dich falsch? Müsste man nicht vielmehr prüfen, ob seine interpolierte Bahn weniger als einen Planetenradius vom Schwerzentrum des Planeten weg durchläuft?

Man müsste wohl darüber hinaus auch das gravitational focussing in Betracht ziehen. Dieses (bzw. der Radius, bei dem es noch akkretiert wird) hängt aber von der Geschwindigkeit des Fragments ab.

Die Fluchtgeschwindigkeit ist, denke ich, nicht so wichtig, weil man freie Einfänge in einen "Mondorbit" wohl vernachlässigen kann (solche wären langfristig eh nicht stabil). Ein Fragment, das sich einem Planeten aus einem ungebundenen Orbit nähert, wird immer schneller als mit Fluchtgeschwindigkeit relativ zum Planeten unterwegs sein (es sei denn, es kollidiert mit dem Planeten...).

Es wäre schön, wenn eine dritte Person (eventuell Bynaus?) diese Startbedingungen festlegen würde.

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).

Weiter wäre es gut, ein paar grössere Brocken (sagen wir, 1 Promille der Mondmasse oder 350 km Durchmesser bei gleicher Dichte) auf ihrem Weg durchs innere Sonnensystem zu verfolgen. Hier würden ein paar Dutzend Objekte (so dass alle radialen Richtungen einigermassen abgedeckt wären) genügen. Bei diesen Brocken könnte man wohl die Masse der Planeten so lange vernachlässigen, bis sie in die Nähe eines Planeten kommen (oder?).
 

ismion

Registriertes Mitglied
Bynaus, es brauchen gar nicht so viele mitmachen (ich will jetzt keinen daran hindern). Warum den Integrator nicht einfach erweitern auf N Teilchen, die gleichzeitig simuliert werden?
Dann trägst du als Output einfach den Zeitschritt raus, sowie die Koordinaten eines jeden Partikels innerhalb der Simulationsbox. Wenn die Trümmer alle als masselos angenommen werden kannst Du gravitative Wechselwirkungen untereinander vernachlässigen und erhälst ein (fast) lineares "Problem" a la M*N, mit N=Anzahl der Trümmer und M=Anzahl der Planeten (+ Sonne). Das sollte machbar sein auf nem normalen Rechner.

Was für einen Integrator nutzt ihr denn für die numerische Integration? Ist der symplektisch (in Bezug auf die Planetenbewegung falls diese nicht als statisch angenommen werden)?

Können sich die Trümmerteile auch zusammenpacken?

Gruß,
Basti
 

Bernhard

Registriertes Mitglied
Was für einen Integrator nutzt ihr denn für die numerische Integration?
Es gab da vor einiger Zeit mal dieses Thema hier http://astronews.com/forum/showthread.php?5102-Sonnensystem-Position-der-Planeten, aber von dem dort entwickelten Code existieren offensichtlich auch nur noch Fragmente. Grmpff :mad: .

EDIT: Habe in meinen privaten Quellen noch die letzte Version von damals gefunden :) . Dieser Integrator hatte brauchbare Ergebnisse für vergleichsweise kurze Simulationszeiten von einem Jahr geliefert. Vielleicht sollte ich diesen Code zuerst mal bei sourceforge.net veröffentlichen? Man könnte dann testen, wie dieser Integrator Zeiten über eine Milliarde Jahre bewältigt.
 
Zuletzt bearbeitet:

SRMeister

Registriertes Mitglied
Vielleicht könnte man bei diesen genauso verfahren wie bei den grossen Asteroiden? Schliesslich wollen wir nicht unbedingt die Bewegung der Planeten simulieren, sondern wir wollen sehen, was mit den Trümmern geschieht.
Das ist eine gute Idee, das ist schonmal vorgemerkt.



Ja, das ist in der Tat ein Problem. Selbst wenn wir nur den Bereich zwischen Merkur und dem dichtesten Teil des Asteroidengürtels nehmen, dann haben wir doch Umlaufzeiten von zwischen 80 Tagen und 3 Jahren.
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. Wenn alle Teilchen auf ihren eigenen kreisförmigen (kaum exzentrischen) Bahnen dahinschweben, kann man schon vorher voraussagen, dass nicht viel passieren wird und größere Schritte gehen. Leider sind die Fragmente ja eben auf genau dem Gegenteil einer kreisförmigen Bahn.


Klingt gut. Vielleicht wäre es auch interessant, wenn man erst eine Reihe von zufälligen Startbedingungen (von einem Programm) jeweils in ein File schreiben könnte. Diese Files könnten dann von verschiedenen interessierten Usern laufen gelassen werden - so bekämen wir evtl. sowas wie eine "Monte-Carlo"-Simulation hin.
Ist vorgemerkt. Sowas wird sich ganz einfach umsetzen lassen.

Könnte man nicht einfach die Planeten "indirekt" implementieren, indem man das Gravitationspotential in bestimmten Bereichen leicht abändert?
Ich bin nicht auf dem Stand, den ihr habt, bzgl. des Programmes, aber viel sollte sich ja nicht ändern, wenn ihr die einbaut. Zumindest zur Ausbildung des Asteroidengürtels sollten die wichtig sein, da sie ja schon eine "gravitative Abbremsung" bewirken, denke ich.
Nunja, "indirekt"... hmm ... man könnte sie vielleicht zufällig auf ihren Bahnen springen lassen, also quasi keine Integration durchführen sondern durch Keplerbahnen abschätzen... Das wird auch in der Forschung so gemacht....
Aber eine konstante Position ist denke ich eher schlecht für das Ergebnis.


Was sind Yarkovski und YORP? :(
Siehe Wikipedia (Ist wohl leider momentan down sonst hätte ich Links rausgesucht)


Adaptive zeitliche Integration ist immer ein Problem, finde ich, da dort die Synchronität der Simulation verloren geht.
Der nächst kleiner Zeitschritt ist natürlich immer die Hälfte des größeren. Man muss auch nicht alle Körper in den kleinen Schritten simulieren, sondern nur die beiden die sich nahe kommen. So ist das üblich in den modernen adaptiven Bulirsch-Stoer-Integratoren. So würde ich das gerne machen, da können wir auf vorhandenes Wissen aufbauen und müssen das Rad nicht neu erfinden. Uns kommt zugute dass wir keine großen Teilchenzahlen haben, da wären Ansätze wie Barnes-Hut vollkommen fehl am Platz. Die wären wesentlich langsamer als ein gut gemachter adaptiver BS.


@SRMeister: Ich würde hier lieber bei jedem Integrationsschritt prüfen, ob sich ein Fragment innerhalb einer Kugel mit definiertem Radius um jeden Planeten befindet.
Also die Idee mit dem Radius kann ich momentan garnicht nachvollziehen, außer als Indiz für die Verkleinerung der Zeitschritte.
Ich teile da Bynaus zweifel:

Meinst du damit den Planetenradius? Dann verpassen wir die Kollision, wenn sie nicht exakt an der Grenze zwischen zwei Integrationsschritten geschieht. Oder verstehe ich dich falsch? Müsste man nicht vielmehr prüfen, ob seine interpolierte Bahn weniger als einen Planetenradius vom Schwerzentrum des Planeten weg durchläuft?


1)Für die Realisierung dieses Vohabens könnte SRMeister eine neue Programmversion (Branch) speziell für dieses Projekt anlegen und als Download verfügbar machen. Ich könnte mir da ein neues Thema im Bereich Software & Programmierung vorstellen, das dann einen entsprechenden Download-Link enthalten sollte. Könntest Du das einfach mal so anlegen Stefan?
Werde ich machen sobald ich auch den core auf Visual 2010 Express kompilieren kann, damit wirklich jeder Interessierte mit kostenlosen Tools mitmachen kann und damit wir alle die gleichen Vorrausetzungen haben.
Ich erkläre jetzt einfach Visual C++ 2010 Express (Download hier) als Vorraussetzung. Punkt. Außerdem wird es kompilierte Versionen geben, also für Leute die das Prog testen wollen und nicht programmieren wollen.

Letztlich bliebe bei diesem Vorgehen dann nur noch zu klären, ob die gravitative Wirkung der Fragmente auf die Planeten berücksichtigt werden soll. Man könnte das in der angesprochenen Version aber recht leicht ausbauen und hätte dann nur noch Testkörper, deren Bahnen nur noch von der Sonne und den Planeten bestimmt werden. Die Notwendigkeit für eine adaptive Schrittweite sehe ich momentan noch nicht als gegeben :) .
Gruß
Die Fragmente sind so klein und leicht, ich denke die können wir als m=0 ansetzen. Ohne adaptive Schrittweite müssen wir die Schrittweite so wählen, dass keine Kollision verloren geht, da wären wir bei Schrittweiten von ein paar Sekunden/Minuten. Obwohl der BS- Algo mit Schrittweiten von Jahren sehr genau war.

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).
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.

Grüße
 
Oben