TheiaSim

Bernhard

Registriertes Mitglied
Hallo Bynaus,

die zweite Millionen Jahre sind jetzt fertig. Nach 1.13 Mio. Jahren kollidiert noch ein Fragment aus der 16er Gruppe mit der Venus, weiter nichts.

Ich möchte meinem Rechner jetzt erst mal eine Ruhepause gönnen. Das Hit-and-Run-Szenario ist als Möglichkeit ansatzweise bestätigt, in Form eines Treffers auf der Erde.

Für die volle Simulation über 100 Mio. Jahre wäre es schön, wenn sich noch andere Freiwillige beteiligen könnten. Quelltext und Parameter stelle ich jederzeit gerne zur Verfügung. Man könnte dazu auch auf http://www.astrotreff.de nach Freiwilligen suchen. Dort gibt es eine ganze Menge Linux-User.
MfG
 

Bynaus

Registriertes Mitglied
Sehr schön! Und ja klar, das muss ja alles nicht sofort und gleich geschehen. Wenn ich wieder in Lund bin (zurzeit bin ich in der Schweiz) kann ich mal abklären, ob die dort ein Rechenzentrum haben, das ich kostenlos nutzen könnte.

Das Hit-and-Run-Szenario ist als Möglichkeit ansatzweise bestätigt, in Form eines Treffers auf der Erde.

Das ist schön, auch wenn es nur ein Ansatz ist. Wir wissen ja nicht, wie häufig das langfristig gesehen ist...
 

Bernhard

Registriertes Mitglied
Wenn ich wieder in Lund bin (zurzeit bin ich in der Schweiz) kann ich mal abklären, ob die dort ein Rechenzentrum haben, das ich kostenlos nutzen könnte.
Das wäre interessanter und sicherer, als eine Verteilung an Freiwillige. Da die Ausgaben zur Zeit einfache Textdateien sind, könnten diese mit einem Editor theoretisch ziemlich leicht sabotiert werden. Bei einem Rechenzentrum würde diese "Fehlerquelle" automatisch wegfallen.
 

Bynaus

Registriertes Mitglied
Ich bin recht gespannt, was rauskommt, wenn wir die Simulation weiterlaufen lassen. So gespannt, dass ich mittlerweile ernsthaft über die Installation des Dualboots nachdenke... :)
 

Bernhard

Registriertes Mitglied
So gespannt, dass ich mittlerweile ernsthaft über die Installation des Dualboots nachdenke... :)
Hi hi! Wenn Du einen DVD-Rohling übrig und einen DVD-Brenner hast, lade schon mal die iso-Datei von hier: http://software.opensuse.org/121/de . Natürlich die 64-Bit Version. Um den Support für die Installation so einfach wie möglich zu halten, empfehle ich die Version 12.1, weil ich die auch verwende. Du kannst später wenn alles läuft dann auf die 12.2 bei Bedarf updaten.

Die iso-Datei einfach als iso-Image (nicht als Datei) auf die DVD brennen und fertig ist die bootfähige Installations-CD.
 

Laudian

Registriertes Mitglied
Moin moin.
Ich les hier schon seit einiger Zeit mit, und finde euer Projekt extrem interessant.
Wenn ihr interessiert seid, könnte ich euch mit ca. 40 Stunden Rechenzeit pro Woche unter die Arme greifen, mein pc läuft eh den ganzen Tag, und wenn ich in der Uni bin könnte er ja wunderbar für euer Projekt arbeiten ;-)
 

Bernhard

Registriertes Mitglied
könnte ich euch mit ca. 40 Stunden Rechenzeit pro Woche unter die Arme greifen
Hallo Laudian,

das klingt für mich sehr interessant. Verwendest Du an Deinem Arbeitsplatz Linux? Wenn ja, welche Distribution? Ich weiß nämlich nicht genau, inwieweit die Binärdateien zwischen den verschiedenen Linux-Distributionen ausgetauscht werden können. Prinzipiell könnte ich ein Paket vorbereiten, das beispielsweise etwa 7 h lang läuft. Mit jedem weiteren Trümmerteil, das per Kollision oder Merging (verbinden zweier Trümmer) verschwindet, wird der Programmablauf dann auch immer schneller. Aktuell stehen wir bei 34 Planeten (inklusive massive Trümmer). Das Programm wird in einer Konsole gestartet. Die Ausgaben auf der Kommandozeile sollten nach dem Programmablauf per Screenshot dokumentiert werden. Wenn man mit Linux ein wenig Erfahrung hat, sind das im Prinzip alles Standardaufgaben.

Willkommen im Forum!
 
Zuletzt bearbeitet:

Laudian

Registriertes Mitglied
Zur Zeit habe ich kein Linux, beginne aber gerade mit dem Download von SUSE.
Bisher habe ich Linux / Windows immer von Grub gestartet, aber wenn ich SUSE auf einer eigenen Festplatte installiere kann ich mir das auch eigentlich sparen, und direkt im BIOS auswählen welche Festplatte gebootet werden soll, richtig ?
Mit Kommandozeilen komme ich zurecht, und Screenshots werde ich auch schon hinbekommen ;-)
 

Bernhard

Registriertes Mitglied
aber wenn ich SUSE auf einer eigenen Festplatte installiere kann ich mir das auch eigentlich sparen, und direkt im BIOS auswählen welche Festplatte gebootet werden soll, richtig ?
Oops. Das habe ich noch nicht ausprobiert. Da würde ich aber auch eher zu GRUB raten. Die Einstellerei im BIOS ist doch eher unpraktisch. Da ist das Bootmenü vom GRUB deutlich komfortabler und netter. Ich würde auch bei zwei getrennten Festplatten also mit der Installations-CD starten und beim Partitionieren dann angeben, dass Linux auf der zweiten Festplatte laufen soll. Das sollte dann ebenfalls ein Dualboot-System ergeben.

Mit Kommandozeilen komme ich zurecht, und Screenshots werde ich auch schon hinbekommen ;-)
Sehr gut. Installiere wie im Default vorgegeben, KDE und verwende Gimp für die Screenshots, dann hast Du ein System so komfortabel wie Windows.
MfG
 

Laudian

Registriertes Mitglied
Ich habe jetzt auf jeden Fall ein laufendes Suse 12.2 64 Bit auf dem Rechner, allerdings mit Gnome, das stört hoffentlich nicht.

Morgen sind die Ferien vorbei, wenn der Rechner da schon für euch laufen soll müsstest du mir das Programm also heute noch schicken.
Ich hab dir mal meine Kontaktdaten per PN geschrieben.
 

Laudian

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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

Registriertes Mitglied
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.
 
Zuletzt bearbeitet:
Oben