Entstehung des Mondes

Bernhard

Registriertes Mitglied
Hallo Bynaus,

nachdem ich mich an Deinem Projekt zur Simulation der Entstehung des Mondes als Feierabendprojekt auch weiterhin beteiligen will, mache ich mal dieses Thema hier auf. Die Zusammenarbeit mit SRMeister funktioniert bei mir einfach nicht. Deshalb habe ich meine Quellen bei sourceforge.net in ein eigenes Projekt eingestellt:

http://sourceforge.net/projects/originofthemoon/files/

Bei den Quellen, die ich Dir per eMail zugeschickt hatte, hat die Projektdatei für MS Visual Studio 2010 C++ Express noch gefehlt, was hiermit aber nachgeholt ist. Der Tarball für die Linux-Nutzer kommt noch.

Wir müssten hier allerdings noch jemanden finden, der sich um die grafische Darstellung der Daten kümmert. Mir persönlich fehlen da die Möglichkeiten.
Gruß

EDIT: Hier noch der Link zum Linux-Code:

http://sourceforge.net/projects/originofmoon/
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied

Bernhard

Registriertes Mitglied
Was meinst du damit genau?
Hintergrund sind ziemlich unterschiedliche Informationen und Szenarien zur Entstehung des Mondes auf der akademischen Homepage von Jack Wisdom. Mir ist das beim Querlesen aufgefallen. Man sollte zukünftigen Lesern vorerst also keine Gewissheiten, sondern lediglich Modelle bzw. ein bestimmtes favorisiertes Modell vorstellen.
 

SRMeister

Registriertes Mitglied
Hallo Bernhard, ich versuche grad den SI zu verstehen.

Ist das hier korrekt?
Code:
void CNewton::EvaluateSI(double dt, int i)
{
	double invDistance3;
	int j, k;

	if( i == 1 )
	{
warum nicht if( i == 0 ) ?
 

Bernhard

Registriertes Mitglied
Hallo Bynaus und SRMeister,

da das angedachte "Projekt" mittlerweile etwas in's Stocken geraten ist, möchte ich aktuell mal die folgende Idee zur Verbesserung des C++-Codes einbringen. Die Grundidee der Veröffentlichung von Wisdom & Holman war ja gerade die, dass man die N-Körper-Hamiltonfunktion in einen großen und einen numerisch kleinen Teil zerlegt und getrennt weiterverwendet. Diese Idee würde ich gerne in den C++-Code einbauen. Konkret bedeutet das lediglich eine Zerlegung der einzelnen Planetenbewegungen (oder auch der Bewegung eines Testkörpers) in eine Keplerbahn mit Störung. Man müsste also für jeden Planeten das zugehörige Zweikörperproblem mit der Sonne lösen. Das sollte aufgrund der zugehörigen Mathematik eindeutig lösbar sein, denn man kennt ja zu einem bestimmten Zeitpunkt (z.B. t=t0) sowohl die Ortsvektoren der Sonne und des Planeten und auch beide Geschwindigkeiten. Die Frage wäre jetzt, wie man daraus möglichst elegant (also mit möglichst wenigen Rechenschritten) die Bahnparameter bestimmt, also numerische Exzentrizität, große Halbachse usw. Die Lage der Bahnebene ist trivial aus den beiden Ortsvektoren bestimmbar. Schwieriger wird es bei der Berechnung z.B. des aufsteigenden Knotens, also dem zugehörigen Bahnelement, das die Lage der Bahnebene im dreidimensionalen Raum festlegt.

Für Tips oder Literaturangaben zu dieser sehr speziellen Aufgabe wäre ich sehr dankbar und zwar auch von stillen Mitlesern, die sich auf diesem Gebiet gut auskennen. Als Dank winken Erweiterungen und Verbesserungen des hier vorgestellen und auch weiterhin öffentlich zugänglichen Open-Source-Projektes :) .
MfG
 

SRMeister

Registriertes Mitglied
Bernhard, das erscheint mir als der nächste richtige Schritt in die Richtung eines eigenen mixed-variable SI.
Leider fehlt mir die Mathematik für das Verstehen der Hamiltonfunktion.

Trotzdem möchte ich nochwas anmerken. Erstens: Zu Beginn der Simulation oder vor jedem Schritt müsste das Objekt selbstständig entscheiden, um welchen Körper es sich bewegt. (Anhand der Auswertung der "relativen Tiefe" innerhalb der Hillsphäre bezogen auf jeden anderen massiven Körper)So kann man auch den Mond um die Erde simulieren (auch wenn momentan nicht notwendig - aber mir kommen interessante Simulationen in den Sinn, die die Stabilität von Exomonden betrifft)
Zweitens: Man müsste für jeden Körper festlegen können, ob er komplett als Keplerproblem (2-Körper Problem) oder mit zusätzlicher Störung berechnet wird. So kann man ja den Merkur als reines Keplerproblem betrachten, denn durch fehlende relativistische Effekte ist die Genauigkeit hier sowieso nicht gegeben.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Trotzdem möchte ich nochwas anmerken. Erstens: Zu Beginn der Simulation oder vor jedem Schritt müsste das Objekt selbstständig entscheiden, um welchen Körper es sich bewegt. (Anhand der Auswertung der "relativen Tiefe" innerhalb der Hillsphäre bezogen auf jeden anderen massiven Körper)So kann man auch den Mond um die Erde simulieren (auch wenn momentan nicht notwendig - aber mir kommen interessante Simulationen in den Sinn, die die Stabilität von Exomonden betrifft)
@SRMeister. Das ist zuerst mal eine gute Idee, aber ich würde einen Teil dieser Informationen lieber in die Initialisierung stecken. Im Sonnensystem werden die Planeten in erster Linie von der Sonne auf ihren Bahnen gehalten. Ein Check für alle Planeten und bei jedem Zeitschritt macht das Programm deswegen unnötig langsam. Man sollte sich also schon vorher überlegen, was man simulieren will. Für Exoplaneten kann man eventuell einen Klon des Programmes erstellen, damit die Bedienung der einzelnen Simulationen nicht zu kompliziert wird. Ich will also die "Fehler" der Autoren des SCATR-Codes nicht wiederholen.

Zweitens: Man müsste für jeden Körper festlegen können, ob er komplett als Keplerproblem (2-Körper Problem) oder mit zusätzlicher Störung berechnet wird. So kann man ja den Merkur als reines Keplerproblem betrachten, denn durch fehlende relativistische Effekte ist die Genauigkeit hier sowieso nicht gegeben.
Auch diese Fallunterscheidung kann man sich sparen. Es gibt nämlich bei Merkur eine störungsbedingte Periheldrehung, die deutlich größer ist als der relativistische Effekt. Den störungsbedingten Anteil sollte man also auch bei Merkur tunlichst nicht vernachlässigen.
 

SRMeister

Registriertes Mitglied
Den störungsbedingten Anteil sollte man also auch bei Merkur tunlichst nicht vernachlässigen.
Es sollte darauf hinauslaufen, dass man die Schrittgröße höher ansetzen kann. Vor Allem wenn man einen Mond mit Störung simulieren möchte, würde die Schrittgröße recht klein werden.

Hast du eine Vermutung, warum der Integrator bei close encounters so langsam wird?
 

Bernhard

Registriertes Mitglied
Hast du eine Vermutung, warum der Integrator bei close encounters so langsam wird?
Bei Vorbeiflügen hat man stärkere Bahnkrümmungen als im Raum fern von gravitierenden Massen. Dies sollte ein guter Integrator in der Schrittweite berücksichtigen. Kleine Schrittweite bedeutet dann viel Rechenzeit und damit langsamer Programmablauf. Hast Du das mit dem SCATR-Code ausprobiert?
 

SRMeister

Registriertes Mitglied
Die Trümmerteile des hypothetischen Urmondes sind allerdings gemäß Vorgabe so schnell, dass man für eine aussagekräftige Analyse des Vorbeifluges von Trümmerteilen an Planeten ziemlich viel Rechenzeit benötigt (>>1 Stunde).
Ich weis nicht genau ob ich dich hier richtig verstanden habe. Benötigte jeder einzelne Vorbeiflug eine Std. oder die Simulation insgesamt?

Nein ich habe das mit dem SCATR nicht ausprobiert. Ich habe momentan noch einen anderen Integrator gefunden, Swifter, basierend auf SWIFT, worauf ja auch SCATR basiert. Das Programm ist nahezu identisch strukturiert wie SCATR, bietet aber noch ein paar andere Integratoren
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Die Frage wäre jetzt, wie man daraus möglichst elegant (also mit möglichst wenigen Rechenschritten) die Bahnparameter bestimmt, also numerische Exzentrizität, große Halbachse usw.
Ich habe mittlerweile in der Literatur zum Zweikörperproblem die dazu notwendigen Gleichungen gefunden. Ich hatte den Eindruck, dass auch im SCATR-Code so eine Rechnung gemacht wird und man könnte damit dann lediglich die gravitativen Störungen der Planeten untereinander numerisch berechnen. Die grobe Bahn als Keplerbahn ist im Gegensatz dazu weitgehend analytisch berechenbar. Ich habe momentan nur wirklich wenig Zeit das auch zu programmieren.
Gruß

EDIT: Die Fehlermeldung "Danby konvergiert nicht" könnte demnach bedeuten, dass an einer bestimmten Stelle die Keplerbahn nicht ausreichend genau berechnet werden kann. Bei der Keplerbahn wird zuletzt bekanntlich die wahre Anomalie des Planeten berechnet. Das geht nur numerisch und mit einer vorgegebenen Genauigkeit. Ich vermute deswegen, dass diese Genauigkeit über die DANBY-Parameter vorgegeben wird.
 
Zuletzt bearbeitet:
Oben