TheiaSim

Bynaus schrieb:

Ein möglicherweise wichtiger Punkt wäre, dass man für jedes (?) "fixe" Objekt im Sonnensystem (Planeten, Monde, grosse Asteroiden) wählen kann, ob man ihre Bahnen gemäss gravitativen Interaktionen rechnen will, oder ob man sie einfach als gravitativ auf die masselosen Teilchen agierende, aber nicht untereinander interagierende, "Zielkörper" auf festgelegten Bahnen bewegen will.

Zum Vergrößern anklicken....

Nur so bleibt die Fehlersuche auch meiner Meinung nach im Programm übersichtlich, denn es macht bei den Formeln schon einen recht großen Unterschied, ob der Körper ein gravitatives Feld erzeugt oder nicht. Im SCATR-Code ist das (so weit ich es überblicken kann) sehr deutlich getrennt und in den BS-Code habe ich ja unter "Protest" von SRMeister ebenfalls so eingebaut.

Weiter wäre es wichtig, dass man für jedes "fixe" Objekt (gem. oben) einzeln festlegen kann, bei welcher Distanz ein masseloses Teilchen aus der Simulation entfernt werden soll. Bei der Erde ist z.B. eine Distanz von etwa 1000 km zur Oberfläche ein guter Wert, weil man da annehmen kann, dass die Bahn von masesarmen Teilchen durch die Interaktion mit der Exosphäre stark verändert wird (stärker, als man von der Gravitation alleine vermuten würde). Für einige der Projekte, die ich angedacht habe, wäre es auch wichtig, wenn man Geschwindigkeitsvektor und -richtung zum Zeitpunkt der Annäherung an die Erdoberfläche auf 1000 km (also dann, wenn das Teilchen aus der Simulation entfernt wird) speichern könnte.

Zum Vergrößern anklicken....

In den BS-Code habe ich das so eingebaut. Man kann dort einen kritischen Radius für jeden massebehafteten Körper angeben, ab dem eine Kollision stattfindet.

Der letzte Punkt, der mir wichtig wäre, ist wohl bereits weitgehend realisiert: Ein Input-File, in dem die Positionen und anfänglichen Geschwindigkeiten (und Vektoren) aller zu simulierenden Teilchen gespeichert sind.

Zum Vergrößern anklicken....

Bei dem SCATR-Code ist das genau so gemacht. Allerdings kann man bei den masselosen Testkörpern auch gut darauf verzichten, weil diese Startbedingungen in unserem Fall sehr stark von der Startbedingung der Erde abhängen. Die zugehörigen Listen werden deswegen bei sehr vielen Testkörpern (>100) sehr wenig aussagekräftig und wären ledigleich als Detailinformation für die Dokumentation wichtig. Ich persönlich fände hier einen Eingabeparameter für die Anzahl der masselosen Trümmerteile als ausreichend. Um zusätzlich den Streuwinkel als Eingabeparameter zu bekommmen müsste man den SCATR-Code weiter anpassen und das macht dann wieder eine Fortran-Compiler notwendig, womit wir wieder bei den technischen Problemen wären. Man könnte eventuell auch mal versuchen hier Crowdfunding anzuwenden, um an eine Intel-Lizenz zu kommen. Mit 1900 Dollar wären wir aus dem Schneider.

Der erweiterte Bulirsh-Stoer-Algorithmus liefert mittlerweile auch über eine Million Jahre ganz interessante Ergebnisse. Bei einer Schrittweite von 10 Tagen braucht das Programm nur einige Minuten für die Berechnung.

Zum Vergrößern anklicken....

Das klingt doch schon ganz gut.

Nur so bleibt die Fehlersuche auch meiner Meinung nach im Programm übersichtlich, denn es macht bei den Formeln schon einen recht großen Unterschied, ob der Körper ein gravitatives Feld erzeugt oder nicht.

Zum Vergrößern anklicken....

Nicht dass hier Missverständnisse entstehen: ein gravitatives Feld sollte der Körper natürlich immer erzeugen (dh, er sollte immer eine Wirkung auf die masselosen Teilchen und die Planeten mit langen Umlaufszeiten haben). Aber seine Bahn sollte, sobald die Schrittweite sich seiner Umlaufzeit annähert (innerhalb etwa einer Grössenordnung: also bei 10 Tagen ist es für Merkur und den Mond bereits recht gefährlich, während die Venus wohl nicht so sehr unter diesem Problem "leidet"), nicht mehr durch Integration berechnet, sondern vorgegeben werden: sonst passiert eben das, dass Merkur und Mond aus dem System geworfen werden. Wir müssen so verfahren, weil wir ja weiterhin berechnen wollen, was mit den Teilchen passiert, die in der Nähe von Merkur rumdümpeln - deshalb können wir Merkur nicht einfach aus der Simulation entfernen.

Man kann dort einen kritischen Radius für jeden massebehafteten Körper angeben, ab dem eine Kollision stattfindet.

Zum Vergrößern anklicken....

Sehr schön. Wie gesagt wäre es für spätere Projekte gut, wenn man auch wüsste, an welcher Stelle der Planet bzw. der gewählte Abstand getroffen wird und in welche Richtung das Teilchen sich bewegt.

Allerdings kann man bei den masselosen Testkörpern auch gut darauf verzichten, weil diese Startbedingungen in unserem Fall sehr stark von der Startbedingung der Erde abhängen.

Zum Vergrößern anklicken....

Ja, in dem Fall. Aber in anderen denkbaren Simulationen, die man mit einem solchen Programm machen könnte, sieht es vielleicht anders aus. Ausserdem: wenn man für jedes Teilchen einzeln eine Position und Geschwindigkeit festlegt, kann man dieses Teilchen später (angenommen, es zeigt ein interessantes Ergebnis) "klonen" und variieren, um eine grössere Auflösung für dieses Ergebnis zu bekommen, ohne dass man dabei Abermillionen von uninteressanten Teilchen simulieren muss. Also sagen wir, ein Teilchen trifft den Mars, dann können wir in einem anschliessenden Durchlauf dieses Teilchen sagen wir hunderttausend Mal klonen und seine Anfangsparameter nur ein klein wenig variieren, um eine bessere Beschreibung der Wahrscheinlichkeit eines Mars-Treffers zu erhalten.

Man könnte eventuell auch mal versuchen hier Crowdfunding anzuwenden, um an eine Intel-Lizenz zu kommen. Mit 1900 Dollar wären wir aus dem Schneider.

Zum Vergrößern anklicken....

Hm, ich wäre erstaunt, wenn das Erfolg hätte... Was sind denn, gesamthaft gesehen, die Optionen und Probleme? Ich habe mittlerweile etwas die Übersicht verloren...

Bynaus schrieb:

Sehr schön. Wie gesagt wäre es für spätere Projekte gut, wenn man auch wüsste, an welcher Stelle der Planet bzw. der gewählte Abstand getroffen wird und in welche Richtung das Teilchen sich bewegt.

Zum Vergrößern anklicken....

Ich werde versuchen, da mal etwas Brauchbares in den BSSI-Code einzubauen. (BSSI = Bulirsh-Stoer-Symplectic-Integrator)

Ja, in dem Fall. Aber in anderen denkbaren Simulationen, die man mit einem solchen Programm machen könnte, sieht es vielleicht anders aus. Ausserdem: wenn man für jedes Teilchen einzeln eine Position und Geschwindigkeit festlegt, kann man dieses Teilchen später (angenommen, es zeigt ein interessantes Ergebnis) "klonen" und variieren, um eine grössere Auflösung für dieses Ergebnis zu bekommen, ohne dass man dabei Abermillionen von uninteressanten Teilchen simulieren muss. Also sagen wir, ein Teilchen trifft den Mars, dann können wir in einem anschliessenden Durchlauf dieses Teilchen sagen wir hunderttausend Mal klonen und seine Anfangsparameter nur ein klein wenig variieren, um eine bessere Beschreibung der Wahrscheinlichkeit eines Mars-Treffers zu erhalten.

Zum Vergrößern anklicken....

OK

Was sind denn, gesamthaft gesehen, die Optionen und Probleme? Ich habe mittlerweile etwas die Übersicht verloren...

Zum Vergrößern anklicken....

Für 1900 $ bekäme man eine uneingeschränkt nutzbare Intel-Lizenz für Privatanwender.

Bernhard schrieb:

Ich werde versuchen, da mal etwas Brauchbares in den BSSI-Code einzubauen. (BSSI = Bulirsh-Stoer-Symplectic-Integrator)

Zum Vergrößern anklicken....

Ich habe eben eine Funktion eingebaut, welche bei jedem Schritt die Mindestdistanz der Trümmer zu den Planeten ausrechnet. Bei einer Rechnung über 10k Jahre und 20 Testkörpern fliegt beispielsweise ein Testkörper mit einer Entfernung von nur 16 Jupiterradien an Jupiter vorbei. 2 der 20 Testkörper verlassen das Sonnensystem und die 5 massiven Trümmer sammeln sich im Bereich 0.4 - 1.5 AE. Ein anderer Testkörper fliegt in einem Abstand von nur 40 Sonnenradien an der Sonne vorbei usw.

Ich könnte als nächstes die Schrittweite anpassen. Wenn sich z.B. ein Testkörper einem Planeten kleiner als einem bestimmten kritischen Wert nähert, könnte ich die Schrittweite von 10 Tagen auf einen Tag senken, um die genaue Mindestdistanz zum Planeten zu bestimmen. Während dieser Phasen mit erhöhter Genauigkeit könnte der Vorbeiflug bzw. die Kollision mit erhöhter Genauigkeit analysiert und die zugehörigen Daten (Nummer des Testkörpers, Position, Geschwindigkeit, Winkel zwischen den Bahnen usw.) abgespeichert werden.

EDIT: Habe mich leider bei der Schrittweite etwas vertan, so dass die Simulationszeit nur 10k Jahre anstelle von 100k Jahre beträgt.

Bernhard, wie hast du das Problem mit den Testpartikeln bei dem BSSI gelöst? Soweit ich das verstehe lassen sich masselose Partikel nicht trivial in eine symplektische Form bringen, da es zu Unendlichkeiten kommt.

Bynaus, eigentlich sollte soetwas nicht passieren:

Nicht dass hier Missverständnisse entstehen: ein gravitatives Feld sollte der Körper natürlich immer erzeugen (dh, er sollte immer eine Wirkung auf die masselosen Teilchen und die Planeten mit langen Umlaufszeiten haben). Aber seine Bahn sollte, sobald die Schrittweite sich seiner Umlaufzeit annähert (innerhalb etwa einer Grössenordnung: also bei 10 Tagen ist es für Merkur und den Mond bereits recht gefährlich, während die Venus wohl nicht so sehr unter diesem Problem "leidet"), nicht mehr durch Integration berechnet, sondern vorgegeben werden: sonst passiert eben das, dass Merkur und Mond aus dem System geworfen werden

Zum Vergrößern anklicken....

und meinst du mit "vorgegeben", dass man die Planetenbahnen durch reine Keplerbahnen abschätzt?

Für 1900 $ bekäme man eine uneingeschränkt nutzbare Intel-Lizenz für Privatanwender.

Zum Vergrößern anklicken....

Es gäbe die Option: Der Intel compiler ist für Linux kostenlos. Alternativ wäre ich immernoch an einer kostenlosen Windows Lösung interessiert, vielleicht mit einem GNU Fortran Compiler.

SRMeister schrieb:

Bernhard, wie hast du das Problem mit den Testpartikeln bei dem BSSI gelöst? Soweit ich das verstehe lassen sich masselose Partikel nicht trivial in eine symplektische Form bringen, da es zu Unendlichkeiten kommt.

Zum Vergrößern anklicken....

Ich sehe momentan kein Problem darin die normalen Hamilton-Gleichungen zu verwenden. Die Massen der Testkörper kürzen sich dort heraus. Man kann also den gleichen Algorithmus für die Testkörper verwenden, sofern man berücksichtigt, dass diese Testkörper kein gravitatives Feld erzeugen.

BTW: Die variable Schrittweite erscheint mir momentan recht interessant. Aktuell läuft bei mir im Hintergrund eine Version, bei der jeder Planet (inklusive Sonne) eine Art kritische Hülle von 70 Jupiterradien besitzt. Sobald diese Hülle von einem Trümmerteil durchstoßen wird, wird die Schrittweite von einem Tag auf 8640s und ab 7 Jupiterradien auf 864s gesetzt. Die Ergebnisse einer Simulation über 1000 Jahre mit 120 Trümmerteilen zeigen allerdings, dass die Zeitschritte vermutlich immer noch zu groß gewählt sind.

@SRMeister:

Bynaus, eigentlich sollte soetwas nicht passieren:

Zum Vergrößern anklicken....

Du meinst die Destabilisierung der Bahnen? Warum nicht? Bei so grossen Schrittweiten relativ zur Bahn können sich (würde ich jetzt vermuten) kleine Rundungsfehler zu beträchtlichen "Kräften" auswachsen, die die Bahn verändern. Dass man Bahnen mit Umlaufzeiten in der Nähe der Schrittweite von der Simulation ausklammert, ist gang und gäbe (sieht man auch in anderen Arbeiten regelmässig). Aber kann auch sein, dass ich da etwas verwechsle.

und meinst du mit "vorgegeben", dass man die Planetenbahnen durch reine Keplerbahnen abschätzt?

Zum Vergrößern anklicken....

Ja. Das ist zumindest nicht grob falsch.

@Bernhard:

Aktuell läuft bei mir im Hintergrund eine Version, bei der jeder Planet (inklusive Sonne) eine Art kritische Hülle von 70 Jupiterradien besitzt.

Zum Vergrößern anklicken....

Wäre es da nicht besser, die kritische Hülle von der Masse & Entfernung des Planeten abhängig zu machen? Mit anderen Worten: die Hill-Sphäre zu verwenden?

Betreffend variable Schrittweite: Wird denn da das ganze Programm auf diese langsame Schrittweite heruntergefahren? Oder stoppt man das Programm und klammert das Trümmerteil aus, übergibt es an eine andere Instanz, die mit geringer Schrittweite den Vorbeiflug berechnet, die Endposition zurückgibt und dann mit normaler Geschwindigkeit die Simulation fortsetzt?

Bynaus schrieb:

Wäre es da nicht besser, die kritische Hülle von der Masse & Entfernung des Planeten abhängig zu machen? Mit anderen Worten: die Hill-Sphäre zu verwenden?

Zum Vergrößern anklicken....

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.

Betreffend variable Schrittweite: Wird denn da das ganze Programm auf diese langsame Schrittweite heruntergefahren? Oder stoppt man das Programm und klammert das Trümmerteil aus, übergibt es an eine andere Instanz, die mit geringer Schrittweite den Vorbeiflug berechnet, die Endposition zurückgibt und dann mit normaler Geschwindigkeit die Simulation fortsetzt?

Zum Vergrößern anklicken....

An eine isolierte Betrachtung des lokalen Zweikörperproblems habe ich auch schon gedacht. Mir ist dabei nur nicht klar in welchem Bezugssystem man diese Rechnung dann durchführt.

Bin momentan ziemlich erkältet, was zu Verzögerungen führen wird. Das Buch von Danby ist heute aber eingetroffen.

Also wie ich das sehe, müssten wir den SCATR so modifizieren, dass Mond und Merkur durch reine Keplerbahnen abgeschätzt werden. Dann kann man 1/10tel der Periodendauer von Venus als Schrittweite nehmen und wir sind auf der sicheren Seite.
Korrekt?

SRMeister schrieb:

Also wie ich das sehe, müssten wir den SCATR so modifizieren, dass Mond und Merkur durch reine Keplerbahnen abgeschätzt werden. Dann kann man 1/10tel der Periodendauer von Venus als Schrittweite nehmen und wir sind auf der sicheren Seite.
Korrekt?

Zum Vergrößern anklicken....

@SRMeister: Ich denke, Du legst hier den Finger genau in die wunden Stellen des SCATR-Projektes, denn meiner Meinung nach ist das SCATR-Projekt viel zu schlecht dokumentiert, um damit sinnvoll arbeiten zu können. Sogar mit dem Buch von Danby wird praktisch überhaupt nicht klar, welche Ideen die Entwickler genau verfolgt haben, weswegen ich dieses Projekt vorerst nicht weiter unterstützen will. Auch wenn es mir selber leid tut, aber ohne weitere Dokumentation ist das Thema für mich erst mal erledigt...

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.

SRMeister schrieb:

Möglicherweise könnte man den SCATR anpassen.

Zum Vergrößern anklicken....

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.

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.

pmvstrm schrieb:

Ein kurzes Hello Fortran programm konnte ich damit erstellen und laufen lassen.

Zum Vergrößern anklicken....

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.

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.

pmvstrm schrieb:

Wenn ja ist es GNU

Zum Vergrößern anklicken....

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ß

Erdmond: Neue Impaktsimulationen

Hallo, ihr fleißigen Programmierer!
Habt ihr schon von den neuen Simulationen von der Harvard University gelesen: Erdmond - Neue Impaktsimulationen

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.

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?

SRMeister schrieb:

Kann man nicht also bei unserem Problem den Mond weglassen?

Zum Vergrößern anklicken....

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.

Bernhard schrieb:

Hallo pmvstrm,
Ohne Debugger kommt man bei diesem Projekt definitiv nicht weiter.

Zum Vergrößern anklicken....

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 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ß

Zum Vergrößern anklicken....

Dann ist es eh egal.