Sonnensystem: Position der Planeten?

[SRMeister]

Dabei gibt es 2 Probleme: 1. 1000 Körper ist wahrscheinlich für den (N²) Algorithmus zu viel.
2. Mit großen Zeitschritten und wenig Objekten würde das zumindest jetzt funktionieren, das Problem sind die Kollisionen: dazu braucht man Zeitschritte in denen sich der Körper nur einen Teil seines Radius weiterbewegt damit jede Kollision erkannt wird. Lösung: kleine Zeitschritte nehmen (dann kommt man wieder nicht weit) oder adaptive Zeitschritte: Bei Annäherung werden die Zeitschritte immer kleiner; daraus folgt auch für jedes bisherige Verfahren eine höhere Genauigkeit.

 

[Bernhard]

Wie wäre es denn mit diesem Ansatz hier: http://relativ-kritisch.net/forum/viewtopic.php?p=39831#39831. Dort betrachtet man einfach ein Gas unter dem Einfluß der Gravitation. Man könnte dort auch noch eine Zustandsgleichung einbauen, indem man die Dichte mit anderen Größen, wie Druck usw. koppelt.

Für die zeitliche Entwicklung dieses Systems kann man die Lösung in Kugelflächenfunktionen für einen begrenzten Satz an Funktionen entwickeln und dann die Dynamik der Koeffizienten untersuchen. Das ist zwar etwas komplizierter im Ansatz, aber ich denke, dass man damit eigentlich weiter kommen müsste.

Man sollte dazu dann am besten ein neues Thema aufmachen.
Gruß

 

[SRMeister]

Hey Bernhard, ich muss zugeben ich hab nur Bahnhof verstanden
Gase unter dem Einfluss der Gravitation - soviel hab ich verstanden - dies wird in der Forschung angewendet um die Entstehung von Planetenembryos zu simulieren - quasi die Vorstufe von dem was ich wollte. Da entstehen dann Vortices (glaube das sie es so nannten) und durch Reibung und andere Prozesse verklumpt das Gas/Staub der frühen Scheibe schließlich - ab da ist dieses Modell dann kaum noch zu gebrauchen - höchstens um die Migration der Planeten nach Innen durch Reibung mit der Restgas/staub-Scheibe zu erfassen - in einem hybriden Modell.

Ich bin mir aber gänzlich unsicher ob du das überhaupt meintest.

beste Grüße

 

[Bernhard]

Ich bin mir aber gänzlich unsicher ob du das überhaupt meintest.

Hallo Stefan,

so war es schon gemeint. Natürlich interessiert mich die Planetenentstehung aus einer Gas- und Staubwolke auch, und im www gibt es ja auch Simulationen dazu. Ich habe deshalb im AC-Forum einfach mal einen möglichst einfachen Ansatz dazu ohne Materialeigenschaften notiert. Das ergab sich da recht zwanglos aus dem zugehörigen Thema. "Dummerweise" ist das Lösen partieller Differentialgleichungssysteme schon die etwas höhere Kunst und man sollte das momentan wohl einfach den Hauptberuflichen überlassen.

Bei den Kugelflächenfunktionen müsste man den Anfangszustand der "Wolke" auch schon numerisch zerlegen und hätte dabei schon einen recht großen Aufwand. Mit maxima könnte man das aber mal versuchen.

Bei dem N^2-Algorithmus sehe ich momentan auch kein "Land in Sicht", um Gas- und Staubwolken damit vernünftig zu simulieren . Deshalb auch der Vorschlag eines ganz neuen Ansatzes. Ich meine nur, wir (oder besser ich) stehen ja nicht unter Zeitdruck und deswegen kann man doch ruhig auch mal etwas kompliziertere Ansätze ansehen.
Beste Grüße

 

[SRMeister]

Bei den Kugelflächenfunktionen müsste man den Anfangszustand der "Wolke" auch schon numerisch zerlegen und hätte dabei schon einen recht großen Aufwand. Mit maxima könnte man das aber mal versuchen.

Die Kugelflächenfunktionen stellen doch aber nur die Situation an der Oberfläche dar? Wie komme ich gedanklich zu einer komplexen Staubwolke, in der auch noch mehrere große Objekte stören?

Bei dem N^2-Algorithmus sehe ich momentan auch kein "Land in Sicht", um Gas- und Staubwolken damit vernünftig zu simulieren . Deshalb auch der Vorschlag eines ganz neuen Ansatzes. Ich meine nur, wir (oder besser ich) stehen ja nicht unter Zeitdruck und deswegen kann man doch ruhig auch mal etwas kompliziertere Ansätze ansehen.

Das stimmt, Zeitdruck haben wir zum Glück nicht. Momentan sind wir ja auch eher wieder in der Planungsphase. Ich bin ja auch noch unschlüssig, wie es weitergeht.
Angenommen man schreitet auf dem bisherigen Weg voran, so müsste man den N^2 Algo. ersetzen. Dabei können wir uns dann von der Genauigkeit, die wir erreicht hatten, vollkommen verabschieden.
Trotzdem bin ich unsicher, ob sich das Ziel erreichen lässt, deswegen sehr interessiert an Alternativen.

 

[Bernhard]

Die Kugelflächenfunktionen stellen doch aber nur die Situation an der Oberfläche dar? Wie komme ich gedanklich zu einer komplexen Staubwolke, in der auch noch mehrere große Objekte stören?

Man kann zusätzlich die Entwicklungskoeffizienten c_lm als Funktionen vom Radius r und der Zeitkoordinate t betrachten. Die Summation über l läßt man dann von l=0 bis l=N laufen, wobei N die numerische Genauigkeit steuert.

Setzt man diese Entwicklung in die vier partiellen Differentialgleichungen ein, bekommt man ein genähertes, endliches gewöhnliches Differentialgleichungssystem für die vier Entwicklungskoeffizienten c_ilm(r,t) mit i=1,2,3,4.
Gruß

 

[Bernhard]

Setzt man diese Entwicklung in die vier partiellen Differentialgleichungen ein, bekommt man ein genähertes, endliches gewöhnliches Differentialgleichungssystem für die vier Entwicklungskoeffizienten c_ilm(r,t) mit i=1,2,3,4.

Hallo SRMeister,

ich fürchte ich muss da leider wieder etwas "zurückrudern". Sowas (Zitat) funktioniert nämlich nur bei dem Laplace-Operator. Wir haben hier aber eine Divergenz und den Gradienten als separate Operatoren und die Kugelflächenfunktionen sind keine Eigenfunktionen dieser Operatoren. D.h. man kann mit dieser Zerlegung die partiellen DGL (Differentialgleichung) leider nicht unmittelbar in eine gewöhnliche DGL transformieren.

Meinen Vorschlag muss ich deswegen vorerst wieder zurückziehen. Zur Lösung der zitierten partiellen DGL muss man vermutlich doch anders vorgehen .

Ich werde da aber weiter suchen, weil ich die Dynamik der zitierten partiellen DGL durchaus ganz gerne untersuchen/kennenlernen würde...
Gruß

 

[Runzelrübe]

Für 1000 zufällige Objekte stößt man abseits der Geschwindigkeitseinbußen noch auf ein paar weitere Herausforderungen.

Die größte davon ist die zufällige Verteilung. Diese sollte auf einem Generator basieren, der mehrere unabhängige Variablen je Objekt produzieren kann. Eine einfache Schleife über denselben Randomizer hilft da nämlich nicht mehr. Am Ende entstehen sonst Körpereigenschaften aus Variablen, die einer zusammenhängenden Teilmenge einer Reihe gehorchen.

Ich bin aber zuversichtlich, dass wir hier gemeinsam sowohl eine Parallelisierung als auch eine noch bessere Pipelineausnutzung hinbekommen können. Die richtige Synchronisierung der Datengrundlage ist dabei gar nicht so schwierig, wie man sich das allgemeinhin vorstellt. Das richtige Warten und Zusammenführen ist viel entscheidender.

Selbst das Stoßproblem stellt keine allzu große Schwierigkeit dar, da alle Körper in einen durch die Geschwindigkeit seiner Körper gewichteten Octtree eingeordnet werden können und damit statt n^2 Tests durchschnittlich nur noch 8n Tests gemacht werden müssen. Die Kollisionstests schüttelt man am Ende einfach noch aus dem Ärmel hinterher und sie bremsen dann ungefähr genauso stark wie ein Deutschlandfähnchen am Auto.

Ich suche zu den angesprochenen Themen noch etwas raus und stelle die Links dazu hier rein, wenn ich wieder bei mir bin.

Gruß,
Rübe

 

[SRMeister]

Für die zufällige Verteilung hab ich mir folgendes überlegt. Ich hatte in der ersten Version des Programms, bevor ich die Daten der echten Planeten besaß, eine Funktion, die Planeten zufällig verteilt erstellt. Die freien Parameter waren die Entfernung zur Sonne und der Winkel zum Koordinatensystem. Die Funktion berechnete dann die tatsächliche Position (trivial) und die Geschwindigkeit (nicht so trivial) die nötig ist, um den Planeten in einer exakt kreisförmigen Umlaufbahn zu halten.
Man müsste diese Funktion nur um ein paar Parameter erweitern: Exzentrizität und Inklination.
Ich denke, so kann man das von dir angesprochene Problem lösen. Der Randomizer von C++ sollte dafür ausreichen.
Folgendes Thema finde ich interessant.

Die richtige Synchronisierung der Datengrundlage ist dabei gar nicht so schwierig, wie man sich das allgemeinhin vorstellt.

Das stimmt zwar. Die neue C++0x Definition bietet ausgereifte Multithreadingfähigkeiten. Auf diesen würde ich gerne das Programm aufbauen, damit es Plattformunabhängig bleibt (zumindest der Kern)

Das richtige Warten und Zusammenführen ist viel entscheidender.

Solange wir hier von der Nutzung von Multicore Prozessoren reden, ja. Die Parallelisierung mithilfe der SSE SIMD Instructions, funktioniert aber leider nur, wenn die Daten im Speicher linear angeordnet sind, was nur bei O(N^2) der Fall ist.

Selbst das Stoßproblem stellt keine allzu große Schwierigkeit dar, da alle Körper in einen durch die Geschwindigkeit seiner Körper gewichteten Octtree eingeordnet werden können und damit statt n^2 Tests durchschnittlich nur noch 8n Tests gemacht werden müssen.

Bitte definiere Stoßproblem. Wie helfen die Geschwindigkeiten dabei, Kollisionen zu finden?
Nur um mein Problem mit den Kollisionen nochmal deutlich zu machen: Wir benötigen große Zeitschritte, um die Simulation für große Zeiträume fit zu machen. Große Zeitschritte bedeuten, dass sich ähnliche Probleme ergeben, wie beim Tunneln von Quanten. Kollisionen können nur zwischen den Zeitschritten erkannt werden, in etwa vergleichbar mit der Dekohärenz in der Quantenmechanik. Aber ich denke du hast das schon verstanden, nur ich deine Antwort nicht

Ich befinde mich momentan auf der Suche nach einem praktikablen Algorithmus. In [1] werden (u.a. von P. Hut - Miterfinder des Barnes-Hut-Algos) viele aktuell genutzte Varianten diskutiert. Leider geht er nicht auf Integratoren ein, sondern nur auf die Organisation der Daten in Baumstrukturen. Außerdem klammern die Autoren scheinbar gezielt die Variablen-Zeitschritt-Methoden aus, die wir in diesem Projekt aber benötigen um Kollisionen zu erkennen. Trotzdem ist das Dokument ein must-read. Wo die Reise ungefähr hingehen wird (denke ich) ist in [2] relativ gut verständlich erklärt. Allerdings ist der Algo mittlerweile schon etwas angestaubt, es gibt sicher modernere Varianten dessen.

Ich freue mich auch auf deine Links!

Stefan

[1] Gravitational N-body Simulations, M. Trenti (1), P. Hut (2)
[2] Barnes Hut Algorithmus in Deutsch erklärt

 

[SRMeister]

ich fürchte ich muss da leider wieder etwas "zurückrudern". Sowas (Zitat) funktioniert nämlich nur bei dem Laplace-Operator. Wir haben hier aber eine Divergenz und den Gradienten als separate Operatoren und die Kugelflächenfunktionen sind keine Eigenfunktionen dieser Operatoren. D.h. man kann mit dieser Zerlegung die partiellen DGL (Differentialgleichung) leider nicht unmittelbar in eine gewöhnliche DGL transformieren.

Ich hab zwar wieder kein Wort verstanden. Aber bitte schau dir in dem Link [1] von eben unbedingt Abschnitt 3.4 an ( am Besten aber das ganze Doc *daumenhoch*)
Ich vermute das kommt dem ziemlich nahe und finde das auch sehr interessant und bedenkenswert.

Ich werde da aber weiter suchen, weil ich die Dynamik der zitierten partiellen DGL durchaus ganz gerne untersuchen/kennenlernen würde...
Gruß

Da sind wir einer Meinung!

grüße an Alle!

 

[Bernhard]

Aber bitte schau dir in dem Link [1] von eben unbedingt Abschnitt 3.4 an ( am Besten aber das ganze Doc *daumenhoch*)

Hallo SRMeister,

ich habe den Preprint gerade mal überflogen und würde das "Ding" erst mal im Archix lassen. Vermutlich muss es solche Zusammenstellungen auch geben, um die Gedanken der zugehörigen Autoren wieder in's Lot zu bringen. Der Leser muss dagegen aufpassen, dass das Abendessen dort bleibt, wo es hingehört. Sorry, für die drastischen Worte, aber sie entsprechen momentan meiner ganz persönlichen Wahrnehmung, was nicht heißen muss, dass man solche Preprints grundsätzlich nicht lesen sollte. Ich bitte dennoch darum solche Themen den Assistenten an den Unis zu überlassen. Die werden schließlich dafür bezahlt, sich so "Zeugs" reinzuziehen.

Sehr interessant finde ich dagegen den Barnes-Hut-Algo. Freundlich und übersichtlich dargestellt mit interessanten Ideen und sehr überzeugenden Resultaten. Klares "Thumbs up". Mein Vorschlag: genau so was umsetzen. Zu den Kollisionen der einzelnen Körper könnte ja vielleicht Runzelrübe etwas weiter helfen. Die können wir IMO nicht einfach so unter den Teppich kehren, ohne an Seriosität zu verlieren .

So damit habe ich jetzt auch mal meinen Ärger des Tages hier abgelassen. Ich steh zur Zeit leider etwas unter Druck wegen der Übersetzung für TED. Die möchte ich bis zum Wochenende fertig haben und die hat aktuell definitiv Vorrang vor dem N-Körper-Problem.

Dank an Herrn Deiters für das neue Unterforum.
Gruß

 

[Runzelrübe]

Wie helfen die Geschwindigkeiten dabei, Kollisionen zu finden?

Es ist bereits spät, aber ich möchte wenigstens noch in ein paar Sätzen erklären, was es damit auf sich hat.

Erster Ansatz) ungewichteter Octtree:

Wir können den gesamten Raum, in dem die Körper umherschwirren sollen, in acht gleiche Teile unterteilen. Jeder Körper wird sich ja in erster Linie innerhalb der Hülle um alle Körper befinden. Wir setzen in jede der drei Raumrichtungen mal ganz stupide zwei parallele Ebenen um die Hülle, so dass sie einen Quader ergeben, der alle Körper einschließt. Nun achteln wir den Quader - eine Halbierung je Dimension. Betrachten wir die Szene, so können wir zwei Zustände je Körper unterscheiden. Ein Körper befindet sich entweder vollständig innerhalb eines Achtels oder aber er schneidet eine der eben gezogenen Grenzen. Schneidet er eine Grenze, bleibt er der schnittfreien BoundingBox zugeordnet, befindet er sich jedoch vollständig innerhalb eines der acht Knoten, wird er diesem zugeordnet. Wir teilen nun jedes der Achtel immer nur dann weiter, wenn sich mehr als ein Objekt in ihm befindet oder bis wir ein anderes, durch uns festgelegtes Kriterium erreichen.

Was haben wir dadurch erreicht? Nunja, in erster Linie schonmal eine sehr schnelle Möglichkeit, die allernächsten Nachbarn zu finden, ohne uns die Nachbarn je Objekt merken zu müssen.

Zweiter Ansatz) Gewichteter Octtree

Nehmen wir den Baum aus dem ersten Ansatz. Wir berechnen ja in jedem Zeitschritt für jeden Körper seinen Gravitationseinfluss auf die umgebenen Objekte. Für jeden Körper ergibt sich dabei eine neue resultierende Geschwindigkeit. Die Körper bewegen sich weiter. Statt nun jeden Körper auf Kollisionen mit anderen zu testen, schauen wir uns die Bewegung innerhalb unseres Bezugssystems an. Bis eben waren die Positionen der Körper Ist-Werte in unserem Baum. Das wird sich nun ändern. Welche Aussage können wir denn bereits vorab treffen? Nun, wenn überhaupt, dann können sich nur diejenigen Sterne treffen, die sich entweder innerhalb derselben Boundingbox befanden oder die ihre bisherige BoundingBox oder die der direkten Eltern schneiden würden. Wir werden nun zwei Dinge tun. Wir legen um jeden Körper eine weitere, lokale BoundingBox, die die Raumanteile in Bewegungsrichtung widerspiegelt, wenn wir einen großen Zeitschritt nehmen. Nur dann, wenn sich die Bereiche zweier Körper überlappen, kann überhaupt eine Kollision innerhalb derselben BoundingBox stattgefunden haben. Ebenfalls nur dann, wenn eine dieser BBoxen ihre umschließende BBox trifft oder schneidet, muss bei den Nachbarn geprüft werden. Und nur, wenn solch ein Risiko identifiziert wird, muss der Zeitschritt runtergesetzt oder anders verfahren werden. Ansonsten hat da nix und niemand etwas getroffen. Und aus Erfahrung landen so ca. 2 bis 3 Objekte in einem Knoten.

Ein sinnvolles Kriterium wäre demnach noch, dass die Ausdehnung der kleinsten BBox so gewählt wird, dass sie nicht kleiner ist als der durchschnittliche Weg des Zeitschritts.

Falls das jetzt doch zuviel Bahnhof gewesen sein sollte, ich schau mir das morgen nochmal an.

 

[Hirschi]

Huhu
Auch wenn ich von den Details der Sache wenig verstehe, möchte ich vielleicht doch einen Tip in Bezug auf Fortführung der Simulation und Statistik geben. Ich gehe auch davon aus, dass hier die Verklumpung von Staub gemeint ist.
Im Groben dreht sich ja vieles (gerade auch Runzelrübes Ansatz) um Wahrscheinlichkeiten.
Dein gewichteter Octtree ist mMn der richtige Ansatz. Warum? Wenn man die Simulation fortführt mit der nächsten Stufe, 2 verschmolzene Körper fangen 1 verbleibenden ein und jede andere weitergerechnete Konstellation, dann muss! man sowieso gewichten. Die Feinheit des Gewichtungsrasters ist nur abhängig von der gewollten Genauigkeit oder verfügbarer Rechenleistung.
Die relative Geschwindigkeit der benachbarten lokalen BoundingBoxes spielt eine große Rolle. Trägheit ist das Stichwort.
Ungewichtet würde es immer nur zu gleichen lokalen Ausgangsbedingungen führen, obwohl sich subglobal und global schon ganz andere Bedingungen (Geschwindigkeit, Wahrscheinlichkeit einer Massendominanz, Wahrscheinlichkeit eines leeren Achtels) gebildet haben müssen.

 

[SRMeister]

Hallo Bernhard,

Sorry, für die drastischen Worte, aber sie entsprechen momentan meiner ganz persönlichen Wahrnehmung

OKAY
Ich konnte jedenfalls einiges an wichtigen Infos rausziehen (komme gleich drauf) außerdem, P. Hut, der "Miterfinder" des Barnes-H-As, hat das Preprint geschrieben! Aber das muss ja nichts heissen.

Sehr interessant finde ich dagegen den Barnes-Hut-Algo.

Ja das stimmt. Interessant ist das, informativ und trotzdem verständlich geschrieben.
Allerdings enthält der Artikel keine Hintergrundinformationen, wozu der BHA geeignet ist und wozu nicht.

... die hat aktuell definitiv Vorrang vor dem N-Körper-Problem.

Kein Problem, ich mach auch ganz langsam im Moment (Erstmal Planen)

So jetzt zu dem arxiv Artikel. Dort wird genauestens darauf eingegangen, wozu die verschiedenen Algos brauchbar sind und wozu nicht. Beispielsweise ist der BHA *nicht besonders* gut geeignet für die Simulation der Entstehung von Planeten, sondern eher für Kosmologie, Kollision von Galaxien, Dunkle Materie Verteilung und sowas. Ich unterstelle dem Herrn Hut mal, dass er weis, wovon er redet.
Er sagt noch, dass bei Galaxien usw. Fehler bei Close Encountern entstehen können, die dazu führen, dass überproportional (unrealistisch) viele Sterne aus dem System geschleudert werden, oder sich in Binärsysteme gegenseitig binden. Er gibt dazu einen sehr interessanten Ausweg, der mich irgendwie stark an MOND erinnert hat: Er dämpft die Gravitation auf kurzen Skalen durch Einführung eines zusätzlichen Terms. Was passiert, wenn man das nicht beachtet, kann man direkt sehen, wenn man im 2. Link (hier nochmal) sich ganz unten das Video anschaut: viele Sterne werden raus gekickt, ergo fehlt dem BHA dort, dieser Term.
Leider, und das fehlt mir an dem Text, wird nicht auf Integratoren sowie auf Planetenentstehung eingegangen, es wird nur mehrmals gesagt "dieses und jenes ist dafür ungeeignet" aber Alternativen werden nicht genannt.
Deshalb musste ich mich weiter durch den Arxiv Dschungel kämpfen. Viel uninteressantes, wenig brauchbares findet man da. BTW hab ich auch keine Augen dafür ob ein Artikel "gut oder schlecht" geschrieben ist, ich seh' immer nur, ob ich das dort gesagte Wissen gebrauchen kann/verstehe. Mir fehlt da wohl eine Windung dafür

Ein Preprint, auf dem ich derzeit etwas hängengeblieben bin, ist dieser hier.
Einige wichtige Essenzen daraus:
-der BS-Integrator wird als extrem langsam eingestuft (daraus habe ich erstmal nur geschlossen dass es Methoden geben muss, von denen ich noch keine Kenntniss hatte)
- Die "grobe" Planeten-Flugbahn wird mithilfe von sogenannten "Symplectic Integrators" berechnet. Irgendwie nehmen die analytische Keplerbahnen. Macht wahrscheinlich Sinn, da die vielen kleinen Körper fast "Probekörper" in der fast statistischen Masseverteilung sind. Dann bleiben nurnoch Close Encounters und Kollisionen als Sonderfälle
- EXTREM wichtig sind variable Zeitschritte. Generell braucht ein langsamerer (von der Sonne entfernterer) Körper weniger Genauigkeit, ein sonnennahes Objekt feinere Zeitschritte. Sonst verschwendet man zuviel Rechenleistung. Bei Kollisionen sind die sowieso notwendig.


Hallo Rübe,

Erster Ansatz) ungewichteter Octtree:
...

Soweit alles klar, das entspricht ja weitgehend dem BHA.

Zweiter Ansatz) Gewichteter Octtree
Falls das jetzt doch zuviel Bahnhof gewesen sein sollte, ich schau mir das morgen nochmal an.

Nein, dass war diesmal gut verständlich. Das erinnert mich sehr an die Methoden des Raytracing. Von dort könnte man evtl sogar Funktionen abkupfern. Macht nun aber aufjedenfall Sinn und ist absolut berücksichtigt.

Hi Hirschi,

ich geb dir erstmal keine Antwort sondern hoffe dass Runzelrübe dass übernimmt, da ich mir nicht ganz sicher bin ob ich dich richtig verstehe.

Grüße an Alle!

 

[Bernhard]

OKAY
Ich konnte jedenfalls einiges an wichtigen Infos rausziehen (komme gleich drauf) außerdem, P. Hut, der "Miterfinder" des Barnes-H-As, hat das Preprint geschrieben!

Hallo SRMeister,

es kam einfach ein bisschen zuviel auf einmal.

Ich werde mich voraussichtlich aus dem Thema hier jetzt sowieso mehr heraushalten als vorher, weil ich die direkte Planetenenstehung nicht zu meinen Kerninteressen rechne. Für das numerische Lösen von partiellen DGL habe ich schon eher ein Ohr und ein Auge offen, aber das ist halt auch ein 'irre' weites Feld, so dass man so etwas nebenher nur ansatzweise betreiben kann.
Gruß

 

[SRMeister]

Ich weiß auch grad nicht so richtig wie es weitergehen soll. Ich sehe ehrlich gesagt nicht, dass ich selbst das Projekt angehen kann.(Planetenentstehung)
Ich hab die letzte Zeit erkundet was nötig wäre und festgestellt: es ist zu viel. Scheitern tu' ich an der Mathematik und Physik.

Also von vorne: Was könnte man realistischerweise machen?
- Kosmologie (Kollision von Galaxien, Dunkle Materie Effeke auf Galaxien, Galaxienhaufenbildung .... ) gibts schon
- Sternkarten - gibt es schon einige
- Integration unseres Sonnensystems - gibts schon von der NASA

Nur mal so ein paar Ideen:
- Radial Velocity Simulator
- Transit Simulator
- ...

*???*

Stefan

 

[Bernhard]

Also von vorne: Was könnte man realistischerweise machen?

Hallo Stefan,

mein Vorschlag wäre: vor allem nichts überstürzen. Open-Source-Software ist ein Thema in Entwicklung und muss meiner Erfahrung nach von sehr vielen Usern unterstützt werden, um überleben zu können. Linux ist da das beste Beispiel. Das wird vor allem als Gegenpol zu Windows von sehr vielen Freunden und Liebhabern in ihrer Freizeit gepflegt, gewartet, weiterentwickelt und gesponsort.

Man muss also sehen und abwarten, was die Leser haben wollen und was gebraucht wird. Meine öffentlichen Projekte habe ich mittlerweile alle wieder vom Netz genommen, weil das Feedback einfach ungenügend und entäuschend war. Letztlich erspart mir das aber auch eine Menge freudloser Arbeit.

Zusätzlich kann man das Unterforum hier auch dazu nutzen, um generell Tipps und Erfahrungen mit freier und kostenpflichtiger Software zur Astronomie auszutauschen.
Gruß

 

[UMa]

Hallo Stefan,

Ich weiß auch grad nicht so richtig wie es weitergehen soll. Ich sehe ehrlich gesagt nicht, dass ich selbst das Projekt angehen kann.(Planetenentstehung)
...
Also von vorne: Was könnte man realistischerweise machen?

die jetzige Version, Newton-Dynamik mit BS-Integrator, könnte die Veränderung der Bahnen der Planeten berechen, die Auftreten würden, falls ein gelber, roter, weißer, brauner Zwerg oder umherfliegender Planet durch das Sonnensystem fliegen würde. Ähnliches wurde schon mal hier diskutiert
http://www.astronews.com/forum/show...Skript-Destabilisierung-eines-Planetensystems.
Es wäre sicher interessent in Abhängigkeit vom Masse, Geschwindigkeit und Abstand des durchfliegenden Objektes die Auswirkungen auf die Bahnen der Planeten des Sonnensystem zu untersuchen. Wie verändern sich die Bahnen der Planeten? Werden Planeten ausgeworfen, kollidieren sie, oder gar vom eindringenden Objekt eingefangen?

Man müsste lediglich zum Sonnensystemsimulator eine weitere Masse hinzufügen, welche in vielleicht 1000AE startet, damit die Anfangsauswirkungen nicht so groß sind, aber die Rechenzeit noch im Rahmen bleibt. Dann ist eine geeignete Geschwindigkeit von sagen wir zwischen 5 und 100 km/s zu wählen, wobei die Richtung ungefähr auf die Sonne zeigt.

Grüße UMa

 

[Bernhard]

Man müsste lediglich zum Sonnensystemsimulator eine weitere Masse hinzufügen, welche in vielleicht 1000AE startet, damit die Anfangsauswirkungen nicht so groß sind, aber die Rechenzeit noch im Rahmen bleibt. Dann ist eine geeignete Geschwindigkeit von sagen wir zwischen 5 und 100 km/s zu wählen, wobei die Richtung ungefähr auf die Sonne zeigt.

Nett wäre doch ein Youtube-Filmchen mit einem möglichst anschaulichen, bzw. spannenden Szenario. Das wäre dann ein echtes Astronews-Video. Man müsste dazu nur jemanden (ich werde das aber nicht machen; bin momentan viel zu erkältet für Sowas) finden, der den Code für die grafische Darstellung inklusive schwarzem/gestirntem Hintergrund zur Verfügung stellt.
Gruß

 

[Ich]

Nett wäre doch ein Youtube-Filmchen mit einem möglichst anschaulichen, bzw. spannenden Szenario.

!uribin ;-)
Visualisierung ist so ne Sache. Ich hab vor Jahren mal was in OpenGL geschrieben, so mit Planeten und dazwischenrumfliegen. Dabei hab ich erst bemerkt, wie leer das All so ist: nichts außer Schwarz und ab und zu ein kleiner Punkt. Schöner wird's, wenn man die Planeten um Faktor zehn oder so aufbläst.
Aber ich bin kein Programmierer, den Code von damals kann sich keiner anschauen. Ich bastle nur, bis das Prinzip bewiesen ist, und dann reicht's mir wieder.