TheiaSim

[Bernhard]

Ich hab dir mal meine Kontaktdaten per PN geschrieben.

"Sie haben eine neue Nachricht" .

[Laudian]

So, ein erster Durchgang von 35 (massebehafteten?) Partikeln über 2 Millionen Jahren mit Schrittgrößen von 8 Tagen wurde gerade beendet, das hat ca. 2 1/2 Stunden gedauert. Also setze ich die rechenzeit noch auf 4 Mio Jahre hoch, und schon kann ich morgen beruhigt in die Uni gehen ;-)

[Bernhard]

So, ein erster Durchgang von 35 (massebehafteten?) Partikeln über 2 Millionen Jahren mit Schrittgrößen von 8 Tagen wurde gerade beendet

womit wir dann die ersten 4 Mio. Jahre berechnet hätten (2 Mio hatte ich bei mir laufen lassen) .

@Bynaus: bei der Rechnung von Laudian stürzt ein Trümmerteil aus dem 16er Paket (leichteste Trümmerteile) erneut auf die Erde! Ansonsten keine weiteren Kollisionen.

[Bernhard]

Also setze ich die rechenzeit noch auf 4 Mio Jahre hoch, und schon kann ich morgen beruhigt in die Uni gehen ;-)

Absolut korrekt. Dein Rechner ist offensichtlich etwas schneller als meiner. Hinzu kommt noch, dass der Programmablauf mit jedem Absturz eines Trümmerteils (merging particles) immer schneller wird.

[Bynaus]

Spannende Sache - Danke Laudian für deine Hilfestellung! Die Information, wie lange es dauert, bis alle Trümmerteile kollidiert oder aus dem System geworfen sind, wird wichtig sein, wenn wir eine systematische Parametersuche beginnen wollen.

[Bernhard]

Die Information, wie lange es dauert, bis alle Trümmerteile kollidiert oder aus dem System geworfen sind, wird wichtig sein, wenn wir eine systematische Parametersuche beginnen wollen.

Hi Bynaus,

ich habe bei Laudian gerade angefragt, ob er nicht eventuell noch drei weitere Startbedingungen übernehmen möchte. Sein Rechner würde das von der Rechenleistung her nämlich ganz gut parallel rechnen können. Da der Streuwinkel für eine Startbedingung 5° beträgt, wäre für die systematische Suche ein Rechner mit 72 Kernen ideal. Dann könnte jeder Kern genau eine Startbedingung rechnen und wir hätten alle 360° abgedeckt. Die Auswertung aller Ausgaben ist nicht sonderlich kompliziert. Es fehlt momentan nur an der Rechenleistung. Theoretische wäre dieses Projekt sogar für BOINC geeignet, weil es sich so leicht in kleinere Pakete zerlegen läßt.

[Bernhard]

Hallo Bynaus und Laudian,

es gibt inzwischen ein neues Detail bei den Simulationen. Laudian wollte mehrere Startbedingungen parallel rechnen. Ich habe deswegen einfach den Startwinkel für die Trümmer jeweils um 5° erhöht und die zugehörige Startdatei berechnen lassen. So weit hatte ich es weiter oben ja schon grob beschrieben. Neu ist, dass bei zwei von vier Startbedingungen die Rechenzeit um einen Faktor 10 größer ist, als bei den anderen.

Da das swifter-Programm einige Analyseprogramme mit liefert habe ich das Tool für die close encounters mal angesehen. Dieses Tool zeigt, dass bei den rechenintensiven Startbedingungen leichte Trümmerteile vermutlich umeinander kreisen und dabei permanent close encounters produzieren. Der Effekt ist (vermutlich) sogar unabhängig von der zufälligen Verteilungung der Trümmerteile innerhalb der 5°. Ich habe dazu zwei Startdateien getestet, die den gleichen 5°-Kegel verwenden. Das Problem ist also nicht trivial zu umgehen.

Was meinst Du Bynaus? Sollen wir diese Winkel bei der systematischen Analyse einfach weglassen?

[Laudian]

Wobei der Faktor 10 bei mir eher einen Faktor 100 ergibt ;-)
Während die "einfachen" Startbedingungen ca. 5 Stunden für 4 Millionen Jahre benötigen, kommt die "schwere" Startbedingung nach derselben Zeit erst auf ca. 1% Fortschritt.
Ich lasse diese Startbedingung jetzt noch den Abend laufen, vielleicht haben wir ja Glück und ein paar der close encounter stürzen noch ab. Da mein PC aber recht laut ist werde ich ihn spätestens gegen 24 Uhr ausschalten, sonst wars das mit meinem Schlaf ;-)

[Bynaus]

Dieses Tool zeigt, dass bei den rechenintensiven Startbedingungen leichte Trümmerteile vermutlich umeinander kreisen und dabei permanent close encounters produzieren. Der Effekt ist (vermutlich) sogar unabhängig von der zufälligen Verteilungung der Trümmerteile innerhalb der 5°. Ich habe dazu zwei Startdateien getestet, die den gleichen 5°-Kegel verwenden. Das Problem ist also nicht trivial zu umgehen.

Okay. Dass Trümmerteile sich umkreisen, scheint eine typische Folge einer solchen Kollision zu sein - nicht nur aufgrund eurer Simulationsrechnungen, sondern aufgrund der ursprünglichen Kollisionsrechnungen: schon dort zeigte sich dieses Phänomen.

Was man machen könnte, ist, zunächst zu prüfen, welche Trümmerteile sich gegenseitig umkreisen werden (z.B. via Hill-Sphären). Dann legt man diese einfach zu einem gemeinsamen Trümmerteil (mit der kombinierten Masse) zusammen.

Oder aber, wir reduzieren einfach die Anzahl Trümmer, etwa in dem wir die 16er-Gruppe weglassen.

[Bernhard]

Was man machen könnte, ist, zunächst zu prüfen, welche Trümmerteile sich gegenseitig umkreisen werden (z.B. via Hill-Sphären). Dann legt man diese einfach zu einem gemeinsamen Trümmerteil (mit der kombinierten Masse) zusammen.

Etwas in dieser Art macht swifter bereits, allerdings erst bei kleineren Radien als dem Hill-Radius. Beim Zusammenpacken ("Mergen") werden dann automatisch die neue Masse und der neue Radius ausgerechnet. Man müsste dann im Quelltext die zugehörigen Stellen finden und umprogrammieren, bzw. erweitern. Auf die Schnelle bekomme ich das aber nicht hin, weil ich von dem Quelltext bisher nur die Grundlagen kenne.

Oder aber, wir reduzieren einfach die Anzahl Trümmer, etwa in dem wir die 16er-Gruppe weglassen.

Gute Idee. Ich werde dann mal austesten, wieviel Rechenzeit das einspart.

EDIT: Ohne die 16er Gruppe läuft das Programm wieder mit der "normalen" Geschwindigkeit, d.h. so wie bei den Startbedingungen, die gerade von Laudian bearbeitet werden.