Sonnensystem: Position der Planeten?

SRMeister

Registriertes Mitglied
Huhu liebe User,
ich habe mir ein Programm geschrieben, welches die Planetenbahnen des Sonnensystems simuliert.
Nun bin ich soweit dass es recht gut funktioniert, aber leider fehlen mir informationen bezüglich der Positionen der Planeten. Bei Wiki bekommt man nur Abstand, Masse, usw. also alle wichtigen Parameter nur wo bekomm ich zusätzlich die aktuellen Positionen her? Um die Bahn korrekt festzulegen bräuchte man denke ich zusätzlich die Geschwindigkeit der Planeten?

Wenn bereits Interesse besteht könnte ich das Programm schon veröffentlichen, zb falls jemand helfen möchte, im Moment müssen die meisten Änderungen halt noch im Quellcode vorgenommen werden.(Man kann als Benutzer also noch nicht allzuviel machen) Ist geschrieben in C++.Net

Ziel soll u.a. sein, kurzfristig Asteroidenbahnen zu simulieren, bspw. Apophis, also bräuchte man auch deren Bahnparameter...

Stefan
 

Bernhard

Registriertes Mitglied
Hi Stefan,

bei diesem Thema wirst Du Dich mit Programmen wie XEphem (Linux), Cartes Du Ciel und Stellarium (habe ich noch nicht ausprobiert) messen müssen. Sollte Dein Programm dabei durchfallen, empfehle ich das Buch von Oliver Montenbruck: "Grundlagen der Ephemeridenrechnung". Dort finden sich die wichtigsten Grundlagen und auch die Bahnparameter der Planeten.

Ob man Apophis ohne aufwändige Störungsrechnungen angehen sollte, wage ich zu bezweifeln.
Gruß
 

SRMeister

Registriertes Mitglied
Hi Bernhard, Kibo und Ich,

erstmal Danke für die hilfreichen Antworten.
@Bernhard:
Ich betreibe keine Ephemeridenrechnung. Ursprünglich habe ich ein Programm geschrieben zur N-Body Simulation von Protoplanetensystemen. Ich vermute einfach mal das ist eine andere Herangehensweise als Ephemeridenrechnungen.

Ob man Apophis ohne aufwändige Störungsrechnungen angehen sollte, wage ich zu bezweifeln.
Gruß
Störungsrechnungen sind natürlich da mit inbegriffen da jeder Körper mit jedem Anderen wechselwirkt und kollidieren kann.

Leider musste ich feststellen dass selbst mein Quadcore 3,2Ghz nicht annährend ausreicht um auch nur wenige Körper über lange Zeiträume zu simulieren. 10.000 Jahre für ca 100 Körper wäre beispielsweise ausreichend um diverse interessante Sachen zu simulieren, die so in jungen Planetensystemen abgehen. Aber leider komme ich selbst mit Multithreading also perfekter Ausnutzung aller 4 Kerne nicht annährend da ran :(

Allerdings für Zeiträume<1000Jahre und N<20 oder so, da lässt sich was starten.
Übrigens bei guter Genauigkeit ich denke Zeitschritte von 1-10sec sind machbar.

So jetzt schau ich erstmal wie ich die Planetenpositionen rein kriege.
 

SRMeister

Registriertes Mitglied
Hallo MAC,
ich habe das extra in C++.Net geschrieben um später den "Kern" des Programms in C++ zu schreiben und damit den .Net Vorteil der einfachen Windows Programmierung mit dem Geschwindigkeitsvorteil von C++ zu kombinieren.
Insofern hab ich mir auch schon viele Gedanken über CUDA gemacht, was in .Net nicht machbar ist. Immerhin scheint das ja erheblich schneller als die CPU zu sein. Aber das bedeutet natürlich wieder extremen Aufwand die neue Art zu Programmieren zu lernen. Also mal schauen!
Die von UMa gemachten Vorschläge habe ich jetzt ehrlich gesagt auf Anhieb nicht verstanden. Allerdings habe ich wohl soviel verstanden, dass er letztendlich variable Zeitschritte, abhängig vom erwarteten Fehler vorschlägt?
Ich hatte mir diesbezüglich auch bereits Gedanken gemacht allerdings eher in der Form Zeitschritt abhängig von Entfernung zum nächsten Körper. So können nahe Körper mit hoher Genauigkeit berechnet werden... was im Endeffekt auf dasselbe hinausläuft !? Muss mir dazu noch mehr Gedanken machen :)
Jedenfalls bin ich sehr zufrieden (genau wie du damals :) ) dass es erstmal anständig läuft und für "einfache" Sachen wie Asteroidenbahnen sollte es erstmal so zu gebrauchen sein. Noch eine Frage, du schriebst, du benutzt den halben Zeitschritt ebenfalls, wie von UMa vorgeschlagen, aber in anderem Zusammenhang. Ich benutze nirgends halbe Zeitschritte. Wozu dienen die? War das nur auf die Ermittlung des Fehlers bezogen?

@Bernhard:
Habe mich eben noch etwas mit Bahnstörungen beschäftigt wie von Dir vorgeschlagen, aber sehe erstmal keinen Anlass andere nicht-gravitative Effekte mit reinzunehmen? Es spielt sich alles auch weit genug von der Sonne ab so dass relativistische Effekte wahrscheinlich auch vernachlässigbar sind?

Ups eine Sache hab ich noch vergessen:
In dem von euch vorgeschlagenen HORIZONS Katalog(Danke nochmal, genau was ich gesucht habe) werden perfekterweise die Objekte als Position und Geschwindigkeit angegeben.
Hier als Beispiel die Erde, Koordinatenursprung ist die Sonne, Einheit ist AU:
JDCT
X Y Z <-- Position
VX VY VZ <-- Geschwindigkeit
LT RG RR LT = Lichtzeit(day); RG = Distance from Center(AU); RR = Range Rate(Änderungsrate von RG pro Tag (AU/day)

2455652.500000000 = A.D. 2011-Apr-01 00:00:00.0000 (CT)
-9.855554845305842E-01 -1.864518242419004E-01 1.975847807252305E-05 <-- Position
2.933461796767275E-03 -1.697932543422671E-02 2.779216797989756E-07 <-- Geschwindigkeit
5.793060517472141E-03 1.003037335417702E+00 2.739049035701513E-04

Einfach genial und genial einfach!


Grüße und gute N8 nun :)
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
@Bernhard:
Habe mich eben noch etwas mit Bahnstörungen beschäftigt wie von Dir vorgeschlagen, aber sehe erstmal keinen Anlass andere nicht-gravitative Effekte mit reinzunehmen? Es spielt sich alles auch weit genug von der Sonne ab so dass relativistische Effekte wahrscheinlich auch vernachlässigbar sind?
Hi Stefan,

mit den Bahnstörungen meinte ich eher die gravitativen Einflüsse der Planeten untereinander. Man kann diese Einflüsse für vergleichsweise einfache Rechnungen auch vernachlässigen und bekommt damit Programme, die für rein visuelle Beobachter erst mal ausreichen. Es geht dabei aber mehr um die Frage, wo man einen Planeten abends am Sternhimmel sehen kann.
Gruß
 

SRMeister

Registriertes Mitglied
So habe ich zuerst auch gedacht, habs mir aber trotzdem durchgelesen und naja, ich bin mir etwas unsicher ob relativistische Einflüsse vernachlässigt werden können, denn dort steht ja immerhin bei Merkur sind sie messbar.
Bei Asteroiden könnte auch der Sonnenwind eine Rolle spielen.

Ist also erstmal noch nix entschieden.
 

Bynaus

Registriertes Mitglied
Bei Asteroiden könnte auch der Sonnenwind eine Rolle spielen.

Der Sonnenwind nicht, aber die Strahlung von der Sonne schon. Beim Yarkovsky-Effekt wandern die Asteroiden (bis zu einer Grösse von maximal etwa 30, 40 km, darüber ist das vernachlässigbar) aufgrund ihres Rotationsverhaltens von ihren anfänglichen Bahnen weg. Der YORP-Effekt hingegen beschleunigt die Rotation der Asteoriden und hat somit einen indirekten Einfluss auf den Yarkovsky-Effekt. Es gibt dazu ein nettes Review-Paper von Bottke et al, 2006, das bei "Annual Reviews in Earth & Planetary Science" erschienen ist.

Für ganz kleine Partikel (Mikrometeoriten) gibt es den Poynting-Robertson-Effekt, und für noch winzigere Partikel, die eine nennenswerte Ladung tragen können, kann auch der Sonnenwind eine Rolle spielen ("Blow-out").
 

mac

Registriertes Mitglied
Hallo SRMeister,

ja, UMa steckt entweder so tief in der Materie, daß er vergessen hat wo für Anfänger die Stolpersteine rumliegen, oder er überschätzt meine Fähigkeiten, oder will mich dazu bringen meinen eigenen Grips zu bemühen. Letzteres ist ihm durchaus gelungen und im Nachhinein war das sicher nicht der schlechteste Weg. :)



Voraussetzung ist, daß Dein Programm richtig rechnet! Wie man das testet, beschreibe ich weiter unten - ist vielleicht nicht nötig, aber Deine Frage nach dem halben Zeitschritt, hat mich da in meiner Einschätzung dazu etwas verunsichert, weil Du eigentlich über dieses Problem gestolpert sein mußt.


Doch zunächst zu der von UMa beschriebenen Methode:
Du berechnest die Neue Position des Himmelskörpers A genau so, wie Du es sonst (hoffentlich richtig) machst. Sagen wir mal 1 Tag später. Du wiederholst exakt diese Berechnung, dieses mal aber mit kürzeren Zeitschritten, sagen wir mit 12 Stunden, dann brauchst Du schon zwei Zeitschritte bis Du bei der Position nach einem Tag angekommen bist und Dein Ergebnis für Position und Geschwindigkeit ist genauer. Du machst das nochmal, wieder für den selben Zeitabschnitt dieses mal aber unterteilt in 8 Stunden Schritte, also drei Schritte. Und so weiter (Schrittweite nach Fibonacci verändern ist da wahrscheinlich am besten, muß aber nicht, es geht auch mit anderen Verkürzungsregeln)

Wenn Du Dir nun die von Dir errechneten Werte für die X-Position anschaust und sie gegen die Schrittzahl aufzeichnest wirst Du sehen, daß diese X-Werte gegen einen bestimmten X-Wert konvergieren. Irgendwann werden Deine Ergebnisse, auf welcher X-Position der Planet nach einem Tag steht nicht mehr besser werden, sich nicht mehr verändern, egal wie klein Du Deine Zeitschritte machst.

Das Selbe gilt für die Y und Z Position und auch für die Geschwindigkeitsanteile in X, Y und Z Richtung.

Du kannst nun aus dem Kurvenverlauf, den diese X-Werte gegen die Schrittzahl zeigen ermitteln, wo dieser Konvergenzwert liegt/liegen wird, wenn Du die Schrittzahl weiter vergrößerst (also die Schrittweite weiter verkleinerst) ohne daß Du das bis zu eben dem oben beschriebenen Exzess wirklich durchrechnen mußt.

Und das genau ist der ‚Trick‘.

Ich selber habe das bisher nur mit wenigen Rechnungen ausprobiert und mich noch nicht darum kümmern können, ob ich wirklich in jedem Einzelfall eine eigene Kurvenanpassung rechnen muß, oder ob es ein ganz einfaches Verfahren gibt, den Konvergenzwert zu ermitteln. Ersteres kann ich zwar (war ein Werkzeug in meiner Diplomarbeit), aber es ist ziemlich aufwändig es auch zu programmieren (was ich müßte, wenn ich es in mein Programm einbauen will). Für Letzteres fehlen mir entweder die Erinnerungen wie man das macht, oder ich hab‘ es nie gelernt und selber bin ich bisher nicht (erneut?) drauf gekommen.



Nun zur halben Schrittweite.

Nehmen wir an, Du startest mit der Erde bei Z=0, Y=1AE, X=0, Deine Zeitschrittweite soll 1 Tag sein, dann gibt es mehrere Möglichkeiten wie Du die neue Position und Geschwindigkeit der Erde, nach diesem Tag ausrechnen kannst.

1. Du rechnest erst den neuen Geschwindigkeitsvektor (nach einem Tag Beschleunigung) mit dem Beschleunigungsvektor an dieser Position aus, und läßt die Erde mit diesem neuen Geschwindigkeitsvektor einen Tag lang Strecke machen. Das ist falsch.

2. Du läßt sie mit dem derzeitigen Geschwindigkeitsvektor einen Tag lang Strecke machen und rechnest an der nun nach einem Tag erreichten Position mit dem hier geltenden Beschleunigungsvektor den neuen Geschwindigkeitsvektor aus. Das ist auch falsch!

3. Du rechnest den neuen Geschwindigkeitsvektor mit dem hiesigen Beschleunigungsvektor aus, läßt sie aber einen halben Tag lang mit dem alten Geschwindigkeitsvektor bewegen und den zweiten halben Tag mit dem neuen Geschwindigkeitsvektor. (Man kann das nach diesem Startschritt bei den folgenden Schritten auch geeignet zusammenfassen)

Der für mich zuverlässigste Test ist: Sonne bleibt von jeder Beschleunigung verschont und die Erde bewegt sich auf einer Kreisbahn mit einer Geschwindigkeit von

V = Wurzel(G*mSonne/AE) = erste kosmische Geschwindigkeit

Nach jedem Schritt (hier ein Tag) muß ihr Abstand wieder 1AE sein.

Laß sie ruhig mal mit verschiedenen Schrittweiten einige tausend mal kreisen und schau Dir an, was passiert.

Herzliche Grüße

MAC
 
Zuletzt bearbeitet:

Runzelrübe

Registriertes Mitglied
Voraussetzung ist, daß Dein Programm richtig rechnet! Wie man das testet, beschreibe ich weiter unten

[...]

Der für mich zuverlässigste Test ist: Sonne bleibt von jeder Beschleunigung verschont und die Erde bewegt sich auf einer Kreisbahn [...]

Nach jedem Schritt (hier ein Tag) muß ihr Abstand wieder 1AE sein.

Mal aus reiner Neugier (denn ich entwickle Simulationsumgebungen beruflich):

Ihr nehmt jetzt aber hoffentlich nicht wirklich an, dass ihr in einer kontinuierlichen Simulation, in der ihr Ergebnisse als Eingangswerte weiterreicht, valide Werte mittels Double Precision rausbekommt, oder?! Bitte stellt sicher, dass ihr Datentypen verwendet, die sich um ihre Fehlerfortpflanzung kümmern. Informiert euch dazu bitte über robust geometric computing. Das allerschlimmste an Simulationen ist das Vertrauen in den Computer! :eek:
 

mac

Registriertes Mitglied
Hallo Runzelrübe,

Ihr nehmt jetzt aber hoffentlich nicht wirklich an, dass ihr in einer kontinuierlichen Simulation, in der ihr Ergebnisse als Eingangswerte weiterreicht, valide Werte mittels Double Precision rausbekommt, oder?!
Nein.


Bitte stellt sicher, dass ihr Datentypen verwendet, die sich um ihre Fehlerfortpflanzung kümmern.
warum? Wird das Ergebnis dann genauer? Oder nehmen mir die nur die Fehlerrechnungen ab?


danke für den Link!


Das allerschlimmste an Simulationen ist das Vertrauen in den Computer! :eek:
Ja!

Herzliche Grüße

MAC
 

Runzelrübe

Registriertes Mitglied
Hi MAC,

warum? Wird das Ergebnis dann genauer?

Das ist sehr stark abhängig vom Modell und den verschiedenen Skalen der Parameter. Allerdings werden Deine Werte durch robuste Datentypen immer auch für das mathematische Modell gültig. :cool:

Gerade bei numerischen Simulationen, die keinen sofort berechenbaren Zwischenzustand zu einem x-beliebigen Zeitpunkt erlauben, ist man so auf der sichereren Seite.

Du findest weitere Links, auch mit Negativbeispielen, auf: http://www.cs.nyu.edu/exact/resource/

http://www.ima.umn.edu/~arnold/disasters/sleipner.html schrieb:
The shear stresses were underestimated by 47%, leading to insufficient design. In particular, certain concrete walls were not thick enough

http://www.ima.umn.edu/~arnold/disasters/patriot.html schrieb:
The effect of this inaccuracy on the range gate's calculation is directly proportional to the target's velocity and the length of the the system has been running. Consequently, performing the conversion after the Patriot has been running continuously for extended periods causes the range gate to shift away from the center of the target, making it less likely that the target, in this case a Scud, will be successfully intercepted.

In Simulationen, in denen es um Systeme geht, die ihre Einflüsse zu einem Vektor addieren, können wir nach zig Zehntausend Iterationen eine nette Fehlersumme zusammen haben. Jeder Körper einzeln führt seinen vorherigen Fehleranteil weiter in die jeweils falsche Richtung. Sieht stabil aus auf einer gewissen Skala und für einen gewissen Zeitraum, ist aber ungenügend für Aussagen, das Ende betreffend. Gerade das Beispiel mit der Scud-Rakete, durch die Menschen gestorben sind, sollte zum Nachdenken anregen.
 

SRMeister

Registriertes Mitglied
Nur um nochmal eine kurze Rückmeldung zu geben:

@mac das mit den halben Schritten war mir in der Tat nicht bewusst. Aber du hast recht, meine Sonne ist im Moment verankert. Es muss also was falsch sein. Die Planetenbahnen sehen aber gut aus.

Ich habe die Geschwindigkeit jetzt nochmal verdoppeln können: Da die berechnete Kraft F(a-b) zwischen (a) und (b) gleich der Kraft F(b-a) ist spart man sich mit wenig Aufwand genau die Hälfte aller Berechnungen.

Werde aber wohl doch in Richung Cuda gehen müssen und das erklärte Ziel ist N*log(N) statt N²
wie?
hier mehr

die besten Grüße in die Runde
Stefan
 

mac

Registriertes Mitglied
Hallo Stefan,

hör auf Runzelrübe.

Eine solche Simulation des Sonnensystems ist eine nette Spielerei, bei der man mit (vor)Freude auf’s Ergebnis viel Neues, ganz unauffällig nebenbei lernen kann. Ich hab‘ sowas 1985 mit den Daten des Sonnensystems aus meiner alten Logarithmentafel noch aus der Schulzeit, zum ersten Mal gemacht und hatte keine Ahnung, wie ich an die echten Positionen ran kommen könnte. Welch ein Schlaraffenland steht uns da mit dem Internet zur freien Verfügung! Ich hab‘ ‚Nemesis‘ durchs Sonnensystem rauschen lassen und mich über die durcheinander gewürfelten Planetenbahnen gefreut. :D Aber besonders darüber, wie genau ein solcher ‚Stern‘ treffen muß, um wirklich Schaden anzurichten. :)

Und dann, bei einem erneuten, noch genaueren Treffer, raste auf einmal unser Mond mit ungeheurer Geschwindigkeit davon. Was war passiert? Ich hatte mit festen Zeitschritten gerechnet. Das geht ganz unauffällig gut, solange es keine großartigen Entfernungsunterschiede zwischen den einzelnen Zeitschritten gibt, aber wenn man einen Tag lang mit einer Beschleunigung rechnet, die so höchstens ein paar Minuten dauert, dann bekommt man sehr drastisch die Grenzen solcher Simulationen vor Augen geführt und damals für mich die Grenzen, wie weit ich solche ‚Spielchen‘ in der Mittagspause ausbauen konnte und wie weit nicht.

Du kannst Deinen Simulator nach den Grundtests mit den echten Daten des Sonnensystems testen (aus dem Link von Ich. Laß Dir die Positionen und Geschwindigkeiten(auch die der Sonne)auf den Schwerpunkt des Sonnensystems bezogen ausgeben) und Du wirst auch sehen, daß Du allein mit Newton nicht auskommst, wenn es sehr genau sein soll und das über mehrere Jahre, besonders bei den inneren Planeten.

Schau Dir an, mit welcher Genauigkeit Du an die Massen der Himmelskörper kommst. Das sind alles gerundete Werte. Zum Glück sind die Umlaufbahnen mehr oder minder Kreisförmig, so daß sich die Fehler duch die Rechengenauigkeit bei den Vektor-Berechnungen nicht vollständig addieren. Wenn Du mit floating Point Daten arbeitest, dann sortiere Deine Ergebnisse vor den Additionen nach (absoluter, also vorzeichenloser) Größe, und fang die Additionen mit den kleinen Zahlen an, sonst fällt unnötig viel unter den Tisch. Hier wirst Du dann auch sehen, wo die Beschränkungen in der Rechengenauigkeit liegen und Du kannst Dir in erster Näherung einfach überschlagen, nach wieviel Iterationen Dein Rechenfehler wie groß geworden sein muß, und eben auch, daß zigtausende von Jahren nur noch Hausnummern liefern können.

Dein Plan es mit Barnes und Hut zu versuchen, ist gut, aber er vergrößert auch den systematischen Fehler - ok der tritt allerdings bei einer solchen Dynamik wie sie im Sonnensystem herrscht, eher chaotisch verteilt auf, so daß Du hoffen darfst daß es ein noch brauchbarer Kompromiß ist. Vergleiche einfach die Ergebnisse mit denen ohne diese Zusammenfassungen.

Herzliche Grüße

MAC
 
Zuletzt bearbeitet:

SRMeister

Registriertes Mitglied
und Du wirst auch sehen, daß Du allein mit Newton nicht auskommst, wenn es sehr genau sein soll und das über mehrere Jahre, besonders bei den inneren Planeten.
Die Frage hab ich ja schon weiter vorne aufgewurfen.
Mein Projekt habe ich in Gedanken in zwei Teilprojekte unterteilt. Das Erste war eine möglichst langfrisitge bezogen auf Planetesimale und die Entstehung von Planeten daraus. Das ist vorerst gescheitert da ich noch kein Barnes Hut Algo (also logarithmische Skalierung) implementiert habe und auch noch nicht CUDA verwende.
Das Zweite Teilprojekt ist die Simulation des aktuellen Sonnensystems, um möglichst genaue Voraussagen treffen zu können, was mit einigen Asteroiden passiert. Dazu reichen Simulationszeiten von max. ca. 100 Jahren, was aber möglichst genau sein soll.
zur Genauigkeit: Ich rechne ausschließlich mit double, also 64bit. Double hat ca. 17 Nachkommastellen.
Schau Dir an, mit welcher Genauigkeit Du an die Massen der Himmelskörper kommst. Das sind alles gerundete Werte.
Ich denke in der Horizons Datenbank ist alles in ausreichender Genauigkeit zu finden.

Ich habe nun das Programm in "unmanaged C++" übersetzt weil sich .NET nicht mit CUDA C erweitern lässt und weil es wesentlich schneller läuft.
Bald gibts eine Veröffentlichung.

beste Grüße,
Stefan
 
Zuletzt bearbeitet:

Runzelrübe

Registriertes Mitglied
Ich habe nun das Programm in "unmanaged C++" übersetzt weil sich .NET nicht mit CUDA C erweitern lässt und weil es wesentlich schneller läuft.

Ein Wort der Warnung: Sei bitte vorsichtig, dass Du damit keinen Schritt zurück machst, indem Du Dir durch eine schnellere Berechnung vorgaukelst, dass Dein Programm besser wird. Es wird eben nur eins: schneller. Jede Software kann man in Hardware gießen und genau das wird auf einer GPU für die auf dem Bildschirm benötigten Genauigkeitsvorgaben getan. GPUs arbeiten jedoch mit noch geringeren Bit-Breiten für Datentypen. Um es für Dich bildlich auszudrücken: ausgerechnet Deine kleinen Asteroiden werden immer ungenauer, weil ihre Wichtungsanteile unter den Tisch fallen.

Da ich ebenfalls in .NET entwickle, sei Dir noch ans Herz gelegt, Dich zum Thema unmanaged lieber in Richtung Marshalling zu informieren. Jede C/C++ Bibliothek kann durch DLLImport in managed Code integriert werden. Unmanaged ist schnell auch unsafe, daher heißt auch die Compilerdirektive genau so: unsafe. Sei bitte vorsichtig, sowohl mit Deinen Datentypen und auch mit Deiner Speicherverwaltung.

Worin ich Dich gern bestärken möchte: Plane Deine Schritte. Mach bitte einen Schritt nach dem Anderen. Mach kleine Schritte, diese dann allerdings vollständig. Und geh danach erst weiter bis zum Ende.

Ich hatte vor Jahren ebenfalls mal ein Programm (in C#.NET) geschrieben, welches mir .avi Videos zur Simulation von Sternbewegungen in Sternhaufen ausgespuckt hat und habe mir auch nicht reinreden lassen. Mittlerweile weiß ich es besser. Meine Ergebnisse waren nett anzuschauen, aber leider komplett unbrauchbar. Und das hat mich eher enttäuscht als motiviert. Ich kann Dir nur raten, red Dir nicht ein, Ratschläge selektiv zu ignorieren, weil Du das ja nur aus Hobby machst. Du könntest sonst am Ende ebenfalls enttäuscht sein, wenn Du das Programm präsentierst und es nur für 10-Körper-Probleme ähnlicher Größenordnungen gut läuft.
 
Oben