Sonnensystem: Position der Planeten?

Bernhard

Registriertes Mitglied
Hi SR,

die grafische Oberfläche ist ein wirklich nettes Feature und die kleinen Kringel mit und ohne Farbe machen sich IMO ebenfalls recht gut. Trotzdem hätte ich noch ein paar Wünsche:

a) So weit ich weiß, wird unser Planetensystem üblicherweise von oben gezeigt, so dass die Planeten gegen den Uhrzeigersinn, also in mathematisch positivem Sinn, drehen.

b) Die vier größten Asteroiden Ceres, Pallas, usw. gehören von der Position her eigentlich zwischen Mars und Jupiter. Diesen Fehler habe ich in das Programm gebracht, weil es bei der Konsolenanwendung eigentlich keine Rolle spielt. Bei der grafischen Darstellung ist die korrekte Reihenfolge dagegen schon wichtig, weil sich der Normalbenutzer lieber geordnet von innen nach außen klicken will.

c) Ist es eventuell möglich mit der Programmmaximierung (zweiter Button ganz rechts oben, links neben dem Schließen Button: "x") auch das Display zu vergrößern. Man müsste dann nicht mehr mit der Maus scrollen, sondern könnte die Größe des Displays auch über die Größe des Programmfensters einstellen. Die Bedienbuttons unten in Programm sollten dabei auch einen festen Abstand zum Fensterrand haben.

Ich denke, diese drei Punkte würden die Bedienung des Programmes eventuell noch etwas komfortabler machen. Ansonsten finde ich die Oberfläche sehr gut gelungen.
MfG
 

Bernhard

Registriertes Mitglied
Horizons nimmt vermutlich Erdzeit
Hallo UMa,

Horizons rechnet mit CT, was laut Manual für "coordinate time" steht. Vermutlich wird also bei Horizons, genau wie bei Deinem Programm, die Zeit im Schwerpunktsystem (= weit entfernter Beobachter) ohne weitere Korrekturen verwendet.

Unschön finde ich, dass diese Zeit bei Horizons nur indirekt (??) mit der UT zusammenpasst. Die Erdgeschwindigkeit durchschreitet beispielsweise den Nullpunkt am 1.1.2000 nicht um 11:58:xx sondern um 10:10:xx.
MfG
 

Bernhard

Registriertes Mitglied
Hallo Stefan,

ich habe inzwischen eine neue Version für die Berechnung des N-Körper-Problems geschrieben und dabei alles etwas besser aufgeräumt. Sämtlicher Speicher, der auf dem Heap temporär angelegt wird, wird jetzt mit dem Programmende auch wieder freigegeben. So wird das von guter Software generell erwartet. Version 09 gibt die verlinkte Liste nicht korrekt frei. Der Speicherplatz für die einzelnen Körper wird deswegen nicht korrekt freigegeben.

Aus der Klasse PSystem habe ich die drei Klassen CNewton, CNewtonSP und CEIH gemacht. CNewton berechnet einfach das N-Koerper-Problem mit den bisher beschriebenen Methoden Euler bis Bulirsch-Stoer a la UMa. Bei der Klasse CNewtonSP wird die Bewegung der Sonne getrennt berechnet und zwar so, dass der Schwerpunkt des gesamten Systems konstant bleibt. Der wackelt nämlich bei Klasse CNewton ziemlich herum. Bei einer Rechnung über ein Jahr wandert der z.B. rund 35 km.

Bei einer Rechnung über 10 Jahre ist die Rechnung mit CNewtonSP leider ungenauer, als die Rechnung mit CNewton, was zeigt, dass auch die neue Version für Präzisionsrechnungen noch immer nicht taugt. Zwischen Bulirsch-Stoer und Runge-Kutta gibt es im Ergebnis keine nennenswerten Unterschiede.

Hoffe die neue Version gefällt (s. eMail). Kommentare dazu sind stets willkommen.
MfG
 

Bernhard

Registriertes Mitglied
Inzwischen habe ich noch zwei Programmierfehler in der Berechnung mit erhöhter Genauigkeit (60 Nachkommastellen) gefunden. So konnte ich die Simulation über einen Monat mit Runge-Kutta bei einer Schrittweite von 1000 Sekunden sowohl mit double und der erhöhten Genauigkeit rechnen.

Der Unterschied liegt dabei interessanterweise im mm-Bereich. Im beschriebenen Fall sind die Rundungsfehler also zu vernachlässigen. Von den 15 Stellen der double-Ergebnisse sind also 13 korrekt.
MfG
 
Zuletzt bearbeitet:

UMa

Registriertes Mitglied
Hallo Bernhard, hallo Stefan,

habt ihr mal ausprobiert wie sich der Fehler bei den einzelnen Verfahren als Funktion der Schrittweite verhält? Ihr könntet einen doppelt logarithmischen Plot für den Fehler (der Erdposition) in Abhängigkeit von der Zeitschrittweite machen, erstmal für die newtonschen Gleichungen. Als Referenz erstmal eine Rechnung mit kurzer Zeitschrittweite wählen.
Dann könntet ihr feststellen, welche Zeitschrittweite ihr noch wählen könnt ohne das der Fehler zu groß wird. 1000 Sekunden kommt mir noch etwas kurz vor, ich hatte ja min meinen Verfahren über einen Tag wählen können.

Grüße

UMa
 

Bernhard

Registriertes Mitglied
Hallo UMa,

Stefan meldet sich seit einigen Tagen nicht mehr und ich vermute, dass er gerade im Urlaub verweilt oder auch eine gewisse Auszeit nimmt.

Mir persönlich erscheinen momentan auch die Werte von Horizons aus verschiedenen Gründen als ungeeignet und möchte deswegen als nächstes eine Umrechnungsfunktion in RA und Deklination einbauen, damit man die berechneten Werte mit Programmen wie Cartes Du Ciel vergleichen kann.

Generell würde ich Ephemeridenrechnung sowieso eher anders betreiben, z.B. als Zweikörperproblem mit Störtermen. Es gibt dazu, wie gesagt, das schöne Buch von O. Montenbruck im Verlag Sterne und Weltraum. Für längere Simulationszeiträume sind solche Verfahren einfach wesentlich übersichtlicher und netter zu programmieren.
MfG
 

Bernhard

Registriertes Mitglied
1000 Sekunden kommt mir noch etwas kurz vor, ich hatte ja min meinen Verfahren über einen Tag wählen können.
Hi UMa,

die 1000 Sekunden hatte ich, so wie Stefan, eher für Runge-Kutta verwendet. Bei Bulirsch-Stoer bekommt man mit 8640 Sekunden (1/10 Tag) praktisch die gleichen Werte, wie bei Runge-Kutta mit 1000 Sekunden. Dass Bulirsch-Stoer ziemlich unabhängig von der verwendeten Schrittweite ist, hatte ich bei verschiedenen, kleineren Tests auch gesehen. Der Code sollte also bis hierher halbwegs passen :) .
MfG
 

SRMeister

Registriertes Mitglied
So habe die grafische Version mal endlich weiter verbessern können. Finde sie macht jetzt eindeutig mehr her, habe die genannten Umschläge umgesetzt plus was mir noch so eingefallen ist. Wem fällt mehr ein?

In der Binär-Version sind 3 kompilierte Dateien, plus eine C++ Datei. Die C++ Datei muss zu Bernhards Quellcode hinzugefügt werden, dann muss das ganze Projekt einfach als DLL Datei kompiliert werden und kann dann die entsprechende DLL Datei der Binärdateien ersetzen. So kann jeder ohne Kenntnisse des Windows- Teils, also mit reinen grundlegenden C++ Kenntnissen theoretisch den "Core"-Quellcode weiter verbessern. Um DLL Sachen usw. braucht man sich also nicht kümmern.

Bei Bedarf lade ich auch gern wieder den kompletten Quellcode des Windows Projektes auf den Server.

Binary_10

Code_10_2 wie mir Bernhard gesendet hat, plus die oben genannte .cpp datei um es als .dll zu kompilieren

grüße,
Stefan
 

SRMeister

Registriertes Mitglied
Version 09 gibt die verlinkte Liste nicht korrekt frei. Der Speicherplatz für die einzelnen Körper wird deswegen nicht korrekt freigegeben.
Das ist super und werden wir bald brauchen, wenn man die einzelnen Verfahren gegeneinander antreten lässt und den Fehler direkt auswerten lässt.

Bei der Klasse CNewtonSP wird die Bewegung der Sonne getrennt berechnet und zwar so, dass der Schwerpunkt des gesamten Systems konstant bleibt. Der wackelt nämlich bei Klasse CNewton ziemlich herum. Bei einer Rechnung über ein Jahr wandert der z.B. rund 35 km.
Ich denke das ist aber kein Fehler sondern einfach der RV-Effekt oder? Du siehst ja den Schwerpunkt nicht in den Daten, sondern nur den Nullpunkt. Oder bleibt der Schwerpunkt tatsächlich konstant?

Überhaupt, ich könnte spaßeshalber RV Kurven ausgeben lassen, fällt mir dabei ein!

Bei einer Rechnung über 10 Jahre ist die Rechnung mit CNewtonSP leider ungenauer, als die Rechnung mit CNewton, was zeigt, dass auch die neue Version für Präzisionsrechnungen noch immer nicht taugt. Zwischen Bulirsch-Stoer und Runge-Kutta gibt es im Ergebnis keine nennenswerten Unterschiede.
Was war denn die genaueste Methode bisher? Du hattest doch mal geschrieben, du hattest den Fehler auf unter 10km nach 1Jahr ?
Hoffe die neue Version gefällt (s. eMail). Kommentare dazu sind stets willkommen.
Muss unbedingt noch mehr testen, was die Verfahren angeht! :(

Stefan meldet sich seit einigen Tagen nicht mehr und ich vermute, dass er gerade im Urlaub verweilt oder auch eine gewisse Auszeit nimmt.
Ja das war korrekt. Es gibt da im Moment einige Probleme. Die Auszeit ist zum größten Teil leider unfreiwillig. Dann ist es schwer, sich komplett neu reinzuarbeiten. Allein das RK umzusetzen hat 2 ganze Tage hohe Konzentration gekostet, du kennst das ja sicher. Wenn man dann nur hin und wieder mal ne Stunde findet, fängt man auch lieber nicht mit solchen Monstern an.
Mir persönlich erscheinen momentan auch die Werte von Horizons aus verschiedenen Gründen als ungeeignet und möchte deswegen als nächstes eine Umrechnungsfunktion in RA und Deklination einbauen, damit man die berechneten Werte mit Programmen wie Cartes Du Ciel vergleichen kann.
Schau mal in die .exe rein. Ich denke viel fehlt da nichtmehr, um zu RA und Dec. von der Erde aus, zu kommen.
Generell würde ich Ephemeridenrechnung sowieso eher anders betreiben, z.B. als Zweikörperproblem mit Störtermen.
Also die Bahnberechnung per Kepler, plus Störterme. Soll sehr gut funktionieren, wie du sagst und nicht nur übersichtlicher sondern auch schneller zu sein. Aber ich denke das kommt dann wieder nicht an die von uns bzw. dir erreichte Genauigkeit ran. Ist mehr was für CUDA und 10.000 Körper.
Bei Bulirsch-Stoer bekommt man mit 8640 Sekunden (1/10 Tag) praktisch die gleichen Werte, wie bei Runge-Kutta mit 1000 Sekunden.
Wir müssen unbedingt mehr über die Genauigkeiten rausfinden, wie UMa auch sagt. Die wichtigste Frage ist hier, wir müssen uns ein Kriterium für eine Mindestgenauigkeit finden, und dann rausfinden, welches Verfahren diese Genauigkeit "am schnellsten" erreicht, also nicht abhängig von der Schrittgröße, sondern von der CPU Zeit. Es muss da irgendwo ein Optimum geben, was wir finden müssen. (Für eine vorgegebene Genauigkeit)

Da lässt sich in C# auch einiges viel leichter erreichen als auf C++ Konsole, denn du hast da die ganzen Windows Controls, wie Buttons, Tabellen und Charting für die Fehlerplots, was einfach die Bedienung weiter erleichtert.

Stefan
 

Bernhard

Registriertes Mitglied
Das ist super und werden wir bald brauchen, wenn man die einzelnen Verfahren gegeneinander antreten lässt und den Fehler direkt auswerten lässt.
Hi Stefan,

schön, dass Du Dich meldest! Die Aufteilung in verschiedene Klassen ergab sich natürlich genau aus dem Wunsch die Verfahren über möglichst kleine Code-Änderungen gegeneinander antreten zu lassen.

Ich denke das ist aber kein Fehler sondern einfach der RV-Effekt oder?
Wofür steht RV?

Du siehst ja den Schwerpunkt nicht in den Daten, sondern nur den Nullpunkt. Oder bleibt der Schwerpunkt tatsächlich konstant?
Der Schwerpunkt ist zu 1.0 / Gesamtmasse * Summe (\vec{r}_Planet * m_Planet) definiert. Somit kann innerhalb der Klasse CNewton nach jedem Zeitschritt der Schwerpunkt des gesamten Systems mit einer zusätzlichen Schleife über alle Körper berechnet werden. Für den 01.04.2011 bekam ich über dieses Verfahren eine Abweichung des Schwerpunktes vom Koordinatenursprung von etwa 35 km.

Was war denn die genaueste Methode bisher? Du hattest doch mal geschrieben, du hattest den Fehler auf unter 10km nach 1Jahr ?
Ich habe bei der neuesten Version Runge-Kutta mit CNewton als Sieger in Erinnerung, müsste das aber nochmal konkret nachsehen.

Wir müssen unbedingt mehr über die Genauigkeiten rausfinden, wie UMa auch sagt. Die wichtigste Frage ist hier, wir müssen uns ein Kriterium für eine Mindestgenauigkeit finden, und dann rausfinden, welches Verfahren diese Genauigkeit "am schnellsten" erreicht, also nicht abhängig von der Schrittgröße, sondern von der CPU Zeit.
Genau dafür wollte ich die Umrechnung in RA und D haben. Für beobachtende Amateurastronomen ist z.B. eine Genauigkeit von einer Bogensekunde mehr als ausreichend, um die die berechneten Objekte mit Sternkarte und Optik abends am Himmel zu finden. Man hätte dann eine nette und hilfreiche Anwendung :) . Bei den helleren Planeten wäre auch eine Genauigkeit von einer Bogenminute ausreichend. Bei Neptun, Pluto und den Asteroiden sollte die Position aber genauer berechnet werden, um das Auffinden und Identifizieren zu erleichtern.
Gruß

Bernhard
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Ich denke viel fehlt da nichtmehr, um zu RA und Dec. von der Erde aus, zu kommen.
Hallo Stefan,

ich habe die Umrechnung jetzt zusammengestellt, allerdings ohne die Abhängigkeit vom Beobachtungsort und damit probehalber die Position der Venus zum 31.03.2011 00:00 mit CNewton::Runge-Kutta (Schrittweite = 1000s) berechnet. Die größere Abweichung ergab sich bei der Deklination zu weniger als 14''. Das ist also gar nicht mal so schlecht :) .

Als nächstes müsste dann der Beobachtungsort inklusive Zeitzone berücksichtigt werden. Insbesondere bei der Position des Mondes sollte der Beobachtungsort berücksichtigt werden.
MfG
 

Bernhard

Registriertes Mitglied
Also: Mit Hilfe der Ausgabe von RA und D sind die Ergebnisse leichter und sicherer zu interpretieren. Ich habe deswegen jetzt alle 18 Differenzen mal rechnen lassen: Drei Klassen (CNewton, CNewtonSP und CEIH) mit jeweils drei verschiedenen Methoden (Runge-Kutta mit 1000s, BS mit 8640 s und BS mit 86400s). Berechnung der Position der Venus am 31.03.2012 00:00 in RA und D.

Dabei ergeben sich im Vergleich zu Horizons die folgenden Differenzen in Bogensekunden
HTML:
<table border=1 cellspacing="0" cellpadding="0">
<tr><td> </td><td colspan="2">RK1000</td><td colspan="2">BS8640</td><td colspan="2">BS86400</td></tr>
<tr><td> </td><td>Δ RA/''</td><td>Δ D/''</td><td>Δ RA/''</td><td>Δ D/''</td><td>Δ RA/''</td><td>Δ D/''</td></tr>
<tr><td>CNewton</td><td>0,16</td><td>21,06</td><td>0,16</td><td>21,06</td><td>0,16</td><td>21,07</td></tr>
<tr><td>CNewtonSP</td><td>41,55</td><td>43,99</td></td><td>41,55</td><td>43,99</td></td><td>41,59</td><td>44,12</td></td></tr>
<tr><td>CEIH</td><td>0,16</td><td>21,04</td><td>0,16</td><td>21,04</td><td>0,16</td><td>21,04</td></tr></table>
Im Rahmen der Genauigkeit von 0,01'' macht es also bei CNewton und CEIH keinen Unterschied, ob mit RK1000, BS8640 oder BS86400 (!) gerechnet wird. Die Vergrößerung des absoluten Fehlers im Vergleich zum vorigen Beitrag von 14'' auf 21'' kommt von der Berücksichtigung der Lichtlaufzeit. Warum der Fehler dadurch größer wird, weiß ich momentan aber auch nicht. Ich habe halt über die Geschwindigkeit der Venus die retardierte Position der Venus linear zurück interpoliert.
MfG
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Hallo zusammen,

die verbleibenden Fehler im Bereich mehrerer Bogensekunden schiebe ich mittlerweile doch auf die relativistische Periheldrehung. Zum einen ist es nämlich fraglich, ob der EIH-Limes diese ausreichend genau beschreibt (die numerische Auswertung läßt da eher ein Nein vermuten) und zum anderen braucht man die korrekten Bahnelemente, um die Korrekturen der ART korrekt anzuwenden (ich hatte das weiter oben nur Pi mal Daumen abgeschätzt).

Um nun weiter zu kommen kann man noch die PASCAL-Quelltexte von Cartes Du Ciel lesen. Dort findet man viele Tabellen, die vom JPL stammen. Cartes Du Ciel interpoliert dann zwischen den Werten der Tabelle und kann damit die Werte von Horizons praktisch auf die Bogensekunde genau und besser reproduzieren (!).

Man findet im Netz auch die zugehörige Dokumentation. Ein sehr guter Einstieg dazu ist eine google-Suche nach "J. Chapront, 1995, Astron. Atrophys. Sup. Ser., 109, 181."
Dort findet man einen großen Katalog, als pdf, mit Literatur, wie z.B. http://adsabs.harvard.edu/abs/1994A%26A...282..663S

Die Umrechnung der euklidischen Bahnkoordinaten in RA und D kann man übrigens mit Hilfe einer Translation in geozentrische (bezogen auf den Schwerpunkt der Erde) Koordinaten realisieren. Anschließend dreht man um die x-Achse, die ja in Richtung Frühlingspunkt zeigt. Der Drehwinkel entspricht dabei genau der Schiefe der Ekliptik für J2000.0 und beträgt 23° 26′ 21,45″ (s. http://de.wikipedia.org/wiki/Schiefe_der_Ekliptik#Schwankung_der_Erdachse_und_mittlere_Ekliptikschiefe). Anschließend transformiert man noch die transformierten euklidischen Koordinaten in Kugelkoordinaten.
MfG
 

Runzelrübe

Registriertes Mitglied
Mir fällt es gerade wie Schuppen von den Augen. Vor ein paar Tagen hat Stefan in dem abgesplitteten Thema über eine mögliche Methode, Planeten in Systemen mit bekannten Transitplaneten zu entdecken, ein Paper verlinkt (übrigens ein großes Dankeschön an dieser Stelle!). Ich erinnere mich gerade daran, dort etwas über Unterschiede im Transitzeitpunkt im Sekunden- bis Minutenbereich gelesen zu haben bei Störmassen um Erdgröße.
Habt ihr das System mal inklusive der Jupiter- und Saturnmode laufen lassen? Da kommen wir (über den Daumen gepeilt) doch sicherlich gut und gern auf eine Erdmasse. Horizons scheint in dieser Hinsicht die Gravitationsmassen ja am jeweiligen Körper getrennt zu haben.
 

Bernhard

Registriertes Mitglied
Habt ihr das System mal inklusive der Jupiter- und Saturnmode laufen lassen? Da kommen wir (über den Daumen gepeilt) doch sicherlich gut und gern auf eine Erdmasse. Horizons scheint in dieser Hinsicht die Gravitationsmassen ja am jeweiligen Körper getrennt zu haben.
Hi Rübe,

die Planetenmonde sind seit einigen Versionen enthalten. Der Tipp kam weiter oben von UMa und hat auch einiges an Genauigkeit gebracht. Musst einfach mal nach oben blättern. UMa hatte dort ein pdf (xx405.pdf oder so ähnlich) verlinkt, das passende Gm_i-Werte enthält.
MfG
 

SRMeister

Registriertes Mitglied
Hey Ho

Mal ein kleines Update was bei mir die letzten Wochen mit dem Programm passiert ist.
Das gesteckte Ziel war einen neuen Integrator zu entwickeln, bei dem das Hauptaugenmerk auf Geschwindigkeit liegt.
Dabei wollte ich aber (aufgrund der weiter vorne besprochenen Einschränkungen) nicht auf die GPU gehen sondern nur die CPU voll ausreizen. Also was ist damit möglich? Wie bekomme ich das Programm noch schneller? Vom C++ Code her haben wir schon so ziemlich alle möglichen Tricks ausgereizt, das Limit hier war erreicht.
Es blieben also noch folgende Varianten: Den SSE Befehlssatz ausnutzen, den jede CPU seit mind. 10 Jahren sowieso besitzt - der aber kaum Beachtung findet. Damit kann man in einem Durchgang nicht eine, sondern 4 Fließkomma-Berechnungen durchführen, außerdem gibt es bestimme Befehle die SQRT und DIV viel schneller ausführen als die normalen (sind dafür nur etwas ungenauer). Es galt einen Algorithmus zu finden, bei dem man quasi 4 Planeten gleichzeitig berechnet - dazu musste sogut wie die ganze Datenstruktur von Linked Lists auf standart Arrays umgestellt werden (aufgrund von Einschränkungen von SSE - das mag es nur 4 floats einzulesen die nebeneinander im RAM liegen - und auch noch an 16 Byte Grenzen ausgerichtet sind - alles hat seinen Preis)
Kurz und Knapp: ich hab da viel nachgedacht, einen mMn super tollen Algorithmus gefunden, dann umgesetzt - nämlich in Assembler - war aber enttäuscht - da meine Assemblerkenntnisse nicht ausreichend sind um dem C++ Compiler Konkurrenz zu machen - das Programm lief gerade mal 30% schneller - viel weniger als ich mir erhofft hatte.
Dann habe ich das Ganze nochmal programmiert diesmal mithilfe von "SSE Intrinisic" das sind C++ Funktionen die einem quasi die Assembler arbeit abnehmen - meinen Recherchen und anfänglichen Überlegungen zufolge aber schlechter als wenn man gleich in ASM schreibt - aber da täuschte ich mich. mit den Intrinsics lief das Programm gleich 60% schneller (benötigte nurnoch 40% der Zeit) als der gleiche C++ Algorithmus.
Ich habe mir mithilfe des Debuggers den generierten Assemblercode angeschaut und muss sagen - der Compiler macht zwar viel misst, aber scheinbar immernoch weniger als ich. Leider versteh ich da aber *noch* nicht alles. Es bleibt also weiterhin Platz für Optimierung auf diesem Weg.
Der nächste Weg ist aber schon geplant - wozu hat man eine Quad Core CPU ? :) Das Problem dabei ist folgendes: das Programm läuft dann in mehreren Threads die aber einen gemeinsamen Speicher teilen - die Planetenpositionen und -Geschwindigkeiten. Nach jedem Zeitschritt müssen diese Daten also auf einen gemeinsamen Stand gebracht werden. Ein einzelner Zeitschritt ist aber so schnell in der Ausführung: ich schätze etwa 200- 400 CPU Zyklen - ein Schreib- plus -Lesezugriff auf den RAM dauert bei mir aber schon etwa 200 Zyklen - das ist also der Flaschenhals. Keine Ahnung also ob das überhaupt möglich ist, das Programm auf diesem Weg zu beschleunigen. Würde ein Zeitschritt 10.000 Zyklen dauern - würden die 200 Zyklen Lesen + Speichern nicht ins Gewicht fallen und ich hätte eine 4x Beschleunigung.
Keine Ahnung ob man diese Problem lösen kann.
Die Tage werde ich den Quellcode veröffentlichen - ich muss ihn erst noch etwas aufbereiten.

Betrachtet diesen Eintrag mehr als Update Nachricht - mit Wissenschaft hat das leider (noch) nichts zu tun :(

Stefan
 

Bernhard

Registriertes Mitglied
Betrachtet diesen Eintrag mehr als Update Nachricht - mit Wissenschaft hat das leider (noch) nichts zu tun :(
Hi Stefan,

sehr interessanter Beitrag und eine gute Motivation die genannten Bibliotheken eventuell auch selber mal anzusehen :) .

Zusätzlich würden mich nochmal die Gründe für die Geschwindigkeitsoptimierung interessieren. Wir hatten ja gesehen, dass der EIH-Algo die relativistischen Effekte schlechter als erwartet berücksichtigt mit der Konsequenz, dass man bereits nach einer Simulationszeit von einem Jahr beobachtbare Abweichungen bekommt.

Möchtest Du als nächsten Schritt die Anzahl der Körper erhöhen? Eventuell noch mehr Asteroiden aufnehmen? Ganz allgemein: Wohin soll die "Reise" gehen?
Gruß
 

SRMeister

Registriertes Mitglied
ja also die Relativität hab ich aus diesem Integrator komplett rausgenommen. Er arbeitet im Moment auch mit RK4 ist aber denke ich leicht auf BS umzustellen. (Dazu würd ich dich überreden wollen :) )
Naja jedenfalls möchte ich wie du richtig annimmst, die Anzahl der Körper extrem erhöhen und die Simulation für große Zeiträume gangbar machen. Ich möchte gern einen Simulator schaffen in den man zb. 1000 oder 10000 Planetenembryos steckt und vielleicht mehrere hunderttausend Jahre durchlaufen lässt.
Deshalb hatte ich auch zum Thema RA/ DEC Ephemeriden kein Interesse gezeigt, wobei das Programm mit den letzten Integratoren dafür prinzipiell geeignet erscheint, von der Genauigkeit und Geschwindigkeit her.
Wahrscheinlich muss man um mein Ziel zu erreichen sowieso auf BS gehen, extreme Zeitschritte nehmen und adaptive Zeitschritte umsetzen damit die Kollision noch erkannt werden kann. Ein N-log-N Algorithmus ist denke ich ab 100 Körper oder so, auch schneller.

Edit: Für die SSE Angelegenheit, da hat mir dieser Artikel sehr geholen. Es gibt auch einen guten für Inline-Assembler-SSE aber aus meinen gemachten Erfahrungen heraus ist das Thema *nicht empfehlenswert*
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Ich möchte gern einen Simulator schaffen in den man zb. 1000 oder 10000 Planetenembryos steckt und vielleicht mehrere hunderttausend Jahre durchlaufen lässt.
Benutze dazu doch vorerst die letzte Programmversion ohne Assembler. Dort ist BS ja bereits implementiert und man könnte damit austesten, wie lange das Programm mit N=1000 und t=1000 ... hunderttausend Jahre rechnet. Auch die Programmierung der neuen Startbedingungen ist etwas Arbeit.

Man könnte damit vielleicht schon sehen, ob da etwas zusammenklumpt :confused: .

Erst wenn das ausgetestet ist, würde ich weitere Geschwindigkeitsoptimierungen einbauen.
Gruß
 
Oben