PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : TheiaSim



Seiten : 1 [2]

SRMeister
17.10.2012, 15:14
Bernhard, das braucht dir nicht leid tuen. Ich sehe das momentan genauso. Wir haben zwar viel Arbeit reingesteckt, aber wenn es nicht zielführend ist, sucht man sich eben eine Alternative.
Möglicherweise könnte man den SCATR anpassen. Ich bin mir aber auch nicht sicher ob ich so tief in den Code einsteigen kann, wie benötigt wäre. Das ist sehr fraglich.

Deine Lösung eines eigenen Simulators ist natürlich erstmal gut.
Allerdings stellt sich dann die Frage, ob man Ergebnisse davon in einer wissenschaftlichen Arbeit "verkaufen" kann. MMn. wäre dann auch eine genaue Analyse der Software nötig, was eine 2. wissenschaftliche Arbeit (oder mehr) bedeuten könnte. Dazu müsste man verschiedene Ergebnisse aus anderen Arbeiten reproduzieren um einen Beweis der Gültigkeit zu erbringen. Selbst wenn man alles in eine Arbeit steckt, also die Rechtfertigung der Software und die Ergebnisse bezüglich Theia, so müsste die Arbeit doch von Bynaus u. Kollegen verfasst werden, die dazu die Software selbst bis ins Detail verstehen und vertreten müssen.
Nichtsdestotrotz ist ein eigenes Projekt für uns ein riesen Gewinn.

Möglicherweise gibt es dokumentierte und peer-reviewed Alternativen. Ich schaue mich nochmal um.

Bernhard
17.10.2012, 15:39
Möglicherweise könnte man den SCATR anpassen.
Genau da habe ich so meine Zweifel. Die Tests mit dem Mond zeigen meiner Meinung nach recht gut, dass wir bei engen Vorbeiflügen von Trümmerteilen an Planeten auch nach kleineren Anpassungen kaum brauchbare Aussagen aus dem SCATR-Code ableiten können. Wir haben hier vielmehr eine ganz eigene Problematik, die auch nicht alleine mit der Hillsphäre ausreichend genau beschrieben werden kann. Bei dem Nachbarprojekt "Entstehung des Mondes" habe ich versucht brauchbare Mechanismen zu programmieren, aber diese Versuche sind allesamt sehr sehr rechenintensiv, was zusätzlich bedeutet, dass man das besser den Profis überlassen sollte.

pmvstrm
18.10.2012, 08:24
Hallo,
Ich habe jetzt nicht alles gelesen aber falls Ihr noch auf der Suche nach einem Fortran Compiler seid, die GNU Compiler Collection (GCC) bietet einen
Fortran 95 fähigen Compiler (o 2k Standard schon unterstützt wird kann ich nicht sagen) an (gfortan).Es gibt ein Win32/Win64 Portierungs Projekt genannt MinGW-w64 welches ich im praktischen Einsatz habe (meist nutze ich nur den C/C++ Compiler um Unter Windows trotzdem Posix compliant programmieren zu können.Ein kurzes Hello Fortran programm konnte ich damit erstellen und laufen lassen. Für Parallisierung kann man das mitgelieferte OpenMP oder aber die OpenSource Version von Intels Thread Building Blocks nutzen (finde ich persönlich besser). Als Graphic Library habe ich FreeGLUT (OpenGL) im Einsatz.

Die Compiler Collection (einfach entpacken wars) hat neben Fortran auch noch C, C++, ADA, Gnu Pascal sowie ObjectiveC und Java mit dabei)
Es wird GNU Make als Make Utility mitgeliefert so das man auch Projekte und Prjektmappen anhand eines Makefiles erstellen kann (im Prinzip so wie QMake
unter QTCreator)http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/ ("")

Der Compiler auf den SF Mirrors ist ready to use, entspricht aber nicht den aktuellen Stand. Wer die allerneueste GCC Compiler Collection
für Mingw64 nutzen möchte, kann ihn aus dem Projekt SVN Repo auschecken und selbst kompilieren (Vorsicht, dauert Stunden, ich nutze
selbst auch nur die vorkompilierten).

Intel Thread Building Blocks OpenSource (habe ich im Einsatz und kann mit dem zugehörigen C++ Compiler kompiliert werden) (ca 5 Min kompilierzeit)
http://threadingbuildingblocks.org/

FreeGLUT OpenGL Hilfsbibliothek (die 32/64-Bit DLL muss man sich kurz kompilieren, dauert ca eine Min, static variante nutze ich nicht)
http://freeglut.sourceforge.net/

Kann man alles frei verwenden, es fallen keine Kosten oder Nutzungsbeschränkungen an.
Ich habe zwar noch nicht viel mit Fortran gemacht, aber im Rahmen der GCC nutzen alle Compiler das gleiche Objectcode format und den
selben Linker. Man kann also jedes *.obj File, ob nun mit dem GCC C/C++/Pascal oder ADA oder Fortran Compiler erstellt) im Endeffekt
in einer Exe zusammenbinden. So können z.B Programmierer die alle die GCC nutzen aber mit unterschiedlichen Programmierspachen arbeiten
wollen zusammen arbeiten und das Ergebnis am Ende zusammen linken, auf DLL's verteilen u.s.w. Natürlich muss man den Kompilierprozess
nicht nur auf Windows beschränken. Der selbe Code lässt sich auf auf Linux/Mac/Unix ohne modifikationen übersetzen.

Ach ja, unter Windows versteht Notepad++ (free) Fortan Syntax Highlighting.
http://notepad-plus-plus.org/ es gibt natürlich auch VI für Windows
http://www.vim.org/ oder GNU EMacs http://www.gnu.org/software/software.html für Windows nutzen
die so ziemlich jede Sorte Sprache unterstützen die es auf dem Planeten gibt.

Bernhard
18.10.2012, 08:53
Ein kurzes Hello Fortran programm konnte ich damit erstellen und laufen lassen.
Das SCATR-Projekt ist da doch "ein wenig" komplexer, aber sei's rum. Ich habe, wie gesagt, mittlerweile auch mal Eclipse ausprobiert. Das hat eigentlich einen recht guten Ruf und wird angeblich auch im gewerblichen Einsatz betrieben. Es konnte das SCATR-Projekt aber nicht übersetzen. Eclipse nutzt dabei den GNU Fortran-Compiler.

pmvstrm
18.10.2012, 11:22
Eclipse ist nur ein Editor + Debugger Intergration. Die eigentliche Arbeit wird von den GNU Tools im Hintergrund geleister. Du benötigst Eclipse nicht um
den Fortran Code zu übersetzen. Eclipse verwendet auch ein völlig anderes Buildystem als GNU Make (Apache ANT) das mit anderen Eingabedateien
arbeitet. Du hast weiter oben erwähnt das Du es unter SuSE Linux übersetzt bekommen hast ./configure ./make . make install ? Wenn ja ist es GNU
Make und läuft definitiv ohne Eclipse. Die Frage nach dem Codeeditor ist da eher Geschmacksfrage. Für Java, Android und Java Enterprise Sachenist
Eclipse gut, ansonsten meide ich es wie der Teufel das Weihwasser (zu überladen,, zu träge, viele Sachen fehlen ect). Aber wie gesagt,ist Geschmackssache.

Bernhard
18.10.2012, 11:56
Wenn ja ist es GNU
Hallo pmvstrm,

in diesem speziellen Fall, war es der Intel Fortran Compiler. Das Projekt enthält beigefügte Make-Dateien, in denen auch eingetragen werden muss welchen Compiler man verwenden will (Intel, GNU, o.ä.). Ohne Debugger kommt man bei diesem Projekt definitiv nicht weiter. Man hat dort eigentlich nur Berechnungen mit sehr vielen Variablen, Vektoren und Matrizen.

Wir haben weiter oben zudem gerade besprochen, dass der SCATR-Code für unsere Zwecke vermutlich gar nicht geeignet ist.
Gruß

FrankSpecht
18.10.2012, 13:44
Hallo, ihr fleißigen Programmierer!
Habt ihr schon von den neuen Simulationen von der Harvard University gelesen: Erdmond - Neue Impaktsimulationen (http://www.spektrum.de/alias/erdmond/neue-impaktsimulationen-loesen-entstehungsraetsel/1168053)

Da sind ein paar interessante Details enthalten, die die Rotationsgeschwindigkeit der beteiligten Körper berücksichtigen, um auf das identische Isotopenverhältnis des Mondmaterials mit der Erdkruste zu kommen.

SRMeister
18.10.2012, 14:12
Also wie ich sehe endet die Simulation mit einer Scheibe, aus der sich einmal der Mond bildet.
Kann man nicht also bei unserem Problem den Mond weglassen?

Bernhard
18.10.2012, 14:28
Kann man nicht also bei unserem Problem den Mond weglassen?
Das hat Bynaus weiter oben bereits bestätigt. Der Mond war, wie gesagt, nur als Test für den SCATR-Code gedacht. Für das eigentlich Thema (Wie entstand der Mond), bzw. die Vorgaben von Bynaus (Wie verteilen sich die Trümmer über das Sonnensystem) brauchen wir den Mond nicht.

pmvstrm
18.10.2012, 22:18
Hallo pmvstrm,
Ohne Debugger kommt man bei diesem Projekt definitiv nicht weiter.
Der Debugger ist immer dabei (GNU Debugger "gdb.exe").Eclipse ruft den Debugger (wie die meisten anderen IDE's und Editoren) im
Hintergrund lediglich GDB auf und präsentiert dann die Ausgabe des Debuggers etwas hübscher, das ist bei MS-Visual Studio auch nicht anders.
Wenn Du z.B mit QTCreator oder Eclipse den MS-Visual C/C++ Compiler nutzen und auch debuggen möchtest, dann braucht man noch die Windows Debuggingtools, die dem frei downloadbaren Windows Platform SDK ISO (http://www.microsoft.com/en-us/download/details.aspx?id=18950) von Microsoft beiliegen.Für Visual C++ 2010 Express Anwender ist das Platform SDK auch ansonsten eine große Hilfe, da hier oft benötigte Includes und die zugehörigen Libs zu finden sind, die ansonsten nur in den großen und teuren Visual Studio Versionen direkt eingebunden sind.Es beinhaltet für Visual Studio Express Anwender auch den fehlenden 64-Bit Compiler so das man aus Visual C++ Express heraus auch 64-Bit Windows Programme erstellen kann, dazu muss man Visual C++ Express lediglich nach der Installation des Windows Platform SDK das Toolset in den Projektoptionen auf Windows 7.1 SDK umstellen, dann nutzt Express die Platform SDK 32 und 64 Kompiler im Hintergrund.

Installer für die MS Windows Debuggingtools:
D:\Setup\WinSDKDebuggingTools\dbg_x86.msi (32-Bit).
D:\Setup\WinSDKDebuggingTools_amd64\dbg_amd64.msi (64-Bit).

Falls Du ein 64 Bit Windows verwendest solltest Du am besten beide Pakete installieren.Es werden 4 Debugger installiert davon sind aber nur diese beiden wichtig CDB.EXE (Usermode Console Debugger), WinDBG.EXE (GUI User/Kernelmode Debugger für Treiberentwicklung und LowLevel)
In Visual C++ Express ändert sich durch die Installation der Debuggingtools übrigens nichts, sie sind lediglich für nicht Visual Studio IDE's wichtig.
CDB.EXE wird z.B von Eclipse benötigt damit man den MS-Compiler Objectcode debuggen kann dies gilt natürlich auch z.B für QTCreator oder jede andere Programmersworkbench die den MS Compiler CL.EXE ansteuert, es sei denn man arbeitet sowieso mit Visual Studio.


Wir haben weiter oben zudem gerade besprochen, dass der SCATR-Code für unsere Zwecke vermutlich gar nicht geeignet ist.
Gruß

Dann ist es eh egal.

Bynaus
23.10.2012, 09:52
Ich war eine Zeit lang weg, und werd mich morgen hier für ein längeres Feedback zu den letzten Entwicklungen melden.

Bynaus
23.10.2012, 21:08
Okay, hier mal ein Update aus meiner Sicht seit meiner letzten Wortmeldung hier.

Ich verstehe allerdings immer noch nicht ganz, was genau das Problem mit SCATR ist? Mal abgesehen davon, dass es in Fortran geschrieben ist. Ist es die schlechte Dokumentation? Die Sache mit Mond/Merkur? Letzteres liesse sich, wie SRMeister schon gesagt hat, dadurch lösen, dass man den Mond weglässt (spielt hier eh keine grosse Rolle) und den Merkur durch eine Keplerbahn abschätzt. Eventuell könnte man das sogar für alle (massereichen) Planeten machen.


Die Hill-Sphäre ist bei masselosen Testkörpern gleich Null und damit eigentlich ungeeignet. Wichtiger erscheint mir vielmehr eine Berücksichtigung der Geschwindigkeit des Testkörpers zu sein, um lineare Extrapolationen bei der Bahn machen zu können.

Gemeint war hier natürlich die Hill-Sphäre der Planeten, nicht der Teilchen.

Ich stell mir das so vor:
- 8 massive Planeten (auf Keplerbahnen?), evtl. ein paar grosse Asteroiden im Gürtel (masselos, nur als "Zielkörper")
- X Teilchen mit bestimmten Ausgangspositionen, -koordinaten und -geschwindigkeitsvektoren ("Werte"). Diese Teilchen werden als masselos angenommen, sie interagieren also nicht miteinander, aber ihre Bahnen werden durch Planeten gravitativ beeinflusst.
- Sobald ein masseloses Teilchen sich einem Planeten (oder grossen Asteroiden) auf mehr als eine Hill-Sphäre nähert, werden seine Werte in ein lokales Koordinatensystem transformiert und mit sehr viel kürzerer Schrittweite gerechnet. Verfehlt es den Planeten, werden die Werte beim erneuten Erreichen des Hill-Radius an die ursprüngliche Simulation übergeben. Trifft es den Planeten (dh, es nähert sich auf weniger als einen bestimmten, kritischen Radius, der für jeden Planeten festgelegt werden kann), werden Trefferposition, Zeitpunkt sowie Bahnwerte zum Zeitpunkt der Kollision gespeichert und das Teilchen aus der Simulation entfernt.
- Sobald ein masseloses Teilchen sich der Sonne zu stark nähert, eine grosse Halbachse über einem bestimmten Wert erreicht oder das System ganz verlässt (Fluchtgeschwindigkeit rel. zur Sonne), wird es aus der Simulation entfernt.

Ich hab keine Ahnung, ob dafür SCATR wirklich nötig ist, oder ob ein anderer (etablierter) Integrator (z.B. Mercury?) es genauso tun würde.

SRMeister
23.10.2012, 21:41
Hallo Bynaus und Bernhard,

Ich verstehe allerdings immer noch nicht ganz, was genau das Problem mit SCATR ist? Mal abgesehen davon, dass es in Fortran geschrieben ist. Ist es die schlechte Dokumentation? Die Sache mit Mond/Merkur?
Also die Sache mit dem Mond erübrigt sich ja, aber wenn der Integrator kollisionen nicht richtig erkennen kann, obwohl dass so dokumentiert ist, haben wir natürlich ein Problem. Das ist Bernhard sein Befund, ich habe dazu noch keine Untersuchung vorgenommen. Ich denke es ist auch relativ schwer, einen Testfall zu konstruieren.
Warten wir mal Bernhard seine genaue Diagnose ab.


Letzteres liesse sich, wie SRMeister schon gesagt hat, dadurch lösen, dass man den Mond weglässt (spielt hier eh keine grosse Rolle) und den Merkur durch eine Keplerbahn abschätzt. Eventuell könnte man das sogar für alle (massereichen) Planeten machen.
Ich denke mittlerweile, es wird uns kaum möglich sein, einen anderen bekannten Integrator soweit zu modifizieren. Das würde nur mit einem Eigenen klappen.

Nun zu den Punkten:



- 8 massive Planeten (auf Keplerbahnen?), evtl. ein paar grosse Asteroiden im Gürtel (masselos, nur als "Zielkörper")
Da es leider nur 2 Kategorien von Körpern gibt (masselos, massiv), kann man masselose Objekte nicht mit anderen masselosen kollidieren lassen. Eine Anpassung des Integrators scheint auch hier kaum möglich. Das stellt aber kein großes Problem dar, man kann auch ein paar massebehaftete Objekte in den Asteroidengürtel setzen.


- X Teilchen mit bestimmten Ausgangspositionen, -koordinaten und -geschwindigkeitsvektoren ("Werte"). Diese Teilchen werden als masselos angenommen, sie interagieren also nicht miteinander, aber ihre Bahnen werden durch Planeten gravitativ beeinflusst.
Okay, dies sind dann die "Theiatrümmer". Bernhard sein Algorithmus erzeugt die ja bereits erfolgreich.


- Sobald ein masseloses Teilchen sich einem Planeten (oder grossen Asteroiden) auf mehr als eine Hill-Sphäre nähert, werden seine Werte in ein lokales Koordinatensystem transformiert und mit sehr viel kürzerer Schrittweite gerechnet. Verfehlt es den Planeten, werden die Werte beim erneuten Erreichen des Hill-Radius an die ursprüngliche Simulation übergeben. Trifft es den Planeten (dh, es nähert sich auf weniger als einen bestimmten, kritischen Radius, der für jeden Planeten festgelegt werden kann), werden Trefferposition, Zeitpunkt sowie Bahnwerte zum Zeitpunkt der Kollision gespeichert und das Teilchen aus der Simulation entfernt.
Okay, im Prinzip funktioniert SCATR genau so wie du es beschreibst. Es sollte also bereits jetzt prinzipiell in etwa so laufen. An diesem Punkt hat Bernhard bedenken. Ich kann dazu wie gesagt noch keine Aussage treffen.


- Sobald ein masseloses Teilchen sich der Sonne zu stark nähert, eine grosse Halbachse über einem bestimmten Wert erreicht oder das System ganz verlässt (Fluchtgeschwindigkeit rel. zur Sonne), wird es aus der Simulation entfernt.
Okay, genau so funktioniert SCATR, wobei man für die einzelnen Kriterien grenzwerte vorgeben kann.


Ich hab keine Ahnung, ob dafür SCATR wirklich nötig ist, oder ob ein anderer (etablierter) Integrator (z.B. Mercury?) es genauso tun würde
Im Prinzip ist SCATR eine Erweiterung von SWIFT. SWIFT ist mMn ein sehr verbreiteter Integrator. SCATR ermöglicht, das äußere Sonnensystem in größeren Zeitschritten als das Innere zu berechnen, was man braucht um große Mengen von Objekten in der Oortcloud zu simulieren. Insofern hast du recht, SCATR ist nicht wirklich nötig.
Nach erneutem recherchieren bin ich auf einen anderen, modernen "Zweig" von SWIFT gekommen, der sich Swifter nennt und mit "SyMBA" einen sehr guten, allgemein benutzbaren Integrator bietet, der außerdem codetechnisch mit SCATR nah verwand ist(wir sind also eingearbeitet) da beide auf SWIFT basieren. Außerdem wurde dieser Integrator in der Literatur öfter erwähnt als SWIFT oder SCATR. Der Code zu SyMBA basiert auf dieser (http://journalogy.net/Publication/43094612/a-multiple-time-step-symplectic-algorithm-for-integrating-close-encounters)Arbeit die 79 mal zitiert wurde.(Hier (http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1998AJ....116.2067D&db_key=AST&data_type=HTML&format=&high=4318a59cdd13448) zum PDF)

Meiner Einschätzung nach sollte man dem vielleicht eine Chance geben. Der bietet bis auf die Sache mit der Oortcloud das selbe wie SCATR, ist aber wohl um einiges genauer. Das hilft vllt. bei der Sache mit der Kollisionserkennung:


We present a new symplectic algorithm that has the desirable properties of the sophisticated but highly efficient numerical algorithms known as mixed variable symplectic (MVS) methods and that, in addition, can handle close encounters between objects. This technique is based on a variant of the standard MVS methods, but it handles close encounters by employing a multiple time step technique. When the bodies are well separated, the algorithm has the speed of MVS methods, and whenever two bodies suffer a mutual encounter, the time step for the relevant bodies is recursively subdivided to whatever level is required. We demonstrate the power of this method using several tests of the technique. We believe that this algorithm will be a valuable tool for the study of planetesimal dynamics and planet formation.
Außerdem ist es auch open source.

Bynaus
24.10.2012, 15:33
Das sind erfreuliche Neuigkeiten, SRMeister. SyMBA ist mir auf jeden Fall sehr sympathisch! :) Offenbar kann man sowohl massive als auch masselose Partikel simulieren.

Bernhard
24.10.2012, 16:33
Das Erstpaper zu Symba ist frei zugänglich: http://iopscience.iop.org/1538-3881/116/4/2067

Oops. Sehe gerade dass SRMeister einen Link bereits angegeben hat. Das Paper gefällt mir ebenfalls recht gut und es finden sich darin auch die Ansätze, die ich bereits in unserem BSSI-Code verwendet habe. Falls der Code beschafft werden kann, wäre ich daran interessiert.

SRMeister
24.10.2012, 17:46
Der Code ist hier (http://www.boulder.swri.edu/swifter/) erhältlich. Außerdem gibt es da wohl ein auf Java basierendes Tool zur Visualisierung. Scheint recht umfassend zu sein.
Ich habe zwar noch keine Anstrengungen zur Compilierung unternommen, sollte aber ähnlich wie bei SCATR laufen.

Bernhard
25.10.2012, 23:34
Hallo SRMeister,

ich habe SyMBA versuchsweise als Visual Studio Solution eingerichtet. Leider gibt es da etliche Probleme mit der Programmstruktur, die ich nicht auf die Schnelle beheben kann. Ohne die beiden Ordner fxdr und/oder fxdr_2.1c fehlt in den io-Dateien die Header-Datei fxdr.inc und ich habe keine Ahnung wie man in Fortran-Dateien Header-Dateien so includiert dass man keine Positionierungsfehler bekommt. Mit den beiden Ordnern kommt es zu sehr vielen Fehlermeldungen und noch mehr Warnings. Schaue Dir das bitte auch mal an. Vielleicht kommst Du ja besser mit dem Code zurecht.

ralfkannenberg
29.10.2012, 08:04
Das sind erfreuliche Neuigkeiten, SRMeister. SyMBA ist mir auf jeden Fall sehr sympathisch! :) Offenbar kann man sowohl massive als auch masselose Partikel simulieren.
Hallo Bynaus,

jetzt bist Du auch in der Sonntags-Zeitung erwähnt. Ob man dazu gratulieren soll ist allerdings eine andere Frage ...


Freundliche Grüsse, Ralf

Bernhard
29.10.2012, 11:41
jetzt bist Du auch in der Sonntags-Zeitung erwähnt.
Hallo Ralf,

wird dort auch das Astronews-Forum erwähnt oder sogar dieses Thema hier? Ich bin momentan etwas ratlos bezüglich Deines Beitrages.
Gruß

Bernhard
30.10.2012, 09:03
Ich bin momentan etwas ratlos bezüglich Deines Beitrages.
Hallo Ralf,

vielen Dank für die PN. Dein Postfach ist zur Zeit übrigens so voll, dass man Dir gar nicht mehr antworten kann. Nur zur Info.
Gruß

Bynaus
30.10.2012, 12:03
Ja, es geht im Moment vieles bezüglich des Mondes, und Journalisten fragen öfter mal an (insb. bei meinem Doktorvater in Zürich), wie man denn das alles deuten müsse. Ich hab auch einen längeren populärwissenschaftlichen Artikel geschrieben, der nächstes Jahr publiziert werden wird. Aber mit dem Forum hier und dem TheiaSim-Projekt hat das alles nichts zu tun. :)

SRMeister
30.10.2012, 12:53
und wann erhellt man uns? :)
PS: ich scheitere auch momentan noch an der libfxdr. Für Linux/gcc liegt sie ja vorkompiliert bei

Bernhard
30.10.2012, 16:20
und wann erhellt man uns? :)
Ich habe mich gerade zu den Jacobi-Koordinaten vorgearbeitet (s. Wisdom/Holman). Ziemlich trockene Materie aber auch interessant.

Bernhard
09.11.2012, 15:23
leer ........

Bernhard
10.11.2012, 18:45
Hallo Bynaus und SRMeister,

ich habe aktuell einige Ideen zu den "close encounters" und wie man das eventuell in den SCATR-Code einbauen könnte. Mir schwebt dazu eine bestimmte "Gruppierung" der Hamilton-Funktion aus Punkt 3 der zentralen Veröffentlichung von J. Wisdom und M. Holman (1991) =[WH91] vor.

Als erste wichtige Übungsaufgabe möchte ich dazu das System Erde-Mond durch deren Schwerpunktskoordinate und den Relativabstand ersetzen. Damit sollte dieses Subsystem als separates Zwei-Körper-Problem in der Hamilton-Funktion erscheinen. Anschließend kann man dann das verbleibende (n-1)-Körper-Problem gemäß [WH91] lösen. Man kann dann testen, wie gut man das Sonnensystem selbst (inklusive Erde-Mond-System) simulieren kann. Sollte das gut funktionieren, kann man dieses erweiterte Prinzip auf den SCATR-Code anwenden, um massive Testkörper berücksichtigen zu können. Je nachdem, ob sich ein massiver Testkörper innerhalb oder außerhalb einer Hill-Sphäre eines Planeten befindet, müsste dann im Programm mit unterschiedlichen Hamilton-Funktionen gerechnet werden. Die konkreten Koordinatentransformationen (z.B. Heliozentrisch->Jacobi o.ä.) werden dadurch dann zeitabhängig, je nachdem welches Subsystem gerade aktiv ist.
Gruß

SRMeister
11.11.2012, 01:45
ich hätte eh gedacht, dass es so gemacht wird. sehr merkwürdig das ganze. Wozu soll man Jacobicoord. einführen, wenn man sie letztendlich nicht voll ausnutzt.
Soweit ich das verstehe, sollte das System selbst ohne merklichen Mehraufwand erkennen können, welcher Körper sich in welcher Hillsphäre befindet und die Berechnung entsprechend anpassen.

Bernhard
11.11.2012, 10:46
Wozu soll man Jacobicoord. einführen, wenn man sie letztendlich nicht voll ausnutzt.
Wenn man "nur" die Stabilität der Planetenbahnen oder des Sonnensystems als Ganzes über sehr große Zeitskalen (> 1 Millionen Jahre) untersuchen will ist das auch ohne Planetenmonde ein sehr interessanter Ansatz. Der Programmieraufwand fällt durch Vernachlässigung sämtlicher Monde, wie gesagt, deutlich geringer aus. J. Wisdom et al haben sich darüberhinaus auch noch mit einer Vereinfachung der Störterme beschäftigt um Rechenzeit zu sparen (Faktor 1000).

Bernhard
12.11.2012, 18:55
Ich habe gerade zwei kleinere Fehler in dem C++-SCATR-Code gefunden. Die Fehler waren in den Dateien, welche die Systemwechsel Jacobi <-> Heliozentrisch, bzw. Jacobi <-> Schwerpunkt berechnen. Ich werde als nächstes versuchen hier sämtlich cpp-Dateien fehlerfrei zu bekommen. Im Prinzip ist das eine Art Übungsaufgabe, weil die Rücktransformation Jacobi -> "euklidisch" in [WH91] nicht angegeben ist. Google hilft da auch nicht unmittelbar weiter, so dass man das selber ausrechnen muss. Ohne die Rücktransformation kommt man im Thema ab hier aktuell nicht wirklich weiter.
Gruß

Bernhard
13.11.2012, 23:27
Die Transformation von den Jacobi-Koordinaten in die kartesischen Koordinaten kann man iterativ mit den zwei folgenden Formeln ausrechnen:


\mathbf{x}_{n-1} = \frac{M-m_{n-1}}{M}\;\mathbf{x}'_{n-1}\;+\;\mathbf{x}'_0


sowie


\mathbf{x}_{i-1} = \mathbf{x}_{i}\; -\; \mathbf{x}'_{i}\; +\; \frac{\eta_{i-2}}{\eta_{i-1}}\; \mathbf{x}'_{i-1}


wobei M die Gesamtmasse aller n Körper ist.

Bernhard
20.11.2012, 22:25
Nachdem die Transformation in Jacobi-Koordinaten und wieder zurück aufgeschrieben ist, kann man sich die Lösung des Anfangwertproblems des Zwei-Körper-Problems genauer ansehen. Der SCATR-Code (alternativ auch das Buch von Danby) zeigt jedoch schon beim Überfliegen, dass dieses Thema deutlich komplexer ist, als man vielleicht vermutet. Die Lösung der Kepler-Gleichung (s. zugehöriger Wiki-Artikel) ist da nur die Spitze eines beeindruckenden "Eisberges", der dafür sorgt, dass alle Erhaltungssätze des Zwei-Körper-Problems berücksichtigt werden.
Gruß

SRMeister
26.11.2012, 11:09
Ich konnte zwischenzeitlich den SWIFTER (incl. SyMBA) zum laufen bringen.
Nun müsste man als nächstes wieder so ein Interface Fortran->C++ erstellen, wie wir schon bei SCATR gemacht haben.
Ich könnte auch die benötigten Arbeitsschritte/ Dateien veröffentlichen, bei Interesse.
Der Knackpunkt war, dass SWIFTER auf spezielle, nur auf Linux verfügbare Routinen zurückgreift, um bestimmte Zwischenergebnisse binär in Dateien abzulegen (I/O-Problem). Nun habe ich eine Portierung dieser Funktionen auf Windows eingebunden.

Wie gesagt, bei Interesse könnte man jetzt an SWIFTER anknüpfen, nach dem Interface bspw. Bernhards Fragmentgenerator und/oder meine Benutzeroberfläche usw. anbinden.

Bernhard
26.11.2012, 11:34
Hallo SRMeister,

für mich wäre bei SyMBA noch wichtig zu wissen, nach welchen Algorithmen die nahen Vorbeiflüge berechnet werden. Wenn Du einen Link auf ein paper dazu hast nur her damit.
MfG

SRMeister
26.11.2012, 12:08
Hallo Bernhard,
hier (http://iopscience.iop.org/1538-3881/116/4/2067/pdf/980072.web.pdf) auf Seite 2069 Punkt 3. Der SyMBA in SWIFTER wurde noch verbessert, wie hier (http://iopscience.iop.org/1538-3881/120/4/2117/pdf/200108.web.pdf)beschrieben, jedoch betrifft das nicht die variablen Zeitschritte bei close-encounters.

Bernhard
26.11.2012, 17:51
Hallo SRMeister,

momentan beschäftige ich mich, ehrlich gesagt, noch mit dem Buch von Danby. Die verschiedenen Möglichkeiten das Zwei-Körper-Problem als Anfangswertproblem zu lösen sind sehr interessant (f und g-Funktionen, universelle Variablen) und wichtig. Bevor ich mir die spezielleren Algorithmen aus den Veröffentlichungen genauer ansehe, möchte diesen Punkt richtig verstanden haben und auch mal programmiert haben. Danby schlägt dann als Test vor einen beliebigen Anfangszustand um ein dt in die Zukunft zu rechnen und dann mit dem gleichen Verfahren zu testen, ob man mit einem -dt wieder auf die ursprünglichen Positionen kommt.
Gruß

SRMeister
27.11.2012, 11:44
okay. Das finde ich im Prinzip gut, dass wir uns von mehreren Seiten dem Problem nähern.

Ich habe noch einen interessanten Absatz im Readme von Swifter gefunden, den ich mal hier teilen wollte. Wäre vllt. auch für Bynaus interessant.


INTRODUCTION

The Swifter subroutine package provided here is designed to integrate a
set of mutually gravitationally interacting massive bodies together with a
group of massless test particles which feel the gravitational influence of the
massive bodies but do not affect each other or the massive bodies. (NOTE: the
SyMBA integrator supports a second class of massive bodies whose masses are
less than some user-specified value, MTINY. These bodies gravitationally
affect and are affected by the more massive bodies, but do not interact with
themselves.)

ich versuch das jetzt mal auf den Stand zu bringen, wo wir mit SCATR waren.

Bernhard
27.11.2012, 12:58
ich versuch das jetzt mal auf den Stand zu bringen, wo wir mit SCATR waren.
Ja gut. Ich werde auch weiterhin an dem Debugging der WinSCATR-Version (C++) arbeiten. Die dortigen Auswertungsfunktionen gefallen mir im Grunde sehr gut. Wenn man anhand von Listen sieht, was mit den Testkörpern passiert ist das natürlich wesentlich aussagekräftiger als eine grafische Simulation.

Für Testzwecke kann man zusätzlich verschiedene Teile aus dem WinSCATR-Code in unsere Planetensimulation einbauen. So kann man Datei für Datei entscheiden, ob es für das aktuelle Vorhaben Vorteile bringt oder nicht. Langfristig kann/könnte so eine C++Version entstehen, die maßgeschneidert die Vorgaben von Bynaus berechnet.

Kibo
27.11.2012, 20:14
Seh ich das richtig, einer arbeitet mit SWIFTER und der andere mit SCATR weiter?
Mir erschließt sich der Sinn einer solchen "Aufteilung" jetzt nicht...


mfg

SRMeister
27.11.2012, 20:30
naja, der Sinn ist, dass SCATR in C++ vorliegt und damit eigenen Änderungen zugänglich ist. Während SWIFTER in Fortran quasi nur als "Black Box" genutzt werden kann.
Ich finde das garnicht so schlecht, immerhin beschäftigt sich Bernhard intensiv mit den Grundlagen, wodurch er später einen eigenen Integrator aufbauen kann, der genau an das Problem angepasst ist.
Edit: Beide Versionen sind aber relativ nah verwandt, also kann man sich auch später noch aufeinander zubewegen :)

Bernhard
27.11.2012, 22:16
Ich habe mittlerweile den Zwei-Körper-"Propagator" mit den f und g-Funktionen implementiert und getestet. In dem Buch von Danby ist ein Programmlisting in BASIC, was nur noch übersetzt werden musste.

Der Test hat gezeigt, dass eine zeitliche Vorwärtsbewegung um einen Tag und anschließendes Zurückrechnen auf die Ausgangsposition bei Merkur die größten Fehler verursacht. Ich bekam dort immerhin eine absolute Abweichung von ungefähr 1/100 der Wegstrecke. Das erscheint mir ungewöhnlich viel und ich würde gerne wissen, warum der Fehler dort so hoch ist. Bei den nach außen folgenden Planeten nimmt der Fehler immer weiter ab.

Bernhard
28.11.2012, 10:25
Als nächstes wären jetzt die universellen Variablen dran, die auch im SCATR-Code verwendet werden. Bei diesem Verfahren kann man alle Kegelschnitte berechnen, nicht nur Ellipsen. Auch dort sind dann natürlich Tests auf Genauigkeit interessant.

BTW: Ich mache mir aktuell auch so einige Gedanken über die generelle Güte der SCATR und SWIFTER-Simulationen. Die sind zwar allesamt sehr ausgefeilt und elegant, aber auf ein Laufzeit von Milliarden von Jahren spielen relativistische Effekte durchaus eine Rolle. Merkurs Bahn dreht sich beispielsweise aufgrund der relativistischen Periheldrehung in dieser Zeit viele Male (alle 3 Millionen Jahre einmal) um sich selbst und bei den anderen Planeten ist dieser Effekt auf so lange Zeiten ebenfalls nicht zu vernachlässigen.

SRMeister
29.11.2012, 22:50
Ich bin gerade auf ein Problem gestoßen, welches erstmal mehr Analyse erfordert. Fortran und C++ können nicht auf triviale Weise Zeiger miteinander austauschen, wovon aber SWIFTER leider viel gebrauch macht (Zeiger gibt es in Fortran erst seit Fortran-90, das SCATR ist noch in Fortran-77).

Ich muss nun entweder einen Großteil von SWIFTER nach C++ portieren, oder SWIFTER zu Fortran-2003 erweitern, welches C++ Interfacemöglichkeiten bietet. Beides gefällt mir nicht :)

Bynaus
30.11.2012, 11:28
Zuerst: Ich muss sagen, dass ich beeindruckt bin und grossen Respekt habe vor der Arbeit, die ihr hier leistet.

Ich frage mich aber, ob es wirklich am Ende zielführend ist, SWIFTER/SymBA nach C++ zu transportieren. So wie ich das verstehe wollt ihr eine C++-Schnittstelle zu SRMeisters grafischem Output, aber könnte man das nicht auch anders lösen? Übersetzungen sind immer mit der Möglichkeit von Fehlern behaftet. Mein (vielleicht etwas laienhafter) Vorschlag: Wäre es denn nicht möglich, die Integratoren einfach in FORTRAN zu belassen, aber dem grafischen Outputprogramm beizubringen, mit den Outputdaten der Integratoren zu arbeiten? Ich nehme an, die geben irgend ein Textfile aus, mit Positionen und Zeitpunkten - oder? Das heisst dann zwar, dass zwischen der Berechnung und der Darstellung des Outputs ein weiterer Schritt steht - aber das tut doch der Nützlichkeit des ganzen keinen grossen Abbruch, oder?

@Bernhard: Im ursprünglichen Projekt ging es ja darum, das Schicksal allfälliger Theia-Trümmer zu verfolgen. Dieses dürfte nach ein paar Millionen Jahren ohnehin besiegelt sein. Und da wir eh nicht so genau wissen, wo die Planeten damals standen (weil das Sonnensystem ja jenseits von ein paar 10 Mio Jahren chaotisch ist), macht es auch keinen Sinn, sehr kleine Effekte in die Simulation aufzunehmen.

Bernhard
30.11.2012, 22:58
Zuerst: Ich muss sagen, dass ich beeindruckt bin und grossen Respekt habe vor der Arbeit, die ihr hier leistet.
Vielen Dank. So etwas motiviert weiter zu machen.


Wäre es denn nicht möglich, die Integratoren einfach in FORTRAN zu belassen, aber dem grafischen Outputprogramm beizubringen, mit den Outputdaten der Integratoren zu arbeiten?
Mir persönlich würde da vor den großen Datenmengen grausen, aber SRMeister ist hier aktuell der kompetentere Ansprechpartner.


@Bernhard: Im ursprünglichen Projekt ging es ja darum, das Schicksal allfälliger Theia-Trümmer zu verfolgen. Dieses dürfte nach ein paar Millionen Jahren ohnehin besiegelt sein. Und da wir eh nicht so genau wissen, wo die Planeten damals standen (weil das Sonnensystem ja jenseits von ein paar 10 Mio Jahren chaotisch ist), macht es auch keinen Sinn, sehr kleine Effekte in die Simulation aufzunehmen.
OK. Zu einer Simulation über ein paar Millionen Jahre könnte ich mich überreden lassen. Für mich wäre es zudem einigermaßen reizvoll Monde mit dem bereits veröffentlichten Formalismus (Wisdom/Holman) zu beschreiben. Ich habe da für den "großen" Anteil der Hamiltonfunktion verwertbare Ideen. Kopfzerbrechen bereitet mir der verbleibende Störterm, weil mir die dortige Entwicklung nach der Planetenmasse noch nicht klar ist. Die ist aber für die Numerik recht wichtig, weil man sonst bei jedem Zeitschritt von den Jacobi-Koordinaten wieder zurück zu den eukidischen Koordinaten transformieren muss.
MfG

Bernhard
01.12.2012, 18:50
weil man sonst bei jedem Zeitschritt von den Jacobi-Koordinaten wieder zurück zu den eukidischen Koordinaten transformieren muss.
Ich korrigiere zu: "weil man sonst bei jedem Zeitschritt von den restlichen euklidischen Koordinaten zu den neuen Jacobi-Koordinaten transformieren muss."

Bernhard
10.12.2012, 20:49
Hallo Bynaus und SRMeister,

ich bin zur Zeit noch mit der expliziten Berechung der Ortsableitungen der exakten Wechselwirkungs-Hamiltonfunktion beschäftigt. Es ergeben sich dabei einigermaßen übersichtliche Formeln. Wisdom & Holman schreiben zwar, dass die genäherte Wechselwirkungs-Hamiltonfunktion eigentlich ausreicht, ich würde aber als Übung ganz gerne den Mond auch einmal explizit in der Hamiltonfunktion berücksichtigen, um zu sehen welche Ergebnisse das bringt.
MfG

Bernhard
12.12.2012, 19:17
Der Test hat gezeigt, dass eine zeitliche Vorwärtsbewegung um einen Tag und anschließendes Zurückrechnen auf die Ausgangsposition bei Merkur die größten Fehler verursacht. Ich bekam dort immerhin eine absolute Abweichung von ungefähr 1/100 der Wegstrecke. Das erscheint mir ungewöhnlich viel und ich würde gerne wissen, warum der Fehler dort so hoch ist. Bei den nach außen folgenden Planeten nimmt der Fehler immer weiter ab.
Grund für die Abweichung von 1/100 war ein Programmierfehler. Nach Beseitigung desselben wird das Keplerproblem jetzt bis auf unwesentliche Abweichungen im Micrometer-Bereich korrekt gerechnet. Ich habe jetzt eine Programmversion, bei der die Wechselwirkung der Planeten untereinander erst noch vernachlässigt wird. Jede Planetenbahn wird also nur als Keplerbahn berechnet. Bei dem System Erde-Mond beschreibt der Schwerpunkt ebenfalls eine Keplerbahn und das System selbst wird ebenfalls als Zwei-Körper-Problem gerechnet. Die resultierende Ephemeride für Venus ist bei einer Laufzeit von einem Jahr erfreulich genau. Man muss sich da natürlich erst noch weitere Ergebnisse ansehen, um zu testen, dass dieses Ergebnis kein Zufallstreffer ist. Die Ephemeride des Mondes weist leider noch einen deutlichen Fehler auf. Die Berechnung der Ableitungen der Wechselwirkungshamiltonfunktion ist aber weitgehend fertig.
MfG

Bernhard
17.12.2012, 14:10
Hallo Bynaus und SRMeister,

in der Hoffnung, dass noch Interesse an dem Thema besteht: Ich habe jetzt privat mal die indirekten Störungen programmiert und die Vorarbeit für die direkten Störungen der Planetenbahnen gemacht. Es ist schon jetzt interessant zu sehen, wie groß die Korrekturen aufgrund der Jacobi-Koordinaten sind. Um dann anhand der vorausberechneten Ephemeriden abschätzen zu können, was die Algorithmen wirklich leisten wird es also noch ein wenig dauern. Ob vor oder nach den Feiertagen kann ich noch nicht sagen, aber es bleibt weiterhin interessant und ich denke es sind auch wichtige Vorarbeiten für das Projekt TheiaSim mit den 5 massiven Bruchstücken.
MfG

Bynaus
17.12.2012, 14:19
@Bernhard: Ich habe schon noch Interesse am Projekt. Ich kann dir aber schon längst nicht mehr folgen (bzw., hätte auch gar nicht die Zeit, das zu versuchen).

Bernhard
17.12.2012, 15:11
Ich kann dir aber schon längst nicht mehr folgen (bzw., hätte auch gar nicht die Zeit, das zu versuchen).
Hi Bynaus,

ich bin immer noch dabei die Verfahren aus der 1991er Arbeit von Wisdom&Holman dazu zu verwenden, um ganz normale Ephemeriden (=Positionen) der Planeten auszurechnen. Die zugehörigen Ergebnisse kann man anhand des ausgezeichneten NASA HORIZONS-Web-Interface sehr leicht auf Genauigkeit testen. Sobald das dann fertig ist, kann man langzeitige Simulationen (> 1 Millionen Jahre) testen, weil das die zugrundeliegenden Algorithmen von Wisdom&Holman gut ermöglichen.

Man kann so einige grundlegende Ergebnisse der neueren Forschung nachvollziehen :) , z.B. Schwankungen der Exzentrizitäten der Bahnen usw.

Der Beitrag von vorhin ist also eher als Status-Bericht zu verstehen.
MfG

Bernhard
21.12.2012, 17:15
Hallo Bynaus und SRMeister,

die zusätzliche Übungsaufgabe scheint weitgehend abgeschlossen zu sein und lieferte eben recht interessante Ergebnisse. Bei einer Berechnung der Position des Mondes 100 Jahre nach dem 01.04.2011 lagen die Ergebnisse der neuen Programmversion, die Jacobi-Koordinaten verwendet, weniger als 4 Bogenminuten von der HORIZONS-Position entfernt. Das alte Programm mit der Bulirsch-Stoer-Integration hat über diese Zeitspanne ziemlich unbrauchbare Ergebnisse berechnet und das in starker Abhängigkeit von der Schrittweite. Eine Angleichung der Schrittweite (2160 Sekunden) zwischen der Jacobi-Version und der Bulirsch-Stoer-Version brachte vorerst keine Ergebnisse, weil die Rechenzeit der Bulirsch-Stoer-Version weit über der der Jacobi-Version (ca. 40 Sekunden) lag. Konkurrenzfähig ist über diese Zeitspanne noch das Runge-Kutta-Verfahren in vierter Ordnung. Die zugehörige Version rechnet mit ca. 30s Rechenzeit sogar etwas schneller als die Jacobi-Version. Die berechnete Position des Mondes ist dabei nur unwesentlich schlechter, als bei der Jacobi-Version.

Die Berücksichtigung des Mondes bei den Jacobi-Koordinaten hat noch gezeigt, dass 5 massive Bruchstücke mit diesem Ansatz praktisch nicht mehr berechenbar sind, weil man bei den nötigen Ableitungen der ungenäherten Hamiltonfunktion eine kaum noch zu überblickende Anzahl an Störtermen bekommt. Wie die in [WH91] erwähnte Vereinfachung/Näherung der Wechselwirkungshamiltonfunktion berechnet wird ist mir leider immer noch nicht klar, aber ich habe jetzt auch wieder mehr Zeit dieser Frage nachzugehen.

Vermutlich bleibt für die Bearbeitung von Bynaus' Projektidee also nur das SyMBA-Paket als sinnvolle Lösung übrig.
MfG

Bernhard
26.12.2012, 10:00
Beides gefällt mir nicht :)
Hallo SRMeister,

ich habe gerade gesehen, dass man das SWIFTER-Paket mit den aktuellen GNU-Tools übersetzen kann. Ein Makefile wird ja mitgeliefert. Mit den Befehlen gcc, gfortran und make kann nach wenigen Anpassungen (siehe mitgelieferte README-Datei) an die lokale Installation das gesamte Paket übersetzt werden. Die mitgelieferten Beispieldateien enthalten leider keine Hill-Radien, so dass man mit diesen Beispieldateien ohne Modifikationen nichts machen kann.

Die vorgeschlagene Näherung aus dem 91er Wisdom-Holman-Paper habe ich mittlerweile nachgerechnet. Sie setzt voraus, dass die Jacobi-Koordinaten aus den euklidischen Schwerpunktskoordinaten berechnet werden. Deswegen verstehe ich nicht, warum die SCATR-Autoren bei den Eingabedateien heliozentrische Koordinaten verwenden. Das ist allerdings mittlerweile nebensächlich, da wir den SCATR-Code sowieso nicht weiter verwenden wollen.

Für die weitere Bearbeitung des Themas sind Fortran90-Kenntnisse also unumgänglich. Welche Literatur würdest Du da empfehlen?
MfG

Bernhard
27.12.2012, 16:55
Welche Literatur würdest Du da empfehlen?
Auch das hat sich mittlerweile erledigt, weil es zu Fortran90 ausreichend Standardliteratur gibt.

Bernhard
27.12.2012, 20:32
ich habe gerade gesehen, dass man das SWIFTER-Paket mit den aktuellen GNU-Tools übersetzen kann. Ein Makefile wird ja mitgeliefert. Mit den Befehlen gcc, gfortran und make kann nach wenigen Anpassungen (siehe mitgelieferte README-Datei) an die lokale Installation das gesamte Paket übersetzt werden. Die mitgelieferten Beispieldateien enthalten leider keine Hill-Radien, so dass man mit diesen Beispieldateien ohne Modifikationen nichts machen kann.
Hallo Bynaus,

ich habe gerade SyMBA mit den mitgelieferten Beispieldateien ausprobiert. Dabei werden die vier großen Planeten (Saturn, Jupiter, Uranus und Neptun) als gravitierende Massen und Pluto als masseloser Testkörper betrachtet. Den Hill-Radius kann man für jeden massiven Körper in der Datei pl.in einfach hinter die Masse als zusätzlichen Parameter setzen. Im Prinzip kann man jetzt die Eingabedateien soweit präparieren, dass man Deinen Projektvorschlag beispielsweise über einen Zeitraum von drei Millionen Jahre rechnen lassen kann.

Ich werde das als nächstes dann vorbereiten und nachsehen, ob das Programm interessante Ergebnisse berechnet.
MfG

EDIT: Lasse gerade SyMBA mit 8 Planeten (Merkur,Venus,Erde,Mars,...,Neptun) und 25 Testkörpern laufen. Schrittweite 8 Tage wegen der geringen Umlaufzeit von Merkur. Ich müsste jetzt nur noch wissen wie man den Testkörpern eine Masse mitgeben kann.

EDIT_EDIT: In einhunderttausend Jahren überschreitet laut SyMBA ein Testkörper die Grenze von 500 AU. (Das wussten wir eigentlich schon)

Bernhard
28.12.2012, 06:21
Ich habe jetzt die Eingabedateien gemäß Bynaus' Vorgaben komplett mit 5 massiven Testkörper (1 Mondmasse und viermal 0.1 Mondmassen), die von der Erdoberfläche starten und 20 Testkörper, die ebenfalls mit zufälligen Richtungen von der Erdoberfläche starten. Das Flag CHK_CLOSE für planetary close encounters habe ich auf yes gesetzt. Bei den Planetendaten muss man dann auch die Radien der Planeten mit angeben.

Leider liefert das Modul swifter_symba dann Fehlermeldungen:

SWIFTER Warning:
In symba_step_recur, local time step is too small
Roundoff error will be important!
Planet 5 is lost!!!!!!!!!!

aber man kann im Quelltext ja nachsehen, was da schief läuft.

Bernhard
28.12.2012, 17:06
ich habe gerade gesehen, dass man das SWIFTER-Paket mit den aktuellen GNU-Tools übersetzen kann. Ein Makefile wird ja mitgeliefert. Mit den Befehlen gcc, gfortran und make kann nach wenigen Anpassungen (siehe mitgelieferte README-Datei) an die lokale Installation das gesamte Paket übersetzt werden.

Schade nur, dass die derart übersetzten Dateien nicht ausführbar sind. Eventuell fehlen bei dem Befehl gfortran -c aber auch nur die passenden Compilerflags? Aktuell verwende ich deswegen wieder den Intel Fortran Compiler ifort.

Bynaus
28.12.2012, 20:01
Hallo Bernhard,
Das klingt sehr interessant! Ich vermute mal, die Ursache deiner Fehlermeldung liegt darin, dass du die Objekte von der Erdoberfläche aus starten lässt. Lass sie doch ein paar 100000 km weiter oben starten (mit angepassten Geschwindigkeiten, natürlich), dann sollte das wohl kein grosses Problem sein.

Übrigens: Wir sind nicht (mehr) die einzigen: Hier hat eine Gruppe die Trümmer der "klassischen" Giant Impact Kollision verfolgt. http://arxiv.org/abs/1206.4190 Wäre vielleicht interessant, bei diesen nachzusehen, wie sie die hier diskutierten Probleme gelöst haben. Ausserdem habe ich heute von einer anderen Gruppe erfahren, die sich des Themas angenommen hat. Was natürlich nicht heisst, dass wir gleich aufgeben sollten, im Gegenteil. :)

Bernhard
28.12.2012, 21:43
Hi Bynaus,

ich habe es gerade mit einer Starthöhe von 500.000 km (etwa = halber Hill-Radius) probiert und siehe da: Swifter kommt klar damit :) .

Den verlinkten Preprint habe ich überflogen. Die verwenden den Mercury-Code, den wir ganz am Anfang mal diskutiert hatten. Man müsste jetzt in den nächsten Schritten Swifter dazu bringen Daten zu liefern. Das kann wieder etwas dauern. Leider produziert Swifter nur Binärdaten, die eventuell mit den mitgelieferten Tools analysiert werden können.

Zeitlich bleibt alles sehr eng und ich denke wir sollten uns da auch weiterhin keinen Stress machen. Alles just for fun. Solltest Du irgendwann etwas veröffentlichen wollen verzichte ich voraussichtlich sowieso auf meine Autorenschaft, weil ich nicht in der Forschung tätig bin.
MfG

EDIT: Die kleine Schrittweite von 8 Tagen erhöht leider die Rechenzeit ziemlich stark. Das kann noch Probleme machen, weil ich meinen Rechner nicht tagelang rechnen lassen will.

Bynaus
28.12.2012, 23:51
Swifter kommt klar damit

Super! :)


Zeitlich bleibt alles sehr eng und ich denke wir sollten uns da auch weiterhin keinen Stress machen. Alles just for fun.

Sehe ich genauso!


Solltest Du irgendwann etwas veröffentlichen wollen verzichte ich voraussichtlich sowieso auf meine Autorenschaft, weil ich nicht in der Forschung tätig bin.

Das solltest du sicher nicht tun. Ob jemand in der Forschung tätig ist, spielt keine Rolle (es gibt immer wieder mal solche Fälle! Gerade z.B. in der Meteoritenforschung, wo manchmal passionierte Sammler auf Entdeckungs-Papers eines kürzlich gefallenen Meteoriten drauf sind). Der Hauptautor ist eigentlich stets der, der das Paper geschrieben hat, aber alle, die beigetragen haben, sollten Ko-Autoren sein. Sollte es jemals eine Publikation geben aus diesem Projekt, wirst du sicher mit drauf sein!

Bernhard
29.12.2012, 00:34
Ob jemand in der Forschung tätig ist, spielt keine Rolle
OK. Das wusste ich nicht.

Bernhard
29.12.2012, 09:05
Guten Morgen Bynaus,

für die Ergebnisse von Swifter gibt es eine recht umfangreiche Visualierungssoftware (http://www.boulder.swri.edu/swifter/). Swifter produziert bei mir bereits Binärdaten in der Ausgabe und ich werde heute mal versuchen diese mit SwiftVis zu visualisieren.
MfG

EDIT: Vom ersten Überfliegen und Ausprobieren her vermute ich mal, dass man mit SwiftVis vorwiegend, bzw. nur Bahnelemente analysieren kann :( . Das ist für unsere Zwecke (Verteilung der Positionen) leider wenig hilfreich. Vermutlich müsste man jetzt die nötigen Ausgabefunktionen aus dem SCATR-Code in den Swifter-Code einbauen, um an die Positionen der verschiedenen Körper zu kommen. Man könnte dann prinzipiell die Positionen auch in eine Grafik packen. Leider "riecht" das alles nach ziemlich viel Arbeit.

Bernhard
29.12.2012, 14:21
Vermutlich müsste man jetzt die nötigen Ausgabefunktionen aus dem SCATR-Code in den Swifter-Code einbauen, um an die Positionen der verschiedenen Körper zu kommen.
Die Swifter-Ausgabefunktionen kann man relativ leicht anpassen, so dass die Endpositionen aller Planeten und Testkörper in eine Textdatei geschrieben werden. Irgendetwas scheint dabei aber noch nicht zu funktionieren, weil mit unmodifizierten Startbedingungen (ohne Mond) und einer Laufzeit von 1000 Jahren Merkur bei etwa 4 AU stoppt. Die anderen Planeten bekommen leider ebenfalls ziemlich eigenartige Werte.

Bernhard
29.12.2012, 23:21
Die anderen Planeten bekommen leider ebenfalls ziemlich eigenartige Werte.
Hallo Bynaus,

zum Abschluss des Tages gibt es doch noch eine kleine Erfolgsnachricht. Bei der Ausgabe der Planetenpositionen ist mir beim letzten Beitrag nicht aufgefallen, dass die unterliegende verlinkte Liste nicht sortiert war. So standen die Werte von Jupiter an zweiter Position und ich dachte es wären die Werte für Merkur, usw. (Ist halt mein erstes Fortran90 Projekt :o )

D.h. Ich habe jetzt eine SyMBA-Version, welche die wichtigsten Daten als Klartext in eine Textdatei schreibt!! Wir müssten jetzt nur noch ein Programm suchen, das diese 2D-Koordinaten in eine geeignete Grafik einzeichnet und wir bekommen die berechnete Verteilung der Fragmente im Sonnensystem.

Da das www sicher solche Programme bietet, werde ich jetzt wieder die uns interessierenden Daten verwenden und austesten wie viele Testkörper ich alleine noch generieren kann. Interessant wäre schon mal die Verteilung von 1000 Fragmenten nach 1000 Jahren :cool: .
MfG

EDIT: 1000 Fragmente über 1000 Jahre ist kein Problem. Rechenzeit ganz grob einige wenige Minuten. 5 Fragmente werden dabei von der Erde eingefangen. Man kann bei SyMBA übrigens auch angeben, ab welcher Distanz zur Sonne Fragmente von der Sonnen eingefangen werden.

Bynaus
30.12.2012, 00:45
Hallo Bernhard - toll, das sind ausgezeichnete Neuigkeiten!

Sind das 1000 massive oder massenlose Fragmente? Und welche Anfangsverteilung in Position und Geschwindigkeit hast du ihnen gegeben?
Ich denke, im Notfall kann man die Darstellung auch in Matlab oder so machen, ich glaube, das ist ganz üblich. Vielleicht kann ja auch SRMeister die Textausgabe-Dateien in sein Programm einlesen?

Bernhard
30.12.2012, 11:32
Hallo Bernhard - toll, das sind ausgezeichnete Neuigkeiten!
Das SyMBA-Paket scheint geeignet zu sein. Es enthält wirklich nette Features.


Sind das 1000 massive oder massenlose Fragmente?
Es sind 5 Fragmente mit Masse (1x Mondmasse + 4x 1/10 Mondmasse) und 1000 Fragmente ohne Masse.


Und welche Anfangsverteilung in Position und Geschwindigkeit hast du ihnen gegeben?
Die masselosen Körper starten an der Erdoberfläche mit einer maximalen Abweichung zwischen +20° und -20° zur Ekliptik. Die Richtung innerhalb der Ekliptik ist zufällig verteilt.

Die fünf Körper mit Masse starten innerhalb eines elliptischen Kegels, dessen Symmetrieachse in der Ekliptik liegt und der eine Öffnung von 5° innerhalb der Ekliptik und 10° senkrecht zur Ekliptik besitzt.

Sowohl die masselosen als auch die Trümmerteile mit Masse steigen zuerst nur im Gravitationsfeld der Erde auf eine Höhe von 500 Tausend Kilometer und werden dabei entsprechend des Energiesatzes abgebremst. Die Startgeschwindigkeit an der Erdoberfläche liegt für alle Trümmerteile zwischen 1.0x und 1.4x Fluchtgeschwindigkeit an der Erdoberfläche (ca. 11 km/s). Der weitere Verlauf ab dieser Höhe wird dann von SyMBA berechnet.


Ich denke, im Notfall kann man die Darstellung auch in Matlab oder so machen, ich glaube, das ist ganz üblich. Vielleicht kann ja auch SRMeister die Textausgabe-Dateien in sein Programm einlesen?
Ich habe gestern fünf "Snapshots" mit den Simulationszeiten 1,10,100,1000 und 10000 Jahre laufen lassen. Die 10000-Jahre Simulation hat ca. 45 Minuten gerechnet. Für die grafische Darstellung der Ergebnisse dachte ich zuerst an GNUPlot (http://www.heise.de/download/gnuplot.html). Das ist kostenlos und für solche Zwecke in der Technik sehr beliebt. Wenn Du Matlab hast schicke ich Dir die Ergebnisse gerne per eMail zu. Für den Fall, dass SRMeister gerade im Urlaub ist, müssen wir uns erst mal selbst behelfen. Wichtig wäre noch eine Skala an der Grafik.
MfG

Bernhard
04.01.2013, 01:08
Hallo Bynaus,

ich habe SyMBA eben noch als Test mit reinen Planetenstartbedingungen inklusive Mond, aber ohne masselose Testkörper "gefüttert". Wenn sich bei dem SCATR-Code und einer Rechnung über 1000 Jahre das System Erde-Mond praktisch komplett getrennt hat, so bleibt bei SyMBA das System gravitativ gekoppelt. SyMBA verwendet für dieses Subsystem also im Wesentlichen die korrekten Keplerorbits :) .
MfG

Bynaus
04.01.2013, 07:34
Hallo Bernhard,

Das klingt alles sehr gut - die Startbedingungen scheinen mir ausgezeichnet gewählt. In einem späteren Run können wir gerne noch die Masse der massiven Fragmente erhöhen, so dass sie grob einer Power-law folgen, in der Summe aber weniger als ca. 0.05 Erdmassen haben.
GNUplot is für mich übrigens genauso okay wie Matlab, das war nur ein Beispiel. Das einzige, was in diesen Plots jetzt noch fehlt, sind die Bahnen der Planeten (z.B. in einer anderen Farbe), aber das ist ja letztlich fast trivial.

Ich würde gerne das Programm mal ausprobieren - kannst du es kompilieren und mir schicken? Dann kann ich auch mal ein wenig damit spielen! :)

Hast du schon Statistiken erstellt, wie viele Teilchen jeweils mit den Planeten kollidieren, insbesondere mit der Erde? Was geschieht mit den massiven Teilen?

Bernhard
04.01.2013, 10:55
Das einzige, was in diesen Plots jetzt noch fehlt, sind die Bahnen der Planeten (z.B. in einer anderen Farbe), aber das ist ja letztlich fast trivial.
Kann ich machen. Ich kann dabei erst mal nur mit einem Zeichenprogramm dünne, konzentrische Kreise für die Planeten Merkur, Venus, Erde und Mars einzeichnen.



Ich würde gerne das Programm mal ausprobieren - kannst du es kompilieren und mir schicken? Dann kann ich auch mal ein wenig damit spielen! :)
Ich habe SyMBA aktuell nur als Binärdatei für OpenSuSE 12.1 in der 64Bit Version, weil ich das auf meinem Rechner so installiert habe. Ob man diese Binärdatei mit Linux-Emulatoren (da gibt es ganz gute im Netz) bei Dir zum Laufen bekommt kann ich allerdings nicht versprechen und würde deswegen von derartigen Experimenten eher abraten.

Der sicherste und erfolgversprechendste Weg wäre hier, wenn Du Dir auf Deinem Rechner Linux als zweites Betriebssystem installierst. Ich habe bei mir ein OpenSuSE 12.1 (64Bit-Version) laufen. Ich könnte Dir auch Schritt für Schritt erklären, wie Du das machen kannst (Installationssupport). Man bekommt nach der Installation dann beim Start des Rechners ein Auswahlmenü mit welchem Betriebssystem gearbeitet werden soll. Der Speicherplatz auf der Festplatte der dabei verwendet werden soll kann eingestellt (das ist der schwierigste Punkt der Installation und nennt sich Partitionieren der Festplatte) werden und beträgt minimal 5 GB. Ich könnte Dir dann ebenfalls Schritt für Schritt erklären, wie Du den Quelltext von Swifter kompilieren kannst und dann das Programm testen kannst. Wenn Dich das interessiert sollten wir ein neues Thema mit dem Titel "Dualboot Windows7+Linux" aufmachen.


Hast du schon Statistiken erstellt, wie viele Teilchen jeweils mit den Planeten kollidieren, insbesondere mit der Erde? Was geschieht mit den massiven Teilen?
Das Programm druckt während des Programmablaufes Meldungen über die Testkörper aus, die mit Planeten kollidieren und auch über Testkörper, die das Sonnensystem verlassen. Erstaunlicherweise passiert da ziemlich wenig. Bei der Rechnung über 1000 Jahre gibt es aktuell nur fünf Kollisionen mit zwei Planeten (welche genau habe ich momentan nicht mehr im Kopf. Es sind entweder die fünf massiven Trümmerteile oder einer der Planeten Merkur, Venus, Erde). Bei der Rechnung über 10000 Jahre war mindestens ein Testkörper dabei, der das Sonnensystem verlassen hat. Am Ende waren aber immer noch rund 990 Testkörper aktiv, also ohne Kollision oder Runaway.

Die massiven Trümmerteile befinden sich nach 10000 Jahren im Bereich r=0.75 AU bis r=1.1 AU.
MfG

Bynaus
04.01.2013, 11:21
Ich kann dabei erst mal nur mit einem Zeichenprogramm dünne, konzentrische Kreise für die Planeten Merkur, Venus, Erde und Mars einzeichnen.

Fürs erste (zur Illustration) reicht das auch schon.


Dualboot Windows7+Linux

Okay, das ist mir im Moment etwas viel Aufwand, gerade auch, weil am Dienstag eine Abstract-Deadline ansteht. Wir können das mal angehen, wenn ich mehr Zeit habe - sofern du natürlich bereit bis, bis dahin die Anlaufstelle für meine neugierigen Fragen zu spielen... :)


Am Ende waren aber immer noch rund 990 Testkörper aktiv, also ohne Kollision oder Runaway.

Okay. Weisst du eigentlich, was mehr Rechenaufwand benötigt? Die wenigen massiven Teile oder die vielen massenlosen? Testen könnte man das ja, in dem man mal einen Run ohne massive, einen ohne masselose rechnet und dann die Zeiten vergleicht. Das könnte uns einen Hinweis darauf geben, worauf wir uns am ehesten zuerst fokussieren. Wenn eines der beiden Szenerien sehr viel schneller ist als das andere, können wir z.B. (das "massive") mal für einige Millionen Jahre laufen lassen, oder beim anderen (das "masselose") die Anzahl deutlich Partikel erhöhen.


Die massiven Trümmerteile befinden sich nach 10000 Jahren im Bereich r=0.75 AU bis r=1.1 AU.

Das ist eine interessante Beobachtung, da sich in diesem Bereich ja eigentlich nur die Erde tummelt. So lange diese die Trümmerteile nicht ablenkt, dürften sie früher oder später mit ihr kollidieren.

Bernhard
04.01.2013, 12:18
Okay, das ist mir im Moment etwas viel Aufwand, gerade auch, weil am Dienstag eine Abstract-Deadline ansteht. Wir können das mal angehen, wenn ich mehr Zeit habe - sofern du natürlich bereit bis, bis dahin die Anlaufstelle für meine neugierigen Fragen zu spielen... :)
Das können wir gerne so machen. Linux hat den großen Vorteil, dass LaTeX "ruckzuck" installiert ist und über die Konsole sehr leicht zu bedienen ist. Zusammen mit einem besseren Editor wie Kate kann man damit recht schnell professionelle pdfs erstellen. Die Compilerauswahl (inklusive Fortran) ist auch nicht zu verachten.


Okay. Weisst du eigentlich, was mehr Rechenaufwand benötigt? Die wenigen massiven Teile oder die vielen massenlosen? Testen könnte man das ja, in dem man mal einen Run ohne massive, einen ohne masselose rechnet und dann die Zeiten vergleicht. Das könnte uns einen Hinweis darauf geben, worauf wir uns am ehesten zuerst fokussieren. Wenn eines der beiden Szenerien sehr viel schneller ist als das andere, können wir z.B. (das "massive") mal für einige Millionen Jahre laufen lassen, oder beim anderen (das "masselose") die Anzahl deutlich Partikel erhöhen.
Die Rechenzeit erhöhen eher die vielen masselosen Testkörper. Man darf nicht vergessen, dass bei denen diese close encounters berechnet werden. Das Logging der Encounters hat bei 1000 Jahren und 1000 Teilchen bereits knapp 100MB! Eine Berechnung der Bahnen der fünf massiven Trümmerteile über mehrere Millionen Jahre ist leicht machbar. Ich werde das gleich mal für 10 Mio. Jahre laufen lassen.


Das ist eine interessante Beobachtung, da sich in diesem Bereich ja eigentlich nur die Erde tummelt. So lange diese die Trümmerteile nicht ablenkt, dürften sie früher oder später mit ihr kollidieren.
Momentan gehe ich davon aus, dass die massiven Trümmer über lange Zeiten zu nahen und fernen Erdbahnkreuzern werden. Mal sehen was SyMBA dazu sagt.

Bynaus
04.01.2013, 14:19
Eine Berechnung der Bahnen der fünf massiven Trümmerteile über mehrere Millionen Jahre ist dagegen der reinste Witz und recht leicht machbar (d.h. es interessiert mich und ich werde das in den nächsten Tagen so laufen lassen). Hier könnten sogar Rechnungen über Milliarden Jahre machbar sein. Ich kann das voraussichtlich heute abend ansehen.

Sehr schön. Sollte sich zeigen, dass sie alle (oder fast alle) mit der Erde kollidieren, wäre das prinzipiell eine publikationsfähige Entdeckung. Aber ich will an dieser Stelle nicht zuviel versprechen, wir müssten uns ganz genau ansehen, was alles eingeflossen ist und evtl. eine professionell auf diesem Gebiet arbeitende Person beziehen.

Zu den Anfangsparametern einer solchen Simulation: Ich würde vorschlagen, mit folgenden Trümmergrössen (in Erdmassen) zu starten:

1 x 0.02
2 x 0.01
4 x 0.005
8 x 0.0025
16 x 0.00125

Das gibt nämlich eine Gesamtmasse von 0.1 Erdmassen = 1 Marsmasse, in etwa das, was bei unseren Simulationen entkommt, und die Massen sind in etwa nach einer typischen Fragmentierungsverteilung (f~ax^-1) verteilt. 31 Körper sollten sich dann relativ fix simulieren lassen, über eine Zeit von 100 Mio Jahren dürfte ausreichend sein (ausser es stellt sich heraus, dass die meisten dann noch immer da sind - dann müsste man noch etwas länger integrieren).

Bernhard
04.01.2013, 15:38
Sehr schön. Nur her mit den Modellparametern :) !

Die Simulation über 10 Mio. Jahre mit den 5 Trümmern ist mittlerweile bei 94% (ein Faktor 1000 bläst die Rechenzeit doch noch mal ganz schön auf) und es ergeben sich inzwischen die folgenden Resultate:

1) Nach 1.7 Mio. Jahren verbindet sich der schwerste Teil (1 Mondmasse) mit einem der leichteren Trümmer (0.1 Mondmassen)
2) Nach 2 Mio. Jahren kollidiert das verbundene Paket von 1) mit Merkur
3) Nach 5.1 Mio Jahren kollidiert ein weiteres Fragment mit 0.1 Mondmassen mit der Venus
4) Nach 6.5 Mio Jahren kollidiert ein weiteres Fragment mit 0.1 Mondmassen mit der Venus
5) Nach 8.9 Mio Jahren kollidiert ein weiteres Fragment mit 0.1 Mondmassen mit der Venus

EDIT: Die Simulation ist jetzt fertig. Keine weiteren Änderungen. Aus den Erdkollisionen ist leider nichts geworden.

Bynaus
04.01.2013, 16:11
Die arme Venus... :) (und Merkur: gemessen daran, dass er gerademal 4.5 Mondmassen hat, ist ein Treffer von einem 1.1-Mondmassen-Trümmerteil ein heftiges Ereignis...) Aber spannendes Resultat! Mal schauen, was die Simulation mit mehr Trümmern bringt. Wenn das ganze qualitativ reproduzierbar ist, wirds erst richtig interessant.

Bernhard
04.01.2013, 16:13
Hallo Bynaus,

die Simulation über 10000 Jahre hat uns leider ein wenig "genarrt". Scheinbar driften die massiven Trümmer also nur sehr langsam von der Erde weg.

Es gibt allerdings noch einen Wert mit dem man ein wenig herumspielen kann und zwar mit den Startbedingungen. Die massiven Trümmer starten ja per Vorgabe in einem recht engen Winkelbereich (+/- 5°) innerhalb der Ekliptik. Ich werde die 10 Mio. Jahre Simulation also nochmal laufen lassen, allerdings mit der entgegengesetzten Richtung innerhalb der Ekliptik für die massiven Trümmer.
MfG

Bynaus
04.01.2013, 16:14
die Simulation über 10000 Jahre hat uns leider ein wenig "genarrt".

Was meinst du damit genau?

Bernhard
04.01.2013, 16:17
Mal schauen, was die Simulation mit mehr Trümmern bringt.
Das wäre dann eine Aufgabe frühestens für das Wochenende. Ich werde da aber auch erst mal mit 10 Mio. Jahren starten. Bei 100 Mio. Jahren ist mein Rechner für mindestens 30 Stunden auf Linux festgelegt. Das gefällt mir nur bedingt ist zur Not aber schon mal machbar.

Bernhard
04.01.2013, 16:18
Was meinst du damit genau?
Bitte diesen Spruch nicht weiter ernst nehmen. genarrt steht für "in die Irre geführt".

Bynaus
04.01.2013, 16:29
Bei 100 Mio. Jahren ist mein Rechner für mindestens 30 Stunden auf Linux festgelegt.

Okay. Vielleicht wäre es eine Idee, das Programm so zu gestalten, dass man es unterbrechen / zwischenspeichern kann? Dann könnte man jeweils in der Nacht rechnen lassen. Oder lass es fürs Erste nur 30 Mio Jahre oder so laufen, das reicht evtl. auch.


Bitte diesen Spruch nicht weiter ernst nehmen. genarrt steht für "in die Irre geführt".

Ja, das dachte ich mir, aber ich meine: inwiefern genau hat uns die Simulation in die Irre geführt / genarrt?

Bernhard
04.01.2013, 16:35
Ja, das dachte ich mir, aber ich meine: inwiefern genau hat uns die Simulation in die Irre geführt / genarrt?
Nach 10000 Jahren sah es tatsächlich so aus, als würden sich die massiven Trümmer in der Erdbahn oder deren Nähe ansammeln. Erst die längere Simulation hat gezeigt, dass die massiven Trümmer doch weiter im Sonnensystem umherwandern.

Bynaus
04.01.2013, 16:45
Ach so - ja, eigentlich logisch, dass du das gemeint haben musst. :) Sorry.

Vermutlich verlieren die Trümmer bei jeder Begegnung etwas Bahnenergie (bzw., tauschen sie mit dem Planeten aus, dem sie begegnen), was sie im Generellen in Richtung Sonne wandern lässt.

Bernhard
04.01.2013, 16:53
Okay. Vielleicht wäre es eine Idee, das Programm so zu gestalten, dass man es unterbrechen / zwischenspeichern kann?
Sehr gute Idee. Die Ausgaben des Programms kann man nämlich mit nur minimalen Änderungen wieder als Eingabedateien verwenden. Der Programmablauf kann damit ohne Probleme portioniert werden.

Die neue Simu mit der entgegengesetzten Richtung für die 5 massiven Trümmer habe ich gerade gestartet. In etwa 3 Stunden sollte es dann neue Ergebnisse geben.

Die neuen Parameter kommen dann als nächstes dran.
MfG

Bernhard
04.01.2013, 16:54
Vermutlich verlieren die Trümmer bei jeder Begegnung etwas Bahnenergie (bzw., tauschen sie mit dem Planeten aus, dem sie begegnen), was sie im Generellen in Richtung Sonne wandern lässt.
Klar und eben von diesen Begegnungen gibt es laut Programmablauf ziemlich viele.

EDIT: Die neue Simu hat gerade neue Meldungen ausgegeben. Nach 150.000 Jahren haben bereits zwei der leichteren Trümmer das Sonnensystem (500 AU) verlassen.

Bynaus
04.01.2013, 17:19
Wahrscheinlich müssen wir mit der "Trümmerauswurfrichtung" ohnehin irgendwann durch die 360° rotieren. Wir haben nämlich keine Ahnung, aus welcher Richtung der Impaktor gekommen ist (und entsprechend, in welche Richtung die Trümmer davonflogen).

Bernhard
04.01.2013, 19:40
Hallo Bynaus,

mit den modifizierten Startbedingungen ergibt sich

1) Ein leichtes Trümmerteil (0.1 Mondmasse) verlässt bei t=20.000 das Sonnensystem
2) Ein leichtes Trümmerteil verlässt bei t=130.000 das Sonnensystem
3) Ein leichtes Trümmerteil verlässt bei t=3.3 Mio. Jahre das Sonnensystem
4) Ein leichtes Trümmerteil verlässt bei t=4.2 Mio. Jahre das Sonnensystem
5) Das schwere Trümmerteil (1 Mondmasse) befindet sich bei r=1.35 AU, also ziemlich genau zwischen den Bahnen von Erde und Mars.
MfG

Bernhard
04.01.2013, 19:57
Hallo Bynaus,

ausgehend von den neuen Daten stellt sich mir eine eher grundlegende Frage. Warum gehst Du (oder geht ihr) eigentlich davon aus, dass die Differenzgeschwindigkeit zwischen Theia und der Protoerde so hoch war, dass die Trümmerteile auf mehr als 11 km/s beschleunigt werden? Falls Theia in etwa so schnell unterwegs war wie die Protoerde, hätten die Trümmerteile eine wesentlich geringere Startgeschwindigkeit und könnten damit viel leichter den Mond bilden.
MfG

Bynaus
04.01.2013, 20:53
Zunächst einmal, zur Erinnerung: es geht ja hier nicht um die Bildung des Mondes. Der bildet sich in der Zwischenzeit (in ca. 100-1000 Jahren) schon aus der Trümmerscheibe um die Erde, die wir hier gar nicht simulieren. In diesem Projekt geht es nur um den Teil der Trümmer, der aus dem Schwerefeld der Erde entkommt: was geschieht damit?

Das Problem mit dem klassischen Giant Impact ist, dass der Mond sich vorwiegend aus Impaktormaterial bildet - aber der Mond ist dafür der Erde geochemisch viel zu ähnlich. Also sucht man, schon seit Jahren, nach Szenarien, bei denen sich ein genügend grosser Mond mit genügend hohem Drehimpuls bilden kann, bei dem ein höherer Anteil aus dem Erdmantel kommt. Am besten wäre ca. 80-90% Mantelgestein, da wäre die Zusammensetzung von Mond und Erde identisch, egal wie geochemisch verschieden Erde und Theia waren. In unserem Szenario kommt man auf höhere Mantelbeiträge, wenn Theia einiges schneller ist als bisher angenommen - die Kollisionsgeschwindigkeit beträgt dabei 1.4 mal die gegenseitige Fluchtgeschwindigkeit (also ca. 1.4 * 11 km/s).

Die Idee dahinter ist, dass wenn die Trümmer wieder mit der Erde kollidieren, die geochemische Ähnlichkeit zwischen Erde und Mond grösser würde (denn die Trümmer sind Theia-Material, fügen wir davon zur Erde hinzu, verringert sich der Unterschied zum Theia-ähnlicheren Mond).

Bernhard
04.01.2013, 22:51
Die Idee dahinter ist, dass wenn die Trümmer wieder mit der Erde kollidieren, die geochemische Ähnlichkeit zwischen Erde und Mond grösser würde (denn die Trümmer sind Theia-Material, fügen wir davon zur Erde hinzu, verringert sich der Unterschied zum Theia-ähnlicheren Mond).
OK. Das klingt ganz vernünftig. Ich bereite dann also die Simulation mit 31 Trümmerteilen vor. Die könnten dann ja vielleicht mit einer Verteilung von 180° innerhalb der Ekliptik und +/- 20° in theta-Richtung (s. Kugelkoordinaten) starten, was die statistische Auswertung erleichtert?

Bynaus
04.01.2013, 23:07
Die könnten dann ja vielleicht mit einer Verteilung von 180° innerhalb der Ekliptik und +/- 20° in theta-Richtung (s. Kugelkoordinaten) starten, was die statistische Auswertung erleichtert?

Ich würde den engen "Trümmerstrahl" vorerst lieber beibehalten, das ist dynamisch realistischer.
Langfristig werden wir einfach den Trümmerstrahl "rotieren" lassen müssen.

Bernhard
04.01.2013, 23:42
Ich würde den engen "Trümmerstrahl" vorerst lieber beibehalten, das ist dynamisch realistischer.
Ok.

Langfristig werden wir einfach den Trümmerstrahl "rotieren" lassen müssen.
Puh! Dir ist hoffentlich klar, dass das im Prinzip auf mehrere Wochen Rechenzeit kommt. Habt Ihr an der Uni nicht irgendwelche UNIX-Maschinen, die so etwas im Hintergrund laufen lassen könnten?

Bynaus
04.01.2013, 23:46
Puh! Dir ist hoffentlich klar, dass das im Prinzip auf mehrere Wochen Rechenzeit kommt. Habt Ihr an der Uni nicht irgendwelche UNIX-Maschinen, die so etwas im Hintergrund laufen lassen könnten?

Ja, das sehe ich ein. Ich müsste das abklären, evtl. kann man das in Bern (dort simulieren sie ja Kollisionen und solche Dinge), allerdings weiss ich nicht, wie das gelöst wird, wenn man von aussen kommt.

Aber wenn das Programm zwischenspeichern kann, könnte man das auch mit interessierten Usern hier im Forum versuchen?
Aber schauen wir erst mal, was bei diesen ersten Simulationen so rauskommt, bis wir wirklich eine derart systematische Studie planen.

Bernhard
05.01.2013, 10:18
Guten morgen Bynaus,

ich habe die Ausgabefunktion für die Planeten inzwischen so umgebaut, dass man den Programmablauf jetzt wirklich unterbrechen kann. Das war noch nicht komplett umgesetzt. Dann habe ich eine Simulation über 1 Mio. Jahre und Schrittweite 8 Tage gestartet. Rechenzeit ca. 2.5 h mit den folgenden Ergebnissen

1) 4 der leichteren Trümmerteile aus den 4er, 8er und 16er Blocks verbinden sich innerhalb der ersten zehn Jahre
2) Nach 430.000 Jahren kollidiert einer dieser zwei "Compound"-Trümmer mit Merkur
3) Nach 780.000 Jahren kollidiert ein Trümmerteil aus dem 2er Block (0.01 Erdmassen) mit der Erde ("Ja/Yes").

Als Startrichtung habe ich die interessantere der beiden bereits verwendeten genommen.

Gestern abend hatte ich die gleichen Startbedingungen auch mal mit einer Schrittweite von einem Tag gestartet. Ergebnis 1 gab es dabei auch, allerdings bei etwas anderen Zeiten, aber auch innerhalb der ersten zwölf Jahre. Ich habe diese Simulation dann aber abgebrochen, weil mir der Programmablauf zu langsam erschien.

Bernhard
05.01.2013, 13:55
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
05.01.2013, 14:59
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
05.01.2013, 17:22
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
05.01.2013, 18:12
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
05.01.2013, 18:54
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
05.01.2013, 21:21
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
05.01.2013, 22:01
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!

Laudian
05.01.2013, 22:42
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
06.01.2013, 09:39
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
06.01.2013, 12:17
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.

Bernhard
06.01.2013, 17:49
Ich hab dir mal meine Kontaktdaten per PN geschrieben.
"Sie haben eine neue Nachricht" ;).

Laudian
06.01.2013, 22:40
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
06.01.2013, 23:32
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
06.01.2013, 23:40
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
07.01.2013, 06:58
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
07.01.2013, 17:49
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
09.01.2013, 20:22
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
09.01.2013, 21:02
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
10.01.2013, 09:31
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
10.01.2013, 12:07
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.

Bynaus
11.01.2013, 17:56
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.

Sehr schön. Wie sieht es denn mittlerweile aus? Ich bin gespannt zu erfahren, was am Ende des ersten "langen" Runs herausschaut...

Bernhard
11.01.2013, 19:43
Hallo Bynaus,

ich habe von Laudian aktuell die Ergebnisse von zwei Berechnungen bekommen. Jede Einzelrechnung geht von 0 bis 20 Mio. Jahre. Die Rechnungen selbst unterscheiden sich durch den Startwinkel der massiven Trümmer. Die Startwinkel der Trümmer liegen dabei im Mittel um 10° auseinander. Die Trümmer starten bei Rechnung 1 also in eine leicht unterschiedliche Richtung als bei Rechnung 3.

Das Protokoll für Rechnung 1 ohne die exakten Zeiten lautet:

Merging particles 18 and 22
Merging particles 10 and 16
Merging particles 2 and 10
Merging particles 4 and 6
Merging particles 3 and 26
Merging particles 4 and 21
Merging particles 3 and 5
Merging particles 4 and 25
Merging particles 3 and 33
Particle 17 too close to Sun
Particle 30 too far from Sun
Particle 34 too far from Sun
Merging particles 4 and 8
Merging particles 3 and 27
Particle 7 too far from Sun
Merging particles 3 and 13
Merging particles 3 and 29
Particle 15 too far from Sun
Merging particles 12 and 24
Merging particles 3 and 9
Particle 20 too far from Sun

Das Protokoll für Rechnung 2 hat aktuell noch keine konkreten Ergebnisse, weil dort die Rechenzeit zu hoch war. Laudian hat aber mittlerweile die reduzierten Startbedingungen von mir bekommen.

Das Protokoll für Rechnung 3 ohne die exakten Zeiten lautet:

Merging particles 5 and 28
Merging particles 18 and 21
Merging particles 4 and 5
Merging particles 35 and 30
Merging particles 4 and 18
Merging particles 4 and 8
Merging particles 3 and 6
Merging particles 10 and 20
Merging particles 27 and 23
Merging particles 3 and 26
Merging particles 3 and 24
Particle 33 too far from Sun
Merging particles 3 and 11
Merging particles 3 and 7
Merging particles 4 and 32
Particle 29 too far from Sun
Merging particles 2 and 10
Merging particles 3 and 17
Particle 15 too far from Sun
Particle 14 too close to Sun
Particle 34 too far from Sun
Merging particles 3 and 22

Die Planeten sind dabei wie folgt durchnummeriert:

2: Merkur,
3: Venus,
4: Erde,
5: Trümmergruppe 1 (schwerstes Stück mit 0.02 Erdmassen) ,
6-7: Trümmergruppe 2 (2 Stück)
8-11: Trümmergruppe 3 (4 Stück)
12-19: Trümmergruppe 4 (8 Stück)
20-35: Trümmergruppe 5 (16 Stück)
36: Mars
37: Jupiter
38: Saturn
39: Uranus
40: Neptun

Bei beiden Rechnungen erhält die Erde also 4 Treffer und die Venus 7 Treffer.

Am Wochenende bleibt das "Rechenzentrum" voraussichtlich geschlossen. Weitere Ergebnisse gibt es also frühestens nächste Woche :) .

Bernhard
12.01.2013, 08:18
Hier die Fortsetzung der Protokolle:

Rechnung 1 wird bis 32 Mio. Jahre wie folgt fortgesetzt:

Merging particles 3 and 35
Merging particles 2 and 19


Rechnung 3 wird bis 32 Mio. Jahre wie folgt fortgesetzt:

Merging particles 4 and 35
Merging particles 4 and 13
Merging particles 2 and 12
Particle 27 too far from Sun

Zusätzlich gibt es jetzt Ergebnisse bei Rechnung 5. Diese wurde bisher bis 6 Mio. Jahre gerechnet:

Merging particles 5 and 34
Merging particles 5 and 28
Merging particles 7 and 10
Merging particles 3 and 27
Merging particles 4 and 5 (Hier treffen also insgesamt gleich drei Trümmerteile inklusive dem schwersten Teil auf der Erde ein)
Merging particles 3 and 22
Merging particles 4 and 17

Bynaus
13.01.2013, 10:05
Sehr schön! So wie es aus Rechnung 1 und 3 scheint, gewinnen Venus / Erde etwa 2-4% ihrer Masse aus diesen Theia-Trümmern (in den ersten 32 Mio Jahren), Merkur eher mehr (10-20% - interessantes Ergebnis...). Ich kann mal schauen, welche Auswirkungen das auf die Geochemie hat.

Welche Parameter hast du eigentlich für "zu nahe an der Sonne" und "zu weit weg" festgelegt? Bei ersterem könnte man den Roche-Radius nehmen. Für letzteres müsste man evtl. eher schauen, ob die Trümmer Fluchtgeschwindigkeit gegenüber der Sonne erreicht haben (dh, ob ihre Bahnenergie > 0 ist).

Auch eine Frage, die ich mir gestellt habe: Gut, jetzt sind wir bei 32 Mio. Aber natürlich fliegen da noch etliche der Trümmer herum. Wäre interessant zu sehen, wie lange diese im inneren Sonnensystem wirklich überleben. Wenn einige davon für 100 Mio Jahre oder gar für Milliarden Jahre verbleiben und erst dann mit Erde oder Venus zusammenkrachen, wäre das eine interessante Voraussage. Schliesslich sind auch die kleinsten Trümmer von 0.00125 Erdmassen (= ca. 10 x Ceres), die wir hier simulieren, bei Dichte 3, immer noch gigantische Objekte mit mehr als 800 km Radius!!! Ich denke nicht, dass die Erde sehr spät in ihrer Geschichte eine solche Kollision erlebt hat. Würden wir finden, dass praktisch alle Simulationen noch über das Archaikum hinaus solche tödlichen Bomben enthalten, wäre das ein Hinweis dafür, dass unser "Hit-and-run" Szenario des Giant Impacts der Wirklichkeit nicht sehr nahe kommen kann.

EDIT: PS: Ist die 16er Gruppe jetzt wieder drin? Anhand der Nummern sieht das für mich ganz so aus? Dann ist es doch kein Problem mehr - oder habt ihr jetzt einfach so lange gerechnet?

Bernhard
13.01.2013, 19:59
Welche Parameter hast du eigentlich für "zu nahe an der Sonne" und "zu weit weg" festgelegt?
Das sind aktuell ziemlich triviale Werte, um die entsprechenden Features überhaupt zu nutzen. Mindestabstand = Sonnenradius und Maximalabstand = 500 AU


Bei ersterem könnte man den Roche-Radius nehmen.
OK. Das wäre dann der Roche-Radius für starre Körper (?) und da wären wir bei einer Sache, die bisher noch nicht besprochen wurde. Wie groß ist eigentlich die Dichte der Trümmer. Ich habe nämlich einfach die Dichte der heutigen Erde bisher dafür verwendet :o . Für Dichte 3 müsste man dann eventuell wieder von vorne anfangen?


Für letzteres müsste man evtl. eher schauen, ob die Trümmer Fluchtgeschwindigkeit gegenüber der Sonne erreicht haben (dh, ob ihre Bahnenergie > 0 ist).
Dieses Feature müsste erst einprogrammiert werden. Keine Ahnung, ob ich dafür nächste Woche die nötige Zeit finde.


EDIT: PS: Ist die 16er Gruppe jetzt wieder drin? Anhand der Nummern sieht das für mich ganz so aus? Dann ist es doch kein Problem mehr - oder habt ihr jetzt einfach so lange gerechnet?
Es gibt insgesamt 72 Startbedinungen und dementsprechend 72 Rechnungen bin 100 Mio. Jahre. Bei Rechnung 1 und 3 sind die Startbedinungen (vermutlich) per Zufall(sgenerator) so günstig, dass man das inklusive 16er Gruppe rechnen. Bei Rechnung 2 und 4 muss man mit den reduzierten Startbedingungen (ohne die 16er Gruppe) starten, um nicht unnötig lange rechnen zu müssen. Laudian rechnet aktuell Rechnung 1, 3 und 5 also alle mit der 16er Gruppe. Ich habe bisher die Geschwindigkeiten der ersten 30 Startbedingungen getestet, um die entsprechenden Rechnungen vorzubereiten.


Auch eine Frage, die ich mir gestellt habe: Gut, jetzt sind wir bei 32 Mio. Aber natürlich fliegen da noch etliche der Trümmer herum. Wäre interessant zu sehen, wie lange diese im inneren Sonnensystem wirklich überleben. Wenn einige davon für 100 Mio Jahre oder gar für Milliarden Jahre verbleiben und erst dann mit Erde oder Venus zusammenkrachen, wäre das eine interessante Voraussage. Schliesslich sind auch die kleinsten Trümmer von 0.00125 Erdmassen (= ca. 10 x Ceres), die wir hier simulieren, bei Dichte 3, immer noch gigantische Objekte mit mehr als 800 km Radius!!! Ich denke nicht, dass die Erde sehr spät in ihrer Geschichte eine solche Kollision erlebt hat. Würden wir finden, dass praktisch alle Simulationen noch über das Archaikum hinaus solche tödlichen Bomben enthalten, wäre das ein Hinweis dafür, dass unser "Hit-and-run" Szenario des Giant Impacts der Wirklichkeit nicht sehr nahe kommen kann.
Diese Fragen erfordern eine tiefer gehende Analyse. Eventuell muss auch hier der swifter-Code erweitert werden und das muss erst mal ein wenig warten von meiner Seite aus.

Bynaus
14.01.2013, 09:24
Das sind aktuell ziemlich triviale Werte, um die entsprechenden Features überhaupt zu nutzen. Mindestabstand = Sonnenradius und Maximalabstand = 500 AU

Das klingt sehr vernünftig. Gemessen daran, dass bisher nur ein Bruchteil der Trümmer wirklich das Sonnensystem verlassen, kann man das vielleicht auch so belassen. Sollte sich aber langfristig herausstellen, dass dies die meisten (oder zumindest ein bedeutender Bruchteil der) Trümmer tun, müsste man das evtl. modifizieren, also entweder an jedem Punkt berechnen, ob sie mit Fluchtgeschwindigkeit fliegen (und wenn ja, dann entfernt man sie jenseits von ca. 5 AU aus der Simulation), oder aber man setzt den Maximalabstand hinauf, so dass dieser nur erreicht werden kann, wenn die Trümmer im Rahmen der Unsicherheit praktisch Fluchtgeschwindigkeit haben müssen, um diese Höhe über der Sonne zu erreichen. Aber wie gesagt, im Rahmen dessen, was wir bisher gesehen haben, kann das noch warten.


Wie groß ist eigentlich die Dichte der Trümmer. Ich habe nämlich einfach die Dichte der heutigen Erde bisher dafür verwendet

Uh oh. Das ist auch mein Fehler - daran hatte ich bisher noch gar nie gedacht... Diese Trümmer sind wohl vorwiegend Mantelgestein, und das hätte wohl eher eine Dichte von ca. 3, ähnlich wie Mond und Mars. Die Dichte der Erde ist nicht nur wegen des Kerns so hoch, sondern auch wegen der gravitativen Selbstkompression, die bei so kleinen Objekten praktisch wegfällt. Es kann durchaus sein, dass das einen Einfluss auf den Ausgang der Simulation hat, denn weniger dichte Körper sind gemessen an ihrem Hill-Radius grösser, werden also mehr Kollisionen erleben.

Ich würde sagen, wir sollten hier sofort umstellen (und, tut mir wirklich leid, nochmals von vorn beginnen). Auf der positiven Seite, wenn die Erde schon für Dichte 5.5 einige Prozent ihrer Masse aus diesen Trümmern gewinnt, dann sollte der Effekt für Dichte 3 etwas grösser sein. Anderseits nehmen wir ja bisher an, dass alle Kollisionen perfekte "Vereinigungen" der involvierten Materie darstellen, oder? (die Masse der vereinigten Trümmer wird gegenseitig addiert, nehme ich an?) Das könnte etwas überoptimistisch sein, denn bei jeder Kollision wird ein Teil der Materie wegfliegen.


Ich habe bisher die Geschwindigkeiten der ersten 30 Startbedingungen getestet, um die entsprechenden Rechnungen vorzubereiten.

Und was ist dabei rausgekommen? Es wäre seltsam, wenn das Phänomen der "langsamen Startbedingung" nur die ungraden Rechnungen betreffen würde...


Diese Fragen erfordern eine tiefer gehende Analyse. Eventuell muss auch hier der swifter-Code erweitert werden und das muss erst mal ein wenig warten von meiner Seite aus.

Inwiefern muss der Swifter-Code erweitert werden? Es geht ja im Prinzip nur um eine längerdauernde Integration.

Bernhard
14.01.2013, 10:10
und, tut mir wirklich leid, nochmals von vorn beginnen
Genau das wollte ich auch vorschlagen. Dieser Parameter ist für das untersuchte Modell viel zu wichtig, als das man da großzügig sein könnte. Auch von meiner Seite deswegen eine Entschuldigung an Laudian.


Und was ist dabei rausgekommen? Es wäre seltsam, wenn das Phänomen der "langsamen Startbedingung" nur die ungraden Rechnungen betreffen würde...
Die Abhängigkeit gerade/ungerade gibt es nur bei den ersten paar Werten. Es gibt auch einige Startbedingungen die mit mittlerer Geschwindigkeit laufen. Eine genaue Auswertung dieser Information möchte ich aber erst mal verschieben, weil auch hier der Dichteparameter eine Rolle spielt.

Ich werde als nächstes erst mal einen neuen Satz an Startbedingungen erstellen (2 mal 72 Dateien).

Bynaus
14.01.2013, 11:26
Auch von meiner Seite deswegen eine Entschuldigung an Laudian.

Solche Dinge sind (wissenschaftlicher) Alltag. Man kann nicht immer schon von vornherein an alles denken... Vielleicht gibt es noch andere Effekte, die wir übersehen haben, wo wir in ein paar Wochen, nach ein paar dutzend Runs, wieder einsehen, dass wir nochmals von vorn beginnen müssen. Damit muss man leben: zum Lernen gibts keine Abkürzung. :)

Wenn irgendwo Unsicherheiten oder Fragen auftauchen, dann können und sollten wir diese jederzeit hier im Forum diskutieren.

In diesem Sinne will ich die Gelegenheit nutzen, um noch ein paar Unklarheiten meinerseits zu beseitigen, bevor wir die neuen Runs starten:

1) Hab ich das mit dem "Trichter", in dem sich die Trümmer anfänglich befinden, richtig verstanden, dass dessen Achse in der Bahnebene der Erde liegt, und dass sein Öffnungswinkel (der Winkel zwischen zwei Geraden, die auf exakt entgegengesetzten Seiten seines Mantels liegen) 10° beträgt?
2) Ist es auch korrekt, dass der erste Run davon ausging, dass die Trümmer in Bewegungsrichtung der Erde (dh, die Achse des Trichters liegt tangential zur Erdbahn, mit dem offenen Ende in Bewegunsrichtung der Erde) weggeschleudert wurden, während in den späteren Runs jeweils um jeweils zusätzliche 5° von dieser tangentialen Richtung abgewichen wurde? Das also der 36. Run eine Kollision simulieren wird, bei der die Trümmer entgegen der Bewegungsrichtung der Erde weggeschleudert werden?
3) Wie genau werden die Trümmer innerhalb des Trichters verteilt? Einfach zufällig innerhalb der verfügbaren Raumkoordinaten? Wir sollten dann vielleicht auch mal verschiedene Runs mit gleichen Trichterrichtungen testen, aber verschiedenen Verteilungen der Trümmer innerhalb des Trichters. Wir wissen sonst nicht, ob Unterschiede zwischen den Trichterrichtungen wirklich auf diese Richtung zurückzuführen sind, oder bloss auf die zufällige Position der Trümmer innerhalb des Trichters.
4) Warum sind es 2 mal 72 Dateien, die du vorbereiten musst? Sind es 2 Dateien pro Run?
5) Wenn zwei Trümmer kollidieren, was geschieht dann mit ihren Massen? Wenn also z.B. Trümmer 5 und 28 "mergen", wird dann das neue Trümmerteil 5 (?) eine Masse (und Grösse) haben, die der Summe der beiden Trümmer entspricht, oder wird Trümmer 28 einfach nur entfernt? Das dürfte, gerade bei vielen Kollisionen, eine wichtige Frage werden...
6) Wäre es allenfalls möglich, nach 1000 Jahren den Mond (der Erde) in die Simulation aufzunehmen? Man müsste seine Bahn im Verlauf der darauf folgenden Jahrmillionen langsam von der Erde entfernen (auf eine Art und Weise, die ich in der Literatur recherchieren müsste). Der Punkt ist eben, dass wenn die Theia-Trümmer so lange überleben, dass sie auch den Mond treffen können (das wussten wir ja eigentlich nicht von Anfang an), dann können sie die geochemischen Unterschiede zwischen Mond und Erde eben auch vergrössern (gerade weil der Mond so viel kleiner als die Erde ist, gemessen an der Grösse der Trümmer). Ich weiss dass das einen zusätzlichen Programmieraufwand erfordert, und ich will hier keinesfalls einen fortlaufenden Feature-Creep fördern, aber ich denke, Kollisionen mit dem Mond dürften ein Punkt sein, den ein Reviewer sicher hervorheben würde.

Bernhard
14.01.2013, 12:13
1) Hab ich das mit dem "Trichter", in dem sich die Trümmer anfänglich befinden, richtig verstanden, dass dessen Achse in der Bahnebene der Erde liegt, und dass sein Öffnungswinkel (der Winkel zwischen zwei Geraden, die auf exakt entgegengesetzten Seiten seines Mantels liegen) 10° beträgt?
Soweit korrekt. Der Öffnungswinkel beträgt allerdings nur 5°.


2) Ist es auch korrekt, dass der erste Run davon ausging, dass die Trümmer in Bewegungsrichtung der Erde (dh, die Achse des Trichters liegt tangential zur Erdbahn, mit dem offenen Ende in Bewegunsrichtung der Erde) weggeschleudert wurden, während in den späteren Runs jeweils um jeweils zusätzliche 5° von dieser tangentialen Richtung abgewichen wurde? Das also der 36. Run eine Kollision simulieren wird, bei der die Trümmer entgegen der Bewegungsrichtung der Erde weggeschleudert werden?
Nein. Ich hatte da einen rein zufälligen Wert gewählt und weiß auch gar nicht, welchen Winkel das mit der Bewegungsrichtung der Erde impliziert.

Ich werde das dann so anpassen, dass die Trümmer bei dem ersten Run tangential zur Bewegungsrichtung der Erde (+/- 2.5°) starten.


3) Wie genau werden die Trümmer innerhalb des Trichters verteilt? Einfach zufällig innerhalb der verfügbaren Raumkoordinaten?
Genau.


Wir sollten dann vielleicht auch mal verschiedene Runs mit gleichen Trichterrichtungen testen, aber verschiedenen Verteilungen der Trümmer innerhalb des Trichters. Wir wissen sonst nicht, ob Unterschiede zwischen den Trichterrichtungen wirklich auf diese Richtung zurückzuführen sind, oder bloss auf die zufällige Position der Trümmer innerhalb des Trichters.
Ich brauche dazu die Startbedingungen nur zweimal ausgeben, da der Zufallsgenerator momentan so eingestellt ist, dass bei jeder Berechnung immer neue Zufallszahlen erzeugt werden.


4) Warum sind es 2 mal 72 Dateien, die du vorbereiten musst? Sind es 2 Dateien pro Run?
Es sind 2 Dateien pro Run, also einmal mit der 16er Gruppe und einmal ohne.


5) Wenn zwei Trümmer kollidieren, was geschieht dann mit ihren Massen? Wenn also z.B. Trümmer 5 und 28 "mergen", wird dann das neue Trümmerteil 5 (?) eine Masse (und Grösse) haben, die der Summe der beiden Trümmer entspricht, oder wird Trümmer 28 einfach nur entfernt? Das dürfte, gerade bei vielen Kollisionen, eine wichtige Frage werden...
Ich habe aktuell nur gesehen, dass nach dem mergen die Masse und auch der Radius verändert wird. Im Deinem Beispiel wird also die Masse und der Radius von Teil 5 erhöht und Teil 28 gelöscht. Ich vermute, dass die Massen addiert werden und der Radius über die Dichte erhöht wird. Den zugehörigen Code habe ich zwar noch nicht explizit gesehen, aber ich kann mir eigentlich nicht vorstellen, dass die swifter-Autoren das anders gemacht haben.


6) Wäre es allenfalls möglich, nach 1000 Jahren den Mond (der Erde) in die Simulation aufzunehmen? Man müsste seine Bahn im Verlauf der darauf folgenden Jahrmillionen langsam von der Erde entfernen (auf eine Art und Weise, die ich in der Literatur recherchieren müsste). Der Punkt ist eben, dass wenn die Theia-Trümmer so lange überleben, dass sie auch den Mond treffen können (das wussten wir ja eigentlich nicht von Anfang an), dann können sie die geochemischen Unterschiede zwischen Mond und Erde eben auch vergrössern (gerade weil der Mond so viel kleiner als die Erde ist, gemessen an der Grösse der Trümmer). Ich weiss dass das einen zusätzlichen Programmieraufwand erfordert, und ich will hier keinesfalls einen fortlaufenden Feature-Creep fördern, aber ich denke, Kollisionen mit dem Mond dürften ein Punkt sein, den ein Reviewer sicher hervorheben würde.
Wenn das Programm schon mergen kann, sollte so etwas zumindest prinzipiell machbar sein. Das wird aber sicher etwas oder auch etwas länger dauern. Voraussichtlich eher eine Aufgabe, die über den Januar hinausgehen wird.

Bynaus
14.01.2013, 13:15
Der Öffnungswinkel beträgt allerdings nur 5°.

Umso besser.


Ich werde das dann so anpassen, dass die Trümmer bei dem ersten Run tangential zur Bewegungsrichtung der Erde (+/- 2.5°) starten.

Gut. Es spielt natürlich keine grosse Rolle, wenn wir die Richtungen eh systematisch durchackern. Aber ich bin gespannt, welche Auswirkungen das hat.


Ich brauche dazu die Startbedingungen nur zweimal ausgeben, da der Zufallsgenerator momentan so eingestellt ist, dass bei jeder Berechnung immer neue Zufallszahlen erzeugt werden.

Sehr schön. Dann sollten wir das zumindest einige Male (10, 20?) mit konstanter Trichterrichtung testen, um sicher zu gehen, dass wir die Auswirkungen dieser Verteilung verstehen (oder um - allenfalls - zu zeigen, dass sie keine sehr grosse Rolle spielt).


Ich habe aktuell nur gesehen, dass nach dem mergen die Masse und auch der Radius verändert wird. Im Deinem Beispiel wird also die Masse und der Radius von Teil 5 erhöht und Teil 28 gelöscht. Ich vermute, dass die Massen addiert werden und der Radius über die Dichte erhöht wird. Den zugehörigen Code habe ich zwar noch nicht explizit gesehen, aber ich kann mir eigentlich nicht vorstellen, dass die swifter-Autoren das anders gemacht haben.

Ja, das ist anzunehmen. Das scheint also vernünftig gelöst zu sein.


Wenn das Programm schon mergen kann, sollte so etwas zumindest prinzipiell machbar sein. Das wird aber sicher etwas oder auch etwas länger dauern. Voraussichtlich eher eine Aufgabe, die über den Januar hinausgehen wird.

Okay. Nun, wenn wir wissen, dass wir das ohnehin einbauen wollen / müssen, dann lohnt es sich, mit den vielen Runs, bei denen die Ausichtung des Trichters variiert, zu warten, bis dieses Feature drin ist. In der Zwischenzeit könnte man die wiederholten Runs mit der stets variierenden zufälligen Verteilung der Trümmer innerhalb des stets gleich ausgerichteten Trichters rechnen - dort spielt der fehlende Mond keine so grosse Rolle, da wir ja nur das Ausmass der Variation des Simulationsverlaufes in Abhängigkeit der zufälligen, anfänglichen Verteilung der Trümmer simulieren wollen, ohne deshalb gleich Aussagen über die Trefferhäufigkeit auf Mond vs. Erde treffen zu wollen.

Bernhard
14.01.2013, 13:32
da wir ja nur das Ausmass der Variation des Simulationsverlaufes in Abhängigkeit der zufälligen, anfänglichen Verteilung der Trümmer simulieren wollen, ohne deshalb gleich Aussagen über die Trefferhäufigkeit auf Mond vs. Erde treffen zu wollen.
Man kann sich da jetzt schon überlegen, wie genau man das analysieren will. Dass die Anzahl der Treffer in der Reihenfolge Venus-Erde-Merkur-Mars geordnet ist sieht man eigentlich jetzt schon. Diese Reihenfolge sollte deswegen von der Verteilung innerhalb des Trichters unabhängig sein.

EDIT: Eine Frage zu dem Trichter: Soll dessen Symmetrieachse eigentlich genau in der Ekliptik liegen oder soll der besser an der aktuellen Tangente der Erdbahn ausgerichtet werden? Aktuell liegt diese Achse genau in der Ekliptik (z_Achse = 0).

EDIT_EDIT: Mir fällt gerade noch ein, dass der "Trichter" eigentlich eher eine Pyramide ist. Die projizierte Grundfläche ist rechteckig, weil beide Winkel (phi und theta) in einem bestimmten Winkelintervall liegen ;) .

Bynaus
14.01.2013, 13:55
Dass die Anzahl der Treffer in der Reihenfolge Venus-Erde-Merkur-Mars geordnet ist sieht man eigentlich jetzt schon.

Ja, wobei n=2 statistisch eben nicht sehr robust ist. An der Reihenfolge wird sich vielleicht nichts ändern, aber vielleicht an den absoluten Häufigkeiten? Ich denke auch nicht, dass das eine grosse Rolle spielt - aber wir wollen ja nicht annehmen, sondern zeigen. Und da kommen wir wohl nicht darum herum, diesen Aspekt zumindest zu beleuchten. Stell dir vor, wir finden dass z.B. in bestimmten Winkelrichtungen (des Trichters) sehr viel mehr Material auf die Erde zurückfällt als in anderen - wie zeigen wir, dass dies wirklich ein Effekt des Winkels ist und nicht der zufälligen Anfangsverteilung der Trümmer innerhalb des Trichters? Indem wir zeigen, dass dieser Effekt stärker ist als die Variation, die aufgrund der zufälligen Verteilung zu erwarten ist - und dafür müssen wir diese zufällige Verteilung zuerst einmal kennen.


EDIT: Eine Frage zu dem Trichter: Soll dessen Symmetrieachse eigentlich genau in der Ekliptik liegen oder soll der besser an der aktuellen Tangente der Erdbahn ausgerichtet werden? Aktuell liegt diese Achse genau in der Ekliptik (z_Achse = 0).

Ja, das hab ich mich auch gefragt. Evtl. könnte man ihn +-10° gegenüber der Ekliptik anstellen. Anderseits, je mehr Parameter wir reinnehmen, desto komplizierter wirds bzw. desto mehr Runs müssen wir durchführen, um allfällige systematische Effekte zu sehen. Vielleicht können wir fürs erste mal in der Ekliptik bleiben, und später noch zusätzliche "Kränze" mit angestellten Trichtern durchführen.

Bernhard
14.01.2013, 15:02
Stell dir vor, wir finden dass z.B. in bestimmten Winkelrichtungen (des Trichters) sehr viel mehr Material auf die Erde zurückfällt als in anderen - wie zeigen wir, dass dies wirklich ein Effekt des Winkels ist und nicht der zufälligen Anfangsverteilung der Trümmer innerhalb des Trichters? Indem wir zeigen, dass dieser Effekt stärker ist als die Variation, die aufgrund der zufälligen Verteilung zu erwarten ist - und dafür müssen wir diese zufällige Verteilung zuerst einmal kennen.
OK. Ich werde dann mal 20 Startdateien mit dem gleichen Trichter tangential zur Erdbahn und der Dichte 3 g/cm³ für die Trümmerteile vorbereiten und hoffen, dass Laudian weiterhin seinen Rechner für uns laufen läßt.

Bynaus
14.01.2013, 17:09
Ja, das klingt gut. Sobald ich wieder in Lund bin, kann ich mal beim Rechenzentrum (sofern es überhaupt ein solches gibt, oder sonst eine andere, allenfalls zugängliche Infrastruktur) vorbei, ich glaube, einfach so per E-Mail wäre das schwierig zu organisieren. Bis dahin finden sich vielleicht ein paar weitere freiwillige Helfer hier im Forum?

Bernhard
14.01.2013, 20:28
Hallo Bynaus,

die zwanzig neuen Startdateien sind mittlerweile erstellt und ich habe mir bei allen Dateien den Ablauf der ersten tausend Jahre angesehen. Dabei gab es kleinere Unterschiede beim Zusammenfügen der Trümmerteile (im Durchschnitt zwei Merges leichterer Teile) und bei einer Datei auch einen Treffer auf der Erde. Bei sieben Startdateien ist der Ablauf der Rechnung wieder so langsam, dass man hier die 16er Gruppe weglassen sollte.

Die alten Startbedingungen waren zufälligerweise gerade so gewählt, dass die Trümmer ziemlich genau (Abweichung 12,3°) entgegengesetzt zur Bewegung der Erde starten.
MfG

Bynaus
15.01.2013, 08:04
Bei sieben Startdateien ist der Ablauf der Rechnung wieder so langsam, dass man hier die 16er Gruppe weglassen sollte.

Wenn, dann müssten wir hier bei allen Runs die 16-er Gruppe weglassen, damit das irgendwie vergleichbar bleibt. Anderseits wollen wir ja die Ergebnisse für die anderen Runs (mit dem variablen Trichter) verwenden, und dort wollen wir die 16-er Gruppe ja nicht generell weglassen. Hm... Vielleicht könnten wir das so lösen: wir rechnen die 20 Runs, inklusive denjenigen, bei denen die Rechnung sehr langsam geht. Dann vergleichen wir die Ergebnisse: gewinnt die Erde im Schnitt deutlich mehr als 20% mehr (zusätzliche) Masse, wenn die 16-er Gruppe mitgerechnet wird? Wenn nicht, dann können wir die 16-er Gruppe viellleicht generell weglassen.

Oder aber, wir entscheiden uns gleich von Anfang an, die 16-er Gruppe wegzulassen. Vielleicht ist das für den Moment die beste Lösung. Wir haben ohnehin noch keine richtige Ahnung, wie die Ausgänge von den Parametern abhängen, also von der Richtung des Trichters, der zufälligen Verteilung der Trümmer innerhalb des Trichters, der Anfangstellung der Planeten (?) etc. Vielleicht wäre es, für diese "Pilotstudie", gar keine so schlechte Idee, die Dinge so einfach und schnell wie möglich zu halten.

Bernhard
15.01.2013, 09:05
Vielleicht wäre es, für diese "Pilotstudie", gar keine so schlechte Idee, die Dinge so einfach und schnell wie möglich zu halten.
Ich habe gestern noch die reduzierten Startbedingungen generiert und getestet wie schnell die laufen. Dabei habe ich festgestellt, dass es gar nicht reicht die 16er Gruppe wegzulassen. D.h. bei den reduzierten Startbedingungen waren ebenfalls Dateien dabei, deren Berechnung immer noch sehr langsam ablief. Um alle 20 Variationen der ersten Startbedingung zu rechnen, könnten/müssten wir also auch noch die 8er Gruppe weglassen.

Ich könnte also erst mal testen, wie lange ein Run ohne die 8er Gruppe dauert. Vielleicht kommt man bei diesen stark reduzierten Startbedingungen dann auch mit einem PC weiter.

EDIT: Ich kann natürlich auch so viele Startdateien berechnen, bis wir 20 Stück mit 16er Gruppe haben, die schnell genug berechenbar sind. Die Frage ist nur, ob man damit das Ergebnis nicht manipuliert.

Bynaus
16.01.2013, 12:14
Alternativ könnte man sich vielleicht auch mal ansehen, wie denn die Verteilung der Objekte in den "langsamen" Runs wirklich aussieht. Wenn diese rein zufällig ist (z.B. einfach davon abhängt, dass sich an bestimmten Stellen "Klumpen" bilden), könnten wir sonst auch einfach viele zufällige Startbedingungen setzen, die ersten paar 1000 (?) Jahre rechnen und nur dann zu längeren Zeiten weiterrechnen, wenn die Rechenzeit sich im "normalen" Bereich bewegt. Wir müssen evtl. zuerst einfach mal verstehen, warum diese Runs überhaupt so langsam werden, um einen (vertretbaren) Weg darum herum zu finden.

Bernhard
16.01.2013, 13:58
Wir müssen evtl. zuerst einfach mal verstehen, warum diese Runs überhaupt so langsam werden, um einen (vertretbaren) Weg darum herum zu finden.
Wie bereits schon festgestellt: Bei den langsamen Runs werden extrem viele close encounters gerechnet. Ich kann mir das momentan nur so erklären, dass in diesen Fällen Trümmer umeinander kreisen und dabei immer wieder einen close encounter auslösen. Swifter_symba generiert bei jedem Run eine Datei enc.dat, wo die encounters mitgeloggt werden. Bei den langsamen Runs kann man zusehen, wie die Megabytes in diese Datei fließen :rolleyes: .

EDIT: Für die Datei enc.dat gibt es auch ein mitgeliefertes Analyse-Werkzeug, mit dem man die Daten dieser Datei filtern und anzeigen lassen kann. Dabei sieht man dann auch, dass es eben paarweise die Trümmerteile sind, welche die vielen Einträge erzeugen.

Bynaus
16.01.2013, 15:01
Dann schlage ich folgendes vor: wir verteilen ca. 50 Koordinatenpunkte möglichst gleichmässig über das Volumen des Trichters, so dass sie möglichst weit voneinander entfernt sind. Dann weisen wir jedes Trümmerteil zufällig einem solchen Koordinatenpunkt zu (einige bleiben leer). Auf diese Weise verhindern wir, dass die Trümmer von Anfang an sehr nahe beieinander stehen.

Wie lang ist der Trichter eigentlich?

Kibo
16.01.2013, 15:48
Vorschlag: Deaktiviert doch mal die Loggingfunktion bei close encounters, oder schränkt sie ein. Vielleicht spart das schon genug Systemressourcen um die Berechnung einigermaßen schnell ablaufen zu lassen

Bynaus
16.01.2013, 16:05
Guter Vorschlag (denke ich)!

Bernhard
16.01.2013, 18:07
Dann schlage ich folgendes vor: wir verteilen ca. 50 Koordinatenpunkte möglichst gleichmässig über das Volumen des Trichters, so dass sie möglichst weit voneinander entfernt sind. Dann weisen wir jedes Trümmerteil zufällig einem solchen Koordinatenpunkt zu (einige bleiben leer). Auf diese Weise verhindern wir, dass die Trümmer von Anfang an sehr nahe beieinander stehen.
EDIT: Wenn so eine Auswahl der Startbedingungen in Ordnung ist, kann ich auch gleich noch mehr Startdateien generieren und die langsamen aussortieren. 20 schnelle Runs zu finden sollte kein größeres Problem sein. 13 habe ich ja schon.


Wie lang ist der Trichter eigentlich?
Ich hatte da 500 Tausend Kilometer gewählt.

Bernhard
16.01.2013, 18:09
Deaktiviert doch mal die Loggingfunktion bei close encounters, oder schränkt sie ein.
Gute Idee aber leider ohne merkliche Wirkung. Ich habe bei mir diese Funktion schon des längeren deaktiviert, aber der Zeitverlust entsteht bei der Berechnung der encounters. Die Ausgabe der Daten fällt nicht in's Gewicht.

Kibo
16.01.2013, 19:38
Ok, wenn diese Testkörper quasi sich gegenseitig eingefangen haben, bilden sie ja von aussen gesehen ein geschlossenes garvitativ gebundenes system. Man könnte ja sagen, wenn der eine Testkörper, den anderen 100 mal umrundet hat, werden die beiden Körper als einer betrachtet.
Was damit geschehen soll wenn dieser von anderen Körpern dann gestört wird ist dann wieder eine andere Frage

Bynaus
16.01.2013, 20:14
Wenn so eine Auswahl der Startbedingungen in Ordnung ist

Wir werden das einfach klar kommunizieren müssen und es wird, bis zu einem bestimmten Grad, ein Schwachpunkt sein. Aber wir haben einfach begrenzte Ressourcen. Wir werden allerdings nicht darum herum kommen zumindest ein paar "langsame" Runs zu rechnen, um zu zeigen, dass die Ergebnisse nicht drastisch verschieden sind.

Bernhard
17.01.2013, 11:17
Die 20 schnellen Startbedingungen habe ich mittlerweile erstellt.

Die Roche-Grenze brauchen wir übrigens nicht berücksichtigen, weil diese wegen der geringen Dichte der Sonne innerhalb der Sonne liegt.

Bynaus
17.01.2013, 14:27
Die 20 schnellen Startbedingungen habe ich mittlerweile erstellt.

Kannst du mir die Koordinaten der Trümmer in diesen 20 "schnellen" sowie in ein paar "langsamen" Runs zukommen lassen? Ich möchte mir das mal ansehen.


Die Roche-Grenze brauchen wir übrigens nicht berücksichtigen, weil diese wegen der geringen Dichte der Sonne innerhalb der Sonne liegt.

Danke dass du das überprüft hast. Dann wird wohl der Sonnenradius als Mindestabstand reichen.

Bernhard
17.01.2013, 16:52
Kannst du mir die Koordinaten der Trümmer in diesen 20 "schnellen" sowie in ein paar "langsamen" Runs zukommen lassen?
Ich habe 27 Startdateien (20 schnelle und 7 langsame) verschickt.

Bernhard
21.01.2013, 22:32
Hallo Bynaus,

ich habe heute nach einigen Tagen Pause die neuen Startbedingungen (eine zusätzliche "schnelle") verwendet. Die Trümmer starten jetzt also mit passender Dichte in tangentialer Richtung zur Erdbewegung. Die ersten 3 Mio. Jahre ergeben dabei die folgenden Ergebnisse:

1. Rechnung mit 1 Mio. Jahre

Merging particles 13 and 26 at time t = 11600.000000000000
Particle 15 too far from Sun at t = 5411776.0000000000
Particle 30 too far from Sun at t = 34661488.000000000
Particle 8 too far from Sun at t = 41953952.000000000
Merging particles 4 and 6 at time t = 48520608.000000000
Particle 25 too far from Sun at t = 50563952.000000000
Particle 29 too far from Sun at t = 72366024.000000000
Particle 32 too far from Sun at t = 77477376.000000000
Particle 10 too far from Sun at t = 105486464.00000000
Particle 20 too far from Sun at t = 127112072.00000000
Particle 19 too far from Sun at t = 140336184.00000000
Particle 12 too far from Sun at t = 179400576.00000000

Anschlussrechnung mit 10 Mio. Jahren

Particle 17 too far from Sun at t = 30985168.000000000
Particle 35 too far from Sun at t = 56108680.000000000
Particle 14 too far from Sun at t = 64913120.000000000
Particle 22 too far from Sun at t = 151790224.00000000
Particle 13 too far from Sun at t = 179769152.00000000
Particle 27 too far from Sun at t = 180003848.00000000
Particle 9 too far from Sun at t = 233828824.00000000
Merging particles 4 and 18 at time t = 341421944.000000000
Merging particles 3 and 31 at time t = 458916752.000000000
....

Die Zeiten sind jeweils in Tagen zu verstehen. Die Punkte sollen andeuten, dass die Rechnung mit 10 Mio. Jahren noch läuft.

Sollten sich auf die Schnelle keine weiteren Freiwilligen finden, möchte ich zumindest noch die Gegenrichtung zu dieser Startrichtung ansehen. Für systematische Auswertungen bräuchten wir entweder Unterstützung von einem Rechenzentrum oder Freiwillige.

Bynaus
21.01.2013, 23:57
Danke für das Schicken der Dateien, ich bin leider noch nicht dazu gekommen, mir das im Detail anzusehen, kommt aber noch.

Meine ich das nur, oder fliegen diese Trümmer bei einem tangentiellen Start fast alle aus dem Sonnensystem raus? Soweit ich mich erinnere, war das in den anderen Simulationen nicht unbedingt so. Ein Blick in die Gegenrichtung wäre tatsächlich interessant: vielleicht fällt da die ganze Wolke in die Sonne?

Bernhard
22.01.2013, 09:05
Meine ich das nur, oder fliegen diese Trümmer bei einem tangentiellen Start fast alle aus dem Sonnensystem raus?
Das stimmt schon und setzt sich bis 11 Mio. Jahre auch so fort. Bevor ich weitere Ergebnisse mitteile möchte ich aber noch weiter rechnen lassen.

Ich werde mir die Bedingung für das Ausgeben der Meldung "Planet zu weit weg" auch noch genauer ansehen. Vielleicht wird dort ja auch die Energie des Planeten berücksichtigt.


Ein Blick in die Gegenrichtung wäre tatsächlich interessant: vielleicht fällt da die ganze Wolke in die Sonne?
Das halte ich für eher unwahrscheinlich, weil wir die Gegenrichtung ja bereits mit der "falschen" Dichte (Dichte der Trümmer = Dichte der Erde) grob gerechnet haben. Ich würde einfach mehr Kollisionen mit der Erde und Venus erwarten.

Bynaus
26.01.2013, 14:48
Kann man die Simulation auf jeder beliebigen Linux-Distribution laufen lassen? Ich denke nämlich darüber nach, Linux Mint als DualBoot zu installieren. Am Departement in Lund haben wir ausserdem einen sehr schnellen Rechner, den wir gelegentlich für grafische Berechnungen (3D-Daten aus Röntgenexperimenten) benutzen, aber meistens steht er unbenutzt herum...

Bernhard
26.01.2013, 16:05
Kann man die Simulation auf jeder beliebigen Linux-Distribution laufen lassen?
Eigentlich ja, weil wir den Quelltext besitzen. Sollte das SuSE-Binary (=lauffähiges Programm swifter_symba) auf Deiner Distribution nicht unmittelbar laufen (was leicht sein kann), schicke ich Dir den Quelltext inklusive make-Files. Du müsstest dann nur dafür sorgen, dass lokal auf dem Rechner ein C und ein Fortran-Compiler installiert ist. Bei beiden Compilern kannst Du die kostenlosen GNU-Versionen verwenden, die eigentlich bei jeder Distribution dabei sein sollten. Es müssen dann nur noch drei Zeilen in der zentralen Make-Datei angepasst werden, um das Berechnungsprogramm lokal bei Dir zu übersetzen und das zugehörige Binary sollte spätestens dann auch laufen.

Ich habe meine private, 21te, schnelle, tangentiale Startbedingung jetzt bis 41 Mio. Jahre rechnen lassen und es "schwirrt" nur noch ein Trümmerteil zwischen Mars und Jupiter mit einer ziemlich beachtlichen Inklination (ca. 0.7 AU weg von der Ekliptik) herum. Die meisten Trümmerteile haben das Sonnensystem verlassen und es gab in etwa gleich viele Treffer auf Venus und Erde. Sobald das letzte Trümmerteil weg ist schreibe ich hier alles auf, um die Statistik schon mal zu eröffnen :) .

Bernhard
26.01.2013, 16:16
Kann man die Simulation auf jeder beliebigen Linux-Distribution laufen lassen?
Ein funktionierendes Linux ist schon mal die "Eintrittskarte" zur "Simulationsparty". Den Rest sollten wir gemeinsam hin bekommen. Ich schicke Dir sobald ich meinen Rechner wieder auf Windows umschalten kann (=in spätestens drei Stunden) einfach mal mein Binary mit Parameterdatei zu. Sollte das nicht funktionieren, müsstest Du den Quelltext bei Dir übersetzen, aber auch das ist kein Hexenwerk.

Bernhard
27.01.2013, 07:04
Ich denke nämlich darüber nach, Linux Mint als DualBoot zu installieren.
Die Wikipedia-Seite von Linux Mint sieht brauchbar aus. Wenn die Installation von Software so einfach wie bei Ubuntu geht wäre das für den Einstieg ein Vorteil. Man braucht bei Ubuntu nämlich nur auf der Konsole den gesuchten Befehl eingeben. Ist das zugehörige Programm nicht installiert, fragt Ubuntu gleich nach, ob es aus dem Internet besorgt werden soll. Nach dem Download der benötigten Software wird diese automatisch installiert. Solltest Du Linux Mint verwenden, solltest Du bei der Installation darauf achten, bei der grafischen Oberfläche KDE auszuwählen. KDE ist Windows sehr ähnlich was den Einstieg erleichtert. Gnome ähnelt eher dem Mac OS.

Mir fällt auch noch eine interessante Alternative zum Dualboot ein. Du könntest Dir einen SATA-Wechselrahmen zulegen und Linux dann auf einer separaten Festplatte laufen lassen. Der Einbau eines solchen Rahmens ist ziemlich leicht und die Installation von Linux wird damit deutlich unproblematischer bis kinderleicht, weil man nicht mehr partitionieren muss. Ich verwende bei mir diesen Wechselrahmen (http://www.amazon.de/RaidSonic-IB-168SK-B-interne-Festplatten-swapping/dp/B000FSBVNC/ref=sr_1_3?ie=UTF8&qid=1359265519&sr=8-3) und bin damit sehr zufrieden. Bei ebay bekommt man auch relativ preisgünstige SATA-Festplatten, was die Kosten weiter reduziert, falls keine Ersatzfestplatte vorhanden ist. Man legt dann vor dem Rechnerstart nur noch die Festplatte ein, mit der man arbeiten will und braucht sich um sonst nichts mehr zu kümmern.

Ich hatte mir meinen Wechselrahmen übrigens auch mal zugelegt, um unterschiedliche Distributionen zu testen. Wenn einem die verwendete Distribution nicht zusagt, installiert man dann einfach komplett eine neue. Bei einem Dualboot muss man sich bei einer Neuinstallation oder auch bei einer Deinstallation immer wieder um die Partitionierung der Festplatte kümmern, was gerade bei Zeitmangel schon mal lästig werden kann. Ein Wechselrahmen schont also die Nerven und die Hauptplatte mit Windows bleibt dabei auch unverändert.

Bernhard
29.01.2013, 19:03
Ich habe jetzt eine Rechnung bis 101 Mio. Jahre gerechnet. Die Trümmer starten tangential zur Erdbahn und lieferten die folgenden Ergebnisse:

Merging particles 13 and 26 at time t = 11600.000000000000
Particle 15 too far from Sun at t = 5411776.0000000000
Particle 30 too far from Sun at t = 34661488.000000000
Particle 8 too far from Sun at t = 41953952.000000000
Merging particles 4 and 6 at time t = 48520608.000000000
Particle 25 too far from Sun at t = 50563952.000000000
Particle 29 too far from Sun at t = 72366024.000000000
Particle 32 too far from Sun at t = 77477376.000000000
Particle 10 too far from Sun at t = 105486464.00000000
Particle 20 too far from Sun at t = 127112072.00000000
Particle 19 too far from Sun at t = 140336184.00000000
Particle 12 too far from Sun at t = 179400576.00000000
Particle 17 too far from Sun at t = 396235168.000000000
Particle 35 too far from Sun at t = 421358680.000000000
Particle 14 too far from Sun at t = 430163120.000000000
Particle 22 too far from Sun at t = 517040224.00000000
Particle 13 too far from Sun at t = 545019152.00000000
Particle 27 too far from Sun at t = 545253848.00000000
Particle 9 too far from Sun at t = 599078824.00000000
Merging particles 4 and 18 at time t = 706671944.000000000
Merging particles 3 and 31 at time t = 824166752.000000000
Merging particles 3 and 7 at time t = 1616933472.000000000
Merging particles 4 and 21 at time t = 3013823392.00000000
Particle 11 too far from Sun at t = 3138515280.00000000
Particle 33 too far from Sun at t = 3755914600.00000000
Particle 16 too far from Sun at t = 3810614576.00000000
Merging particles 4 and 24 at time t = 5096791896.0000000
Merging particles 3 and 34 at time t = 6982805888.0000000
Merging particles 3 and 28 at time t = 9589905784.0000000
Particle 5 too far from Sun at t = 14480180584.0000000

Die Erde bekommt also vier Treffer und die Venus ebenfalls.

Die Einheit von t ist 1 Tag = 86400s. Die Rechnung habe ich mit Ausgabe sämtlicher Planetenpositionen bei 1, 11, 21, 31, 41, 71, 91 und 101 Mio. Jahren durchgeführt. Nach 40 Mio. Jahre ist von den 31 Trümmerteilen nur noch Nummer 23 unterwegs. Es pendelt zwischen der Erdbahn und dem Asteroidengürtel. Die Bahnneigung ist dabei zwischenzeitlich relativ groß und nimmt zum Ende der Simulation dann wieder etwas ab.

Laudian
09.02.2013, 14:16
So, meine letzte Klausur ist geschrieben, und vorgestern hab ich meinem PC noch eine neue CPU spendiert, ich bin ab morgen wieder bereit zum crunchen ;-)

Bernhard
09.02.2013, 19:00
ich bin ab morgen wieder bereit zum crunchen ;-)
Hallo Laudian,

ich habe das Projekt mittlerweile in mein privates Archiv (zip auf DVD) verschoben und die Motivation es wieder heraus zu holen ist momentan ziemlich gering. Bynaus müsste noch etliche neue und schnelle Startbedingungen haben.
MfG

EDIT: Ich sehe gerade, dass die Programme zur Erzeugung der Startdateien noch zugänglich sind. Ich könnte also noch praktisch beliebig viele Startdateien generieren, aber nicht mehr testen, wie schnell die laufen. Wenn Du das selber machen möchtest, schicke ich Dir neue Dateien zu. Schreib hier einfach auf, wieviele Du haben willst.

Ich hatte zwischenzeitlich auch mal 1 Mio. Jahre plus Ceres, Vesta, Juno und Pallas gerechnet. Da gab es dann etliche Abstürze in die Sonne.

Bynaus
25.02.2013, 20:26
Es wäre schade, dieses interessante Projekt ganz in der Versenkung verschwinden zu lassen, aber ich verstehe natürlich auch, dass man da nur soweit was reinsteckt, wie man auch was zurückbekommt, in diesem Fall die Resonanz der Mit"cruncher". Ich bin da auch alles andere als Unschuldig, aber ich hoffe, es wird jetzt langsam wieder etwas besser mit meiner Freizeit...


Ich hatte zwischenzeitlich auch mal 1 Mio. Jahre plus Ceres, Vesta, Juno und Pallas gerechnet. Da gab es dann etliche Abstürze in die Sonne.

Interessant - und seltsam. Derart massearme Objekte, weitab der Kollisionszone, sollten doch eigentlich keine grosse Auswirkungen auf den Verlauf der Simulation haben...

Bernhard
25.02.2013, 22:37
Interessant - und seltsam. Derart massearme Objekte, weitab der Kollisionszone, sollten doch eigentlich keine grosse Auswirkungen auf den Verlauf der Simulation haben...
Hallo Bynaus,

ich stelle mir schon seit längerem die Frage, ob das zu untersuchende System nicht teilweise durch ein chaotisches Verhalten charakterisiert wird. Das würde dann (leider) bedeuten, dass auch mit sehr hohem Rechenaufwand vergleichsweise wenig Informationen gewonnen werden können. Du solltest deswegen vielleicht nochmal etwas enger umreissen, welche statistischen Fragen Du (mit unserer Unterstützung) klären willst und welchen wissenschaftlichen "Wert" diese Informationen haben. Anders ausgedrückt: Welche Fragestellungen können wir prinzipiell mit dieser Simulation untersuchen?
MfG

Bynaus
26.02.2013, 07:57
Mir geht es vorwiegend um diese Frage: "Welcher Anteil der Trümmer stösst in einer typischen Simulation mit der Erde zusammen?" bzw. "Welcher Massenanteil der Erde stammt aus solchen späten Trümmern?" Ob die Antworten, die wir gewinnen, einen wissenschaftlichen Wert haben, hängt davon ab, wie verlässlich die Simulationen (bzw. die daraus gewonnen Ergebnisse) denn wirklich sind. Das kann ich natürlich nicht so ohne weiteres beurteilen. Natürlich hat jedes Modell seine Probleme und Begrenzungen - genauso wie unser Wissen über die damaligen Vorgänge. Da einen Weg hindurch zu finden, bei dem wir sowohl ein einigermassen überzeugendes Ergbniss bekommen, das darüber hinaus auch noch interessant ist, ist eine hohe Kunst. Aber auch nicht völlig unerreichbar.

Bernhard
26.02.2013, 08:47
Mir geht es vorwiegend um diese Frage: "Welcher Anteil der Trümmer stösst in einer typischen Simulation mit der Erde zusammen?" bzw. "Welcher Massenanteil der Erde stammt aus solchen späten Trümmern?"
Dazu kann man eigentlich schon jetzt sagen, dass diese Fragen mit SyMBA und vermutlich auch mit dem Mercury-Code nicht eindeutig zu beantworten sind. Man kann da bestenfalls Wahrscheinlichkeiten für das eine oder andere Szenario berechnen.

Bynaus
26.02.2013, 09:25
Dazu kann man eigentlich schon jetzt sagen, dass diese Fragen mit SyMBA und vermutlich auch mit dem Mercury-Code nicht eindeutig zu beantworten sind.

Warum meinst du?

Mir ist schon klar, dass man für eine exakte Simulation die Anfangsparameter der Kollision wissen müsste. Darum gehts mir ja deshalb auch gar nicht. Es geht darum, zu sehen, ob es einen "typischen" Ausgang der Simulationen gibt, wenn wir genügend oft durch alle möglichen Anfangsparameter (v.a. "Auswurfwinkel" relativ zur Erdbahn, evtl. Winkel relativ zur Bahnebene) iterieren. Gibt es einen solchen typischen Ausgang (also eine Aussage, die für die allermeisten Ausgänge gilt, z.B. "in den meisten Simulationen kollidiert ca. 50% der Auswurfmasse wieder mit der Erde"), dann kann man eine relativ gute Aussage über den Beitrag dieser Trümmer zur irdischen Isotopie machen, selbst wenn man die Anfangsparameter der Kollision nicht kennt. Gibt es aber keinen typischen Ausgang, das heisst also es stellt sich heraus, dass der Beitrag dieser Trümmer sehr stark von den Anfangsparametern abhängt, kann man das eben nicht und man muss die Idee begraben.

Bernhard
26.02.2013, 14:10
Gibt es aber keinen typischen Ausgang, das heisst also es stellt sich heraus, dass der Beitrag dieser Trümmer sehr stark von den Anfangsparametern abhängt, kann man das eben nicht und man muss die Idee begraben.
Die bisherigen Daten zeigen eine gewisse Tendenz in diese Richtung, denn wir hatten bei recht unterschiedlichen Anfangsbedingungen bereits gesehen, dass abgesehen von den Runaways und Treffern auf der Sonne, Treffer auf Erde und Venus relativ häufig auftreten. Wir konnten damit das Hit-and-Run-Szenario nicht falsifizieren und das ist meiner Meinung nach schon für sich ein interessantes Ergebnis.

Gibt es eigentlich experimentelle Hinweise darauf, dass die Venus auch Material von diesem Ereignis tragen könnte?

Laudian
27.02.2013, 00:24
Wie gesagt, solltet ihr weiterrechnen wollen bin ich gerne wieder dabei.

Bynaus
27.02.2013, 08:59
Die bisherigen Daten zeigen eine gewisse Tendenz in diese Richtung, denn wir hatten bei recht unterschiedlichen Anfangsbedingungen bereits gesehen, dass abgesehen von den Runaways und Treffern auf der Sonne, Treffer auf Erde und Venus relativ häufig auftreten.

Ja, das ist ein interessantes, vorläufiges Ergebnis. Bloss müsste es sich jetzt erst noch in einigen dutzend bis hundert Durchläufen bestätigen. Und da sind uns Angebote wie jenes von Laudian natürlich sehr willkommen.


Gibt es eigentlich experimentelle Hinweise darauf, dass die Venus auch Material von diesem Ereignis tragen könnte?

Die geophysikalischen und vor allem geochemischen Informationen, die wir zur Venus haben, sind sehr begrenzt: es gab ja nur wenige Lander und Atmosphärensonden, und die hatten keine sehr fortgeschrittenen Instrumente dabei. Das einzige, was wir über die Geochemie der Venus relativ gut wissen, ist die Edelgaszusammensetzung der Atmosphäre - und die versteht niemand so richtig. :)

Bernhard
27.02.2013, 10:00
Ja, das ist ein interessantes, vorläufiges Ergebnis. Bloss müsste es sich jetzt erst noch in einigen dutzend bis hundert Durchläufen bestätigen. Und da sind uns Angebote wie jenes von Laudian natürlich sehr willkommen.
Ich habe Laudian eben ein Paket mit fünf neuen Startdateien geschickt.

Laudian
05.03.2013, 19:05
Hab eben dooferweise einen Fehler gemacht. Statt 4 Millionen Jahren habe ich 40 Millionen eingestellt, wovon bis jetzt ca. 20% berechnet wurden, also in ca. 5 Stunden. Allerdings weiß ich jetzt, dass das Programm sehr gut mit Hyper Threading skaliert, und morgen wird es dann mit richtigen Einstellungen gestartet ;-)
Letzte Woche bin ich nicht dazu gekommen das Programm laufen zu lassen, das ich krank und dementsprechend viel zuhause war.

Laudian
09.03.2013, 15:12
So, hier mal ein paar Ergebnisse, der Rest kommt heute Abend, Formatierung ebenfalls ;-)

Datei1:
Merging particles 8 and 11 at time t = 0.0000000000000000 =0 Jahre
Merging particles 19 and 26 at time t = 2656.0000000000000 =7,30
Merging particles 6 and 22 at time t = 5952.0000000000000 =1,63
Particle 23 too far from Sun at t = 20263048.000000000 =5,55E4
Particle 20 too far from Sun at t = 24678752.000000000 =6,76E4
Particle 25 too far from Sun at t = 41546928.000000000 =1,14E5
Particle 15 too far from Sun at t = 47178072.000000000 =1,29E5
Particle 6 too far from Sun at t = 65574792.000000000 =1,80E5
Particle 19 too far from Sun at t = 79110840.000000000 =2,17E5
Particle 17 too far from Sun at t = 81572832.000000000 =2,23E5
Particle 12 too far from Sun at t = 88504344.000000000 =2,42E5
Particle 5 too far from Sun at t = 330987008.00000000 =9,06E5
Particle 8 too close to Sun at t = 337962136.00000000 =9,25E5
Particle 34 too close to Sun at t = 448431512.00000000 =1,23E6
Particle 10 too far from Sun at t = 456453528.00000000 =1,25E6
Particle 7 too far from Sun at t = 537680424.00000000 =1,47E6
Merging particles 3 and 18 at time t = 677544840.00000000 =1,86E6
Particle 21 too far from Sun at t = 791486168.00000000 =2,17E6
Time = 1.44000E+09; fraction done = 0.986; Number of active pl, tp = 22, 0
Merging particles 4 and 24 at time t = 65476168.000000000 =4,18E6
Merging particles 3 and 9 at time t = 358144120.00000000 =4,98E6
Particle 29 too far from Sun at t = 2029932896.0000000 =9,56E6
Particle 28 too far from Sun at t = 2119850616.0000000 =9,80E6
Particle 35 too far from Sun at t = 2197055368.0000000 =10,0E6
Merging particles 4 and 32 at time t = 2447532816.0000000 =10,7E6
Merging particles 4 and 30 at time t = 3271703696.0000000 =12,96E6
Particle 27 too far from Sun at t = 3984570704.0000000 =14,61E6
Merging particles 4 and 16 at time t = 6202693880.0000000 =20,98E6
Particle 14 too close to Sun at t = 611387336.00000000 =25,67E6
Particle 33 too close to Sun at t = 917204728.00000000 =26,51E6



Datei2:
Particle 28 too far from Sun at t = 6791792.0000000000 =18607 Jahre
Merging particles 4 and 7 at time t = 36246248.000000000 =99304
Particle 5 too far from Sun at t = 52301592.000000000 =1,43E5
Particle 27 too far from Sun at t = 55368080.000000000 =1,52E5
Particle 25 too far from Sun at t = 61510264.000000000 =1,69E5
Merging particles 4 and 21 at time t = 89269328.000000000 =2,45E5
Particle 17 too far from Sun at t = 120830960.00000000 =3,31E5
Particle 33 too far from Sun at t = 140214952.00000000 =3,84E5
Particle 19 too far from Sun at t = 198909816.00000000 =5,45E5
Particle 11 too far from Sun at t = 293397424.00000000 =8,04E5
Particle 6 too far from Sun at t = 440981352.00000000 =1,21E6
Particle 13 too far from Sun at t = 457913608.00000000 =1,25E6
Particle 35 too far from Sun at t = 839921344.00000000 =2,30E6
Particle 10 too far from Sun at t = 1034207080.0000000 =2,83E6
Particle 8 too far from Sun at t = 1107940528.0000000 =3,04E6
Particle 23 too far from Sun at t = 1851295936.0000000 =9.07E6
Merging particles 2 and 30 at time t = 2218861696.0000000 =10,07E6
Particle 16 too far from Sun at t = 2341659392.0000000 =10,42E6
Particle 9 too far from Sun at t = 3784997232.0000000 =14,37E6
Merging particles 3 and 29 at time t = 4819964840.0000000 =17,21E6
Particle 18 too far from Sun at t = 5764931088.0000000 =19,79E6
Particle 24 too far from Sun at t = 6038608224.0000000 =20,54E6
Particle 34 too far from Sun at t = 6572882088.0000000 =22,01E6
Merging particles 3 and 15 at time t = 7091912976.0000000 =23,43E6
Merging particles 4 and 22 at time t = 3435154512.0000000 =33,41E6



Datei3:
Merging particles 33 and 20 at time t = 0.0000000000000000 =0 Jahre
Merging particles 9 and 12 at time t = 4744.0000000000000 =13
Particle 27 too far from Sun at t = 15977824.000000000 =4,38E4
Particle 29 too far from Sun at t = 18854800.000000000 =5,17E4
Particle 9 too far from Sun at t = 36844288.000000000 =1,01E5
Merging particles 4 and 25 at time t = 37429752.000000000 =1,03E5
Particle 35 too far from Sun at t = 54909712.000000000 =1,50e5
Particle 7 too far from Sun at t = 77682008.000000000 =2,13e5
Particle 6 too far from Sun at t = 79323032.000000000 =2,17e5
Particle 17 too close to Sun at t = 117139720.00000000 =3,21e5
Particle 14 too far from Sun at t = 122145832.00000000 =3,35e5
Particle 16 too far from Sun at t = 140916920.00000000 =3,86e5
Merging particles 4 and 23 at time t = 226063328.00000000 =6,19e5
Particle 22 too far from Sun at t = 287491128.00000000 =7,88e5
Particle 21 too far from Sun at t = 452552984.00000000 =1,24e6
Particle 34 too far from Sun at t = 487528408.00000000 =1,34e6
Particle 15 too far from Sun at t = 886981920.00000000 =2,43e6
Merging particles 3 and 5 at time t = 81433400.000000000 =4,22e6
Particle 10 too far from Sun at t = 109822440.00000000 =4,30e6
Merging particles 36 and 30 at time t = 435474736.00000000 =5,19e6
Merging particles 3 and 28 at time t = 620098392.00000000 =5,70e6
Particle 8 too far from Sun at t = 622290816.00000000 =5,70e6
Particle 33 too far from Sun at t = 650950320.00000000 =5,78e6
Particle 24 too far from Sun at t = 777410144.00000000 =6,13e6
Merging particles 3 and 13 at time t = 1095102680.0000000 =7,00e6
Particle 26 too far from Sun at t = 1982551040.0000000 =9,43e6
Particle 32 too far from Sun at t = 4196263200.0000000 =15,50e6
Merging particles 4 and 19 at time t = 6085384432.0000000 =20,67e6
Particle 11 too far from Sun at t = 3629679600.0000000 =33,94e6

Bernhard
09.03.2013, 17:05
Formatierung ebenfalls ;-)
Es müssen eigentlich nur noch die Zeiten aufaddiert werden.

@Bynaus: Wie wichtig sind eigentlich die Startdateien mit den genauen Positionen und Geschwindigkeiten aller Körper? Ich habe bei meinem Durchlauf über 101 Mio. Jahre lediglich die Ergebnisse gespeichert, damit sich nicht zu viel Datenschrott ansammelt. Mir persönlich erscheint es als ausreichend zu wissen, in welchen Winkelbereich die Trümmer relativ zur Erdbahn starten.

Laudian
09.03.2013, 17:40
Mit Formatierung meinte ich eigentlich, dass ich hier im Forum noch ein paar Leereichen einfüge, damit es schöner aussieht.
Die Zeiten sind ja teilweise schon addiert.

Bernhard
09.03.2013, 19:21
Die Zeiten sind ja teilweise schon addiert.
"Grmpf"...

Ich erkläre es nochmal: Wenn Du an Tag 1 eine Simulation mit 4 Mio. rechnest und am Tag darauf noch eine mit 8 Mio. Jahren so ergibt das insgesamt 12 Mio. Jahre, vorausgesetzt Du verwendest immer die gleiche Datei theia_pl.in. Bei den Ausgaben der zweiten Simulation wie z.B. Particle 29 too far from Sun at t = 2029932896.0000000 müssen also bei der Zeitangabe noch 4 Mio. Jahre = 365.25 * 4000000 = 1461000000 addiert werden. Im Beispiel bedeutet das Particle 29 too far from Sun at t = 3490932896.0000000

Genau deswegen dränge ich so sehr darauf immer alle Ergebnisse zu speichern. Wenn man dann mal nicht mehr weiß, ob man die Verwaltung der Simulation nicht durcheinander gebracht hat, so kann man vom letzten Ergebnis wieder weiter rechnen und muss nicht bei Null anfangen.

Da Du mir die Ergebnisse von Datei 1 bis zu 24 Mio. Jahre geschickt hast, kann ich recht gut nachverfolgen, dass Du die hier (http://astronews.com/forum/showthread.php?6238-TheiaSim&p=93377#post93377) angegeben Zeiten einfach kopiert hast. Die Zeiten kumulieren aber, auch wenn es Arbeit macht, das zu berücksichtigen.
MfG

Laudian
09.03.2013, 20:11
Die Tage habe ich nicht addiert, sondern gleich die Jahre.
Die stehen hier im Forum in der letzten Spalte ;-)
Soweit ich weiß reichen die gerundeten Werte da ja, oder ?

Du hast übrigens seit heute die Rechnungen bis 50 Millionen Jahren ;-)

Bynaus
10.03.2013, 00:11
@Laudian, sehr schön, ich muss mir das mal ansehen.

@Bernhard:


@Bynaus: Wie wichtig sind eigentlich die Startdateien mit den genauen Positionen und Geschwindigkeiten aller Körper? Ich habe bei meinem Durchlauf über 101 Mio. Jahre lediglich die Ergebnisse gespeichert, damit sich nicht zu viel Datenschrott ansammelt. Mir persönlich erscheint es als ausreichend zu wissen, in welchen Winkelbereich die Trümmer relativ zur Erdbahn starten.

Nun, die exakten Positionen und Geschwindigkeiten sind nicht so wichtig. Wir interessieren uns ja eigentlich nicht für die einzelnen Trümmer, sondern für das generelle Verhalten in Abhängigkeit der (eher generellen) Anfangsbedingungen. Wir machen quasi sowas wie eine "Monte-Carlo" Simulation. Da reicht es zu sagen, innerhalb welcher Werte man die Startpositionen und -geschwindigkeiten zufällig festgelegt hat.

Bernhard
10.03.2013, 00:41
Die Tage habe ich nicht addiert, sondern gleich die Jahre.
Die stehen hier im Forum in der letzten Spalte ;-)
OK.

Soweit ich weiß reichen die gerundeten Werte da ja, oder ?
Der Aufwand die Tage zu addieren ist nicht wirklich schlimm. Das kann ich machen. Dann haben wir die exakten Werte und verlieren keine Informationen.


Du hast übrigens seit heute die Rechnungen bis 50 Millionen Jahren ;-)
Prima :cool: . Thread Nr. 8 ist übrigens schon fertig, weil da nur noch die acht Planeten + Sonne übrig sind. (Number of active planets = 9).

Bernhard
10.03.2013, 00:45
Nun, die exakten Positionen und Geschwindigkeiten sind nicht so wichtig.
OK. Da bin ich dann wieder beruhigt. Alles andere hätte wegen des zeitlichen Aufwandes auch näher begründet werden müssen ;) .

Bernhard
10.03.2013, 16:50
Hier die Ergebnisse von Thread Nr. 8 (Nummer ist hier unwichtig):

Merging particles 8 and 12 at time t = 1904
Merging particles 4 and 16 at time t = 3280
Particle 9 too far from Sun at t = 7378256
Particle 8 too far from Sun at t = 43479296
Particle 35 too far from Sun at t = 52775840
Particle 5 too far from Sun at t = 86237224
Particle 21 too far from Sun at t = 103169400
Particle 13 too far from Sun at t = 118031184
Particle 28 too close to Sun at t = 159188224
Particle 22 too far from Sun at t = 169627984
Particle 11 too far from Sun at t = 223119624
Particle 23 too far from Sun at t = 258499640
Particle 27 too far from Sun at t = 346308528
Particle 14 too far from Sun at t = 470310880
Particle 31 too close to Sun at t = 747983704
Particle 26 too far from Sun at t = 1257909928
Particle 20 too far from Sun at t = 1304326496
Merging particles 4 and 18 at time t = 1755238976
Particle 25 too close to Sun at t = 3127112128
Merging particles 36 and 32 at time t = 3376871824
Particle 6 too close to Sun at t = 5517095512
Particle 34 too far from Sun at t = 6528543256
Merging particles 3 and 30 at time t = 6810486232
Merging particles 3 and 29 at time t = 8794714728
Merging particles 4 and 10 at time t = 8942486416
Particle 33 too far from Sun at t = 9008022512
Particle 19 too far from Sun at t = 9528025656
Merging particles 4 and 15 at time t = 9873309328
Particle 24 too far from Sun at t = 12291174024
Merging particles 36 and 7 at time t = 13514499056
Particle 17 too far from Sun at t = 13947289280 = 38,2 Mrd. Jahre

Alle Trümmer sind nach 38,2 Milliarden Jahren verschwunden.

Die Erde erhält in dieser Zeit 4 Treffer
Venus erhält 2 Treffer und
Mars erhält ebenfalls zwei Treffer

Laudian
10.03.2013, 19:06
Tja, deine Ergebnisse zeigen eindeutig, dass wir alle vorherigen Theorien zum Alter des Universums über den Haufen werfen können ;-)

Alle Trümmer sind nach 38,2 Milliarden Jahren verschwunden.
Ich habe es doch noch nicht geschafft, alle Ergebnisse zusammenzufassen, werde das aber bis morgen nachholen.

Bernhard
10.03.2013, 20:31
Alle Trümmer sind nach 38,2 Milliarden Jahren verschwunden.
Hoppla und Danke für den Hinweis! Da sind natürlich Millionen Jahre gemeint.

Bernhard
15.03.2013, 16:21
Hi Bynaus,

ich habe gerade die restlichen Ergebnisse von Laudians 8-pack aufbereitet:

Merging particles 8 and 11 at time t = 0
Merging particles 19 and 26 at time t = 2656
Merging particles 6 and 22 at time t = 5952
Particle 23 too far from Sun at t = 20263048
Particle 20 too far from Sun at t = 24678752
Particle 25 too far from Sun at t = 41546928
Particle 15 too far from Sun at t = 47178072
Particle 6 too far from Sun at t = 65574792
Particle 19 too far from Sun at t = 79110840
Particle 17 too far from Sun at t = 81572832
Particle 12 too far from Sun at t = 88504344
Particle 5 too far from Sun at t = 330987008
Particle 8 too close to Sun at t = 337962136
Particle 34 too close to Sun at t = 448431512
Particle 10 too far from Sun at t = 456453528
Particle 7 too far from Sun at t = 537680424
Merging particles 3 and 18 at time t = 677544840
Particle 21 too far from Sun at t = 791486168
Merging particles 4 and 24 at time t = 1526476168
Merging particles 3 and 9 at time t = 1819144120
Particle 29 too far from Sun at t = 3490932896
Particle 28 too far from Sun at t = 3580850616
Particle 35 too far from Sun at t = 3658055368
Merging particles 4 and 32 at time t = 3908532816
Merging particles 4 and 30 at time t = 4732703696
Particle 27 too far from Sun at t = 5445570704
Merging particles 4 and 16 at time t = 7663693880
Particle 14 too close to Sun at t = 9377387336
Particle 33 too close to Sun at t = 9683204728
Particle 31 too far from Sun at t = 26198620312
Particle 13 too far from Sun at t = 27604240392 = 75.6 Mio. Jahre

Particle 28 too far from Sun at t = 6791792
Merging particles 4 and 7 at time t = 36246248
Particle 5 too far from Sun at t = 52301592
Particle 27 too far from Sun at t = 55368080
Particle 25 too far from Sun at t = 61510264
Merging particles 4 and 21 at time t = 89269328
Particle 17 too far from Sun at t = 120830960
Particle 33 too far from Sun at t = 140214952
Particle 19 too far from Sun at t = 198909816
Particle 11 too far from Sun at t = 293397424
Particle 6 too far from Sun at t = 440981352
Particle 13 too far from Sun at t = 457913608
Particle 35 too far from Sun at t = 839921344
Particle 10 too far from Sun at t = 1034207080
Particle 8 too far from Sun at t = 1107940528
Particle 23 too far from Sun at t = 3312295936
Merging particles 2 and 30 at time t = 3679861696
Particle 16 too far from Sun at t = 3802659392
Particle 9 too far from Sun at t = 5245997232
Merging particles 3 and 29 at time t = 6280964840
Particle 18 too far from Sun at t = 7225931088
Particle 24 too far from Sun at t = 7499608224
Particle 34 too far from Sun at t = 8033882088
Merging particles 3 and 15 at time t = 8552912976
Merging particles 4 and 22 at time t = 12201154512
Particle 12 too far from Sun at t = 20851108272 = 57.1 Mio. Jahre

Merging particles 33 and 20 at time t = 0
Merging particles 9 and 12 at time t = 4744
Particle 27 too far from Sun at t = 15977824
Particle 29 too far from Sun at t = 18854800
Particle 9 too far from Sun at t = 36844288
Merging particles 4 and 25 at time t = 37429752
Particle 35 too far from Sun at t = 54909712
Particle 7 too far from Sun at t = 77682008
Particle 6 too far from Sun at t = 79323032
Particle 17 too close to Sun at t = 117139720
Particle 14 too far from Sun at t = 122145832
Particle 16 too far from Sun at t = 140916920
Merging particles 4 and 23 at time t = 226063328
Particle 22 too far from Sun at t = 287491128
Particle 21 too far from Sun at t = 452552984
Particle 34 too far from Sun at t = 487528408
Particle 15 too far from Sun at t = 886981920
Merging particles 3 and 5 at time t = 1542433400
Particle 10 too far from Sun at t = 1570822440
Merging particles 36 and 30 at time t = 1896474736
Merging particles 3 and 28 at time t = 2081098392
Particle 8 too far from Sun at t = 2083290816
Particle 33 too far from Sun at t = 2111950320
Particle 24 too far from Sun at t = 2238410144
Merging particles 3 and 13 at time t = 2556102680
Particle 26 too far from Sun at t = 3443551040
Particle 32 too far from Sun at t = 5657263200
Merging particles 4 and 19 at time t = 7546384432
Particle 11 too far from Sun at t = 12395679600
Particle 18 too far from Sun at t = 23144814152 = 63.4 Mio. Jahre

Merging particles 5 and 17 at time t = 0
Particle 26 too far from Sun at t = 5195448
Particle 29 too far from Sun at t = 13752664
Particle 7 too far from Sun at t = 30750936
Merging particles 3 and 5 at time t = 33646976
Particle 27 too far from Sun at t = 73229288
Particle 18 too far from Sun at t = 78132504
Particle 20 too far from Sun at t = 84930304
Particle 34 too far from Sun at t = 153970016
Particle 21 too close to Sun at t = 156862904
Particle 12 too far from Sun at t = 163258920
Particle 11 too far from Sun at t = 173645888
Particle 6 too far from Sun at t = 183948376
Particle 35 too far from Sun at t = 217027632
Particle 25 too far from Sun at t = 289250448
Particle 16 too far from Sun at t = 298064048
Particle 31 too far from Sun at t = 308783384
Particle 33 too far from Sun at t = 318415304
Particle 14 too far from Sun at t = 356462968
Particle 32 too far from Sun at t = 517916960
Merging particles 3 and 8 at time t = 532407760
Merging particles 3 and 19 at time t = 718459224
Particle 9 too far from Sun at t = 867739392
Particle 23 too close to Sun at t = 3436955936
Merging particles 3 and 10 at time t = 7634913856
Particle 15 too far from Sun at t = 7677352424
Particle 22 too far from Sun at t = 7776485144
Particle 28 too far from Sun at t = 8417547944
Particle 24 too close to Sun at t = 14686777408
Particle 30 too close to Sun at t = 17087986016 = 46.8 Mio. Jahre

Fortsetzung folgt....

Bernhard
15.03.2013, 16:22
Merging particles 4 and 22 at time t = 21584
Merging particles 9 and 16 at time t = 134368
Particle 35 too far from Sun at t = 16019696
Particle 10 too far from Sun at t = 26068184
Particle 21 too far from Sun at t = 41267280
Particle 24 too far from Sun at t = 51192472
Particle 31 too far from Sun at t = 66685296
Particle 34 too far from Sun at t = 115750864
Particle 19 too far from Sun at t = 121647944
Particle 8 too far from Sun at t = 124184192
Particle 28 too far from Sun at t = 139505472
Particle 11 too far from Sun at t = 313489200
Particle 25 too far from Sun at t = 347602904
Particle 5 too far from Sun at t = 371737864
Particle 7 too far from Sun at t = 533118856
Particle 27 too far from Sun at t = 1392516904
Particle 13 too far from Sun at t = 2050282552
Particle 30 too far from Sun at t = 2671421480
Particle 15 too far from Sun at t = 2689115320
Particle 29 too far from Sun at t = 3512717912
Merging particles 3 and 33 at time t = 4556668472
Particle 32 too far from Sun at t = 5973434664
Merging particles 3 and 23 at time t = 6610003968
Merging particles 3 and 17 at time t = 9057698688
Particle 9 too far from Sun at t = 9188734392
Particle 6 too far from Sun at t = 10373642144
Particle 12 too far from Sun at t = 13572125232
Particle 14 too far from Sun at t = 14889300200
Particle 18 too far from Sun at t = 15677691224 = 42.9 Mio. Jahre

Merging particles 7 and 9 at time t = 800
Merging particles 4 and 10 at time t = 1449152
Particle 23 too far from Sun at t = 6915464
Particle 20 too far from Sun at t = 33385984
Particle 11 too far from Sun at t = 44757752
Particle 19 too far from Sun at t = 51876096
Merging particles 4 and 13 at time t = 68248776
Particle 8 too far from Sun at t = 125708672
Merging particles 4 and 31 at time t = 134695656
Merging particles 4 and 29 at time t = 215319144
Particle 35 too far from Sun at t = 225462608
Particle 14 too far from Sun at t = 330767184
Particle 30 too far from Sun at t = 396667712
Merging particles 4 and 24 at time t = 526001048
Particle 25 too close to Sun at t = 547619104
Merging particles 4 and 12 at time t = 609321208
Particle 21 too far from Sun at t = 749039496
Particle 26 too far from Sun at t = 850361376
Particle 15 too far from Sun at t = 1469194280
Merging particles 3 and 6 at time t = 2736794448
Particle 7 too far from Sun at t = 6387519304
Particle 32 too far from Sun at t = 6917703992
Particle 34 too far from Sun at t = 8451284904
Merging particles 4 and 16 at time t = 8942444856
Merging particles 36 and 28 at time t = 8979896336
Particle 33 too far from Sun at t = 10462346144
Particle 27 too far from Sun at t = 10820309624
Particle 5 too far from Sun at t = 10862712384
Particle 18 too far from Sun at t = 15536844904
Particle 17 too far from Sun at t = 17902878856
Particle 22 too far from Sun at t = 31279451224 = 85.6 Mio. Jahre

Merging particles 17 and 25 at time t = 0
Merging particles 31 and 30 at time t = 0
Merging particles 6 and 23 at time t = 8
Particle 15 too far from Sun at t = 15854880
Particle 22 too far from Sun at t = 18597296
Particle 31 too far from Sun at t = 131951456
Particle 6 too far from Sun at t = 149067392
Particle 18 too close to Sun at t = 151266936
Particle 24 too far from Sun at t = 174643136
Particle 27 too far from Sun at t = 204614568
Particle 29 too close to Sun at t = 258823512
Merging particles 4 and 35 at time t = 261954904
Particle 28 too far from Sun at t = 263457960
Particle 9 too far from Sun at t = 314897952
Particle 14 too close to Sun at t = 657259872
Particle 5 too close to Sun at t = 729016728
Particle 10 too far from Sun at t = 822459680
Particle 33 too far from Sun at t = 1026689200
Merging particles 4 and 8 at time t = 1309851096
Merging particles 3 and 13 at time t = 2644617328
Particle 7 too far from Sun at t = 3050874976
Particle 17 too far from Sun at t = 4931731696
Particle 21 too far from Sun at t = 5551015976
Particle 19 too far from Sun at t = 6005723768
Particle 26 too far from Sun at t = 8535919968
Particle 16 too far from Sun at t = 8711784992
Merging particles 3 and 34 at time t = 9108262600
Particle 20 too far from Sun at t = 12193296832
Merging particles 3 and 11 at time t = 12226583104 = 33.5 Mio Jahre

Bynaus
15.03.2013, 18:03
Danke! Ich muss das alles mal zusammennehmen und schauen, was da so rausgekommen ist. Ab morgen bin ich für eine Woche in den USA, ich weiss noch nicht, wie viel Zeit ich habe.

In der Zwischenzeit habe ich einen Artikel für euch: http://arxiv.org/abs/1206.4190

Sehr interessant zu lesen. Alan Jackson (er hat letzte Woche einen Vortrag an der ETH Zürich gehalten, deshalb bin ich darauf aufmerksam geworden) hat ziemlich genau das gemacht, was wir hier versuchten, wobei er sich weniger auf die grössten Objekte konzentriert hat, sondern mehr die Entwicklung einer ganzen Trümmerwolke mit tausenden von Partikeln simuliert hat. Aber es ist auf jeden Fall interessant, zu sehen, wie sich die Ergebnisse denn so vergleichen.

Bernhard
15.03.2013, 22:06
Ab morgen bin ich für eine Woche in den USA
Guten Flug.


In der Zwischenzeit habe ich einen Artikel für euch: http://arxiv.org/abs/1206.4190
Interessant finde ich Bild 10 auf Seite 9. Ich sehe da nämlich eher einen zweiten Ring etwa mit dem Radius der Venusbahn. Das deckt sich ganz gut mit unseren Rechnungen.

Ich habe Laudian heute ein Paket mit 8 Startdateien aus dem 18ten "Sektor" geschickt. Dort starten die Trümmer genau senkrecht zur Erdbahn in Richtung Sonne.

Laudian
22.03.2013, 22:49
Verdammte. Scheiße.
Da ich das ganze Wochenende nur zum Schlafen zuhause bin, wollte ich die 8 neuen Startdatein einfach mal am Stück wegrechnen, also die ganzen 100 Millionen jahre in einem Run. Dooferweise habe ich aber die Laufzeit auf 365.25e9 Tage gestellt...

Ist es ok, wenn ich die Anwendung einfach abbreche, sobald die Anzahl der Teile auf 9 gesunken ist, und dann das Konsolenergebnis sichere ? In der Ergebnisdatei stehen ja ohnehin nur die Positionen der Planeten, da es keine Trümmer mehr gibt.

Edit: Ich sehe gerade, dass die Position der Planeten ja auch nach jedem Dump in die Discard.out geschrieben wird. also gehen doch keine Daten verloren.

Bernhard
22.03.2013, 23:54
Ist es ok, wenn ich die Anwendung einfach abbreche, sobald die Anzahl der Teile auf 9 gesunken ist, und dann das Konsolenergebnis sichere ?
Ja natürlich. Die Positionen der Planeten haben hier nur eine Art Backupfunktion.

Laudian
24.03.2013, 00:37
So, der nächste Satz ist fertig, diesmal wurden 200-300 mio Jahre berechnet.
Ergebnisse kommen morgen, leider ohne Zeitangaben, da mein System aus irgendeinem Grund "beinahe" abgestürzt ist und nurnoch wenige Eingaben akzeptiert hat. Und die auch nur manchmal.
Habe dann die Ergebnisse aller Konsolen auf dem Laptop abgeschrieben, hätte ich die Zeiten auchnoch abgeschrieben wäre ich wahnsinning geworden.

Bernhard
24.03.2013, 10:09
hätte ich die Zeiten auchnoch abgeschrieben wäre ich wahnsinning geworden.
Hallo Laudian,

übertreibe es bitte nicht. Wenn Dein Rechner mit diesen Aufgaben überlastet ist, sollten wir vielleicht erst eine Auf-, bzw. Verteilung der Arbeit besprechen. Ich sehe hier auch Bynaus in der Pflicht, weil von ihm die Vorgaben für die Berechnungen stammen.

Dir also erst mal einen erholsamen Sonntag und sieh zu, dass Du Deinen Kopf wieder frei bekommst. Wenn Du aktuell mehr als 40 Stunden die Woche arbeitest (und dieses Thema hier bedeutet ja auch Arbeit) sollten wir unbedingt einen "Gang" runter schalten, um uns keine versteckten Fehler einzuhandeln.
MfG

Kibo
27.03.2013, 15:35
Das könnte von eurem Interesse sein

"Mond und Vesta teilen sich gemeinsame kosmische Geschichte" (http://t.news.de.msn.com/wissen/nasa-mond-und-vesta-haben-gemeinsame-kosmische-geschichte-1)

mfg

Bernhard
27.03.2013, 19:50
Wenn Dein Rechner mit diesen Aufgaben überlastet ist, sollten wir vielleicht erst eine Auf-, bzw. Verteilung der Arbeit besprechen.
Hallo Laudian,

hast Du noch die ursprünglichen Startdateien von Sektor 18? Falls ja schlage ich vor, den Run nochmal mit vier Dateien laufen zu lassen. Ich persönlich würde nur Daten von einem fehlerfreien Run verwenden, auch wenn es schmerzt eine Menge Rechenzeit verloren zu haben.
MfG

Kibo
13.12.2013, 08:20
Hallo Bernhard,

das dürfte dich interessieren: N-Body Simulationen zur Lithospermie (http://nextbigfuture.com/2013/12/seeding-life-on-moons-of-outer-planets.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2Fadvancednano+%28ne xtbigfuture%29)

mfg

Bernhard
13.12.2013, 11:20
das dürfte dich interessieren: N-Body Simulationen zur Lithospermie (http://nextbigfuture.com/2013/12/seeding-life-on-moons-of-outer-planets.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2Fadvancednano+%28ne xtbigfuture%29)
Hallo Kibo,

Astrobiologie beobachte ich eher ein wenig mit, aber es gibt etliche User hier im Forum, die sich dafür interessieren.
MfG

Nachtrag: Ob es auf fernen Welten Mikroben gibt ist mir ehrlich gesagt sogar ziemlich egal, auch wenn in dieser Richtung ziemlich aufwändig geforscht wird. Interessant ist eventuell die Frage ob ein intaktes menschliches Immunsystem mit außerirdischen Mikroben fertig werden würde, wobei da (wie auf der Erde auch) das gesamte Spektrum von harmlos bis zu 100% tödlich denkbar ist. Letztlich sind das aber Restrisiken, welche die Raumfahrt eben so mit sich bringt. Wer forschen will, sollte auch damit leben können, sich mal eine blutige Nase "einzufangen" :) .

Kibo
13.12.2013, 15:48
Ich meinte auch mehr wegen dem Verfahren das die Forscher anwenden

Bernhard
13.12.2013, 17:16
Ich meinte auch mehr wegen dem Verfahren das die Forscher anwenden
Ja, diese Problemstellungen kennt man mittlerweile doch irgendwoher :) . Ich finde es nur schade, dass die Anwendung des mercury-Codes hier auf relativ wenig aktives Interesse getroffen ist. Ein BOINC-Projekt wäre nett gewesen, aber von einer einzelnen Person kaum zu bewältigen. Die Universitäten haben da die Nase noch weit vorne.

Mittlerweile gab es auf arte.tv auch eine interessante Sendung über die Voyager-Sonden. Demnach hatte damals Michael Minovitch entscheidende Beiträge zum Dreikörper-Problem geleistet. Es gibt dazu auch eine umfangreiche Seite: http://www.gravityassist.com/ und vielleicht wird der mercury-code ja auch in dieser Richtung erweitert.
MfG

Bernhard
08.03.2014, 22:16
Hallo zusammen,

nach einiger Zeit möchte ich dieses interessante Thema gerne wieder etwas beleben. Aus den ersten zwanzig bis einundzwanzig Seiten ziehe ich die folgenden Schlüsse:

1.) Der Streit zwischen SRMeister und mir wurde bisher wohl eher verdrängt und noch nicht wirklich gelöst. Von meiner Seite gibt es deswegen das Bedürfnis nach einer Entschuldigung für mein hartes und unhöfliches Verhalten. Teilweise kann ich das jetzt zwar auf eine Überforderung meinerseits schieben, aber das rechtfertigt natürlich nicht das beschriebene Verhalten. Es würde mich freuen Stefan (SRMeister) wenn Du meine Entschuldigung annehmen würdest, auch wenn es reichlich spät kommt.

2.) Der SCATR-Code ist über das sourceforge-Projekt "TheiaSim" noch immer öffentlich zugänglich. Hier hätte ich ebenfalls eine sehr wichtige Bitte, bzw. Frage. Wurde eine Veröffentlichung des Codes explizit erlaubt? Falls Nein, sollte das Projekt umgehend aus dem www entfernt werden!! Bei sourceforge.net ist das mit wenigen Mausklicks zu machen.
MfG

SRMeister
09.03.2014, 16:33
Hallo Bernhard,
kein Problem. Ist vergessen.

Ich kümmere mich mal um das SCATR Problem. Nachtrag: gelöst :)

Bernhard
09.03.2014, 19:29
Ist vergessen.
Danke.


Nachtrag: gelöst :)
Prima :) .

Kibo
17.04.2014, 09:57
Hallo,

Hat jemand zufälligerweise Test-Daten für ein stabiles Sitnikov System (http://de.wikipedia.org/wiki/Sitnikov-Problem)?

mfg

Bernhard
17.04.2014, 15:22
Hallo Kibo,

EDIT: Ich hatte heute Nachmittag viel zu wenig Zeit, um den Wikipedia-Artikel vernünftig zu lesen. Deswegen jetzt eine etwas passendere Antwort:

Bei Deinem Small Planetary Simulator hatten wir das Zweikörperproblem doch bereits simuliert. Du kannst die Startbedingungen von diesen Simulationen verwenden. Mit den Startbedingungen für den dritten Körper kann man dann experimentieren.

SRMeister
19.04.2014, 12:39
Hallo Bernhard, Kibo und alle anderen Interessierten :)

ich hätte noch 'ne Idee für eine Simulation die wir mithilfe des Programms machen könnte.
Die Frage die ich mir gestellt habe ist, wie stabil Planetenbahnen sind, wenn der Stern sich in einem Sternenhaufen bewegt. Sind da überhaupt über Mio oder Milliarden Jahre stabile Planetenbahnen möglich?
Wäre das ein interessanter Ansatz für eine Simulation? Hardwaremäßig sollten normale PCs das schaffen, immerhin hält sich die Anzahl der Objekte in Grenzen.... bspw. 100 Sterne und 10 davon mit 2-5 Planeten.
Die Frage, die dahinter steckt, wäre ob sich Leben dort überhaupt entwickeln kann (ob Planeten lange genug in der Habitablen Zone bleiben).
Grüße

Kibo
19.04.2014, 14:55
Hallo Bernhard, Hallo SRMeister,

Ersteinmal zu Sitnikov:

Ich habe, wie durch bernhard vorgeschlagen die Testdaten für 2 Sonnen als Vorlage genommen. Hier mal die Daten mit leichter Exzentrizität:

KoordX KoordY Koordz ImpulsX ImpulsY ImpulsZ Masse Name dichte /1.15/20130721115300
-7.48e10 0.0 0.0 0.0 2.0e4 0.0 1.99e30 Sonne1 1.408
7.48e10 0.0 0.0 0.0 -2.0e4 0.0 1.99e30 Sonne2 1.408
0.0 0.0 1.0e11 0.0 0.0 0.0 1.0e20 Sitnikovia 1.408

Egal ob mit, oder ohne Exzentrizität, es dauert nur einige Erdjahre, bis der Planet aus dem System fliegt.


Wegen dem Sternhaufen:

Ich habe mal ein bisschen rumprobiert:

KoordX KoordY Koordz ImpulsX ImpulsY ImpulsZ Masse Name dichte /1.15/20130721115300
-6.080091705285974E+08 2.454333708238292E+07 2.193321432139981E+06 2.809726412820165E+00 -1.036343441959919E+01 -4.204860196381065E-02 1.9897E+30 Sun 1.4
-5.331602529851193E+10 1.424323914756870E+10 6.000210156549231E+9 -2.277058581046753E+04 -4.495485791176564E+04 -1.582633849867808E+03 3.3032E23 Mercury 5.4
2.397967758924109E+10 -1.059717457755222E+11 -2.868972017005123E+09 3.388294521475002E+04 7.783094129350907E+03 -1.848596675496016E+03 4.8704E24 Venus 5.2
-1.474370019336122E+11 -2.789279589304088E+10 2.955826247744262E+06 5.079162483215040E+03 -2.939896910566963E+04 4.812093925554706E-01 5.976E24 Earth 5.5
-1.470514277349460E+11 -2.801509364690417E+10 3.730129039033502E+07 5.382156089456466E+03 -2.847733344864282E+04 2.235354455693894E+01 7.3505E22 Moon 3.3
2.035953497078640E+11 -3.456857769669849E+10 -5.736961786047079E+09 4.976094385716297E+03 2.594977520891352E+04 4.218104801061298E+02 6.421E23 Mars 3.9
7.115603707882032E+11 2.013825854433948E+11 -1.677091861778326E+10 -3.715952626588193E+03 1.319564076159422E+04 2.830947269851247E+01 1.8997E27 Jupiter 1.4
-1.396843425883871E+12 -3.381973875783179E+11 6.146826298318255E+10 1.753564063629373E+03 -9.410322369209542E+03 9.449519324100386E+01 5.6882E26 Saturn 1.4
3.003955040895567E+12 2.614531534364399E10 -3.882080718055668E+10 -1.089777236983593E2 6.492185531504123E+03 2.552972796165465E1 8.6875E25 Uranus 1.4
3.826621024919128E+12 -2.346728069113412E+12 -3.986079005702972E+10 2.805108135465661E+03 4.664771972182217E+03 -1.611737087776297E2 1.025E26 Neptune 1.4
4.599506779023092E+11 -4.750680975824932E+12 3.753056255249584E+11 5.510641913253943E+03 -5.401707214265152E-02 -1.536200853856072E+03 1.4717E22 Pluto 1.8
-6.080091705285974E+08 -2000.789279589304088E+10 2.193321432139981E+06 1.809726412820165E+05 0.0 -0.0 1.9897E+30 Sun2 1.4


Bleibt alles stabil.

Bernhard
19.04.2014, 15:19
Hallo zusammen,

hier ein Artikel von Florian Freistetter zum Sitnikov-Problem: http://scienceblogs.de/astrodicticum-simplex/2009/01/05/seltsame-welten-sitnikov-planetenph/

EDIT: beim Sitnikov-Problem bilden die Potentiale der beiden Hauptmassen in der/den zr-Ebene(n) eine Sattelfläche. Bahnen die dort rechnerisch zunächst stabil sind, werden also durch kleine oder kleinste Störungen zu instabilen Bahnen. Sitzen die Planeten dagegen in dem Potentialtopf eines Sterns, so führen kleine Störungen zu keinen wesentlichen Änderungen in der Bahnform. Womit man wohl eine Erklärung dafür hat, warum sich für das Sitnikov-Problem eher die Chaos-Forscher interessieren.

Das Szenario von SRMeister kann man gut mit den Monden eines Planeten des Sonnensystems vergleichen (z.B. Jupiter + 4 galileische Monde). Deren Bewegung wird auch hauptsächlich von dem Planeten bestimmt, den sie umkreisen. Bei offenen Sternhaufen kann man deswegen noch eher stabile Exoplanetenbahnen erwarten, als bei Kugelsternhaufen. Dort sind die Planetenbahnen langfristig gesehen bekanntlich eher instabil, also selten.
MfG

Bernhard
19.04.2014, 21:49
Bahnen die dort rechnerisch zunächst stabil sind, werden also durch kleine oder kleinste Störungen zu instabilen Bahnen.

Man kann das übrigens mit diesen Startdaten:
KoordX KoordY Koordz v_X v_Y v_Z Masse Name dichte /1.15/20130721115300
-7.48e10 0.0 0.0 0.0 21068.5010849826 0.0 1.99e30 Sonne1 1.408
7.48e10 0.0 0.0 0.0 -21068.5010849826 0.0 1.99e30 Sonne2 1.408
0.0 0.0 1.0e10 0.0 0.0 0.0 1.0e20 Sitnikovia 1.408

ganz gut nachstellen. Die Kamera sollte man dazu in der Settings.ini auf die y-Achse legen. Dann sieht man, wie Sitnikovia zuerst hin und her pendelt und nach einigen Perioden das System verlässt. Das Verlassen des Systems ist vorwiegend auf Rundungsfehler zurückzuführen, da die Pendelbewegung für kleine z in die Bewegung eines harmonischen Oszillators übergeht.
MfG

Bernhard
30.10.2014, 08:05
Hier ein Tipp von Herrn Senf (http://astronews.com/forum/showthread.php?7807-Kollisionen-von-Himmelsk%F6rpern&p=106009#post106009): http://arxiv.org/abs/1410.7444 . Die Arbeit macht einen guten Eindruck. Verwendet wurde ein modifizierter mercury-Code.

@SRMeister: Dein Vorschag von weiter oben, bezüglich der Stabilität von Planetensystemen in Sternhaufen ist zwar interessant, aber mit dem mercury-Code leider nicht unmittelbar simulierbar, weil man dort von einer großen Zentralmasse und umlaufenden Körpern mit vernachlässigbarer Masse ausgeht. Kibos Programm ist für Stabilitätsuntersuchungen meiner Meinung nach ungeeignet, weil sich bei dieser Fragestellung die numerischen Fehler über die Laufzeit der Simulation addieren. Der mercury-Code arbeitet diesbezüglich mit einem ganz anderen Formelapparat, der speziell das Langzeitverhalten von isolierten Planetensystemen berücksichtigt.