Sonnensystem: Position der Planeten?

SRMeister

Registriertes Mitglied
Oh ja hab vor einiger Zeit mich auch mal mit Opengl beschäftigt (NeHe Tutorials gemacht falls die jemand kennt)

Ich denke es gibt mittlerweile unter .NET einfachere Möglichkeiten sowas in 3D umzusetzen, hab da aber keine Erfahrung.

Die Idee ansich find' ich sehr gut. Man könnte auch auf eine realistische grafische Darstellung vorerst verzichten und einfach in einem Diagramm den Verlauf der Bahnparameter der Planeten darstellen.

Interessant wäre dann auch das resultierende System auf langfristige Stabilität zu untersuchen: dafür ist nämlich das bisherige Verfahren ausreichend (Bulirsch-Stoer)
 

Bernhard

Registriertes Mitglied
Ich denke es gibt mittlerweile unter .NET einfachere Möglichkeiten sowas in 3D umzusetzen, hab da aber keine Erfahrung.
Im Prinzip würde auch die 2D-Projektion reichen. Man könnte z.B. die bereits bestehende .NET-Oberfläche noch etwas "aufmotzen": Schwarzer Hintergrund und kleine farbige Kügelchen in leicht unterschiedlicher Größe für die Planeten (Sonne:Gelb,Merkur:Grau, Venus:Weiß,Erde:Blau,Mars:Rot,Jupiter,Saturn:Gelb,Asteroiden:Grau,Uranus,Neptun:Grün,Pluto:Grau). An die Sonne und den "Eindringling" würde ich dann noch die Labels Sonne und WZ (Weißer Zwerg) als Text setzen, dass die klar erkennbar bleiben. Eventuell müsste man auch den Beobachter weg- und heranfahren (Zoom). Die Kennzeichnung der Bahnen könnte man eventuell noch weglassen, um alles übersichtlich zu halten.

Daraus könnte man dann einen kleinen Clip machen. Die einzelnen Frames werden mit einem geeigneten Zeitabstand berechnet und dann zusammengesetzt. Man müsste sich dazu noch nach einer freien Filmbearbeitungssoftware im Netz umsehen (ich denke, da werde ich mich mal ein bisschen umsehen. Gerade das Zusammensetzen finde ich interessant.).

OpenGL würde ich weglassen, weil zu viel Arbeit. Auf weitere Zahlen würde ich auch verzichten, weil ich mir gut vorstellen könnte, dass sich das dann niemand mehr ansieht.
Gruß
 

SRMeister

Registriertes Mitglied
sehr gut.
wie wärs wenn man die Bahn der Planeten des letzten halben Jahres oder so, als Schweif anzeigt?
Zoom gibts schon (Mausrad).
Denke mal ich finde dieses WE noch Zeit um ein paar Sachen umzusetzen.
 

Bernhard

Registriertes Mitglied
wie wärs wenn man die Bahn der Planeten des letzten halben Jahres oder so, als Schweif anzeigt?
Das wäre vermutlich von Vorteil.

Es gibt zum Clip zusätzlich noch eine entscheidende Hürde: Das Programm müsste Einzelbilder exportieren können. Es müsste z.B. pro zehn Tage (o.ä) ein Bild produzieren, um die Bilderserie dann zu einem Clip zusammenzufügen. Welches Format da geeignet wäre, weiß ich momentan leider nicht, aber ich gehe der Sache nach.
Gruß
 

SRMeister

Registriertes Mitglied
Ich kann das Programm so machen das es einen Film auf dem Bildschirm abspielt. Es gibt dann mehrere Programme die Videos vom Bildschirm aufnehmen können, ich glaube sogar unter Windows 7 ist eins integriert. Ich denke die Programme können sicher auch nur Teile des Bildschirms aufnehmen.
Evtl. könntest du also in die Richtung schauen, das wäre wohl am einfachsten.
 

Bernhard

Registriertes Mitglied
Hallo Stefan,

vermutlich willst du den Bildschirmspeicher per Programm immer wieder neu beschreiben? Meiner Erfahrung nach, flackert so etwas gerne.

Es gäbe als Alternative kostenlose Konverter, wie z.B. JPGVideo. Das macht aus maximal 32700 durchnummerierten JPG-Dateien eine avi-Datei. Man kann dort auch die Anzahl an Frames pro Sekunde einstellen und könnte damit die Empfehlungen von youtube gut einhalten. Gibt es bei .NET nicht eine Export-Funktion, die ein Bild mit einer vorgegebenen Auflösung als jpg auf die Festplatte rausschreibt?
Gruß
 

UMa

Registriertes Mitglied
Hallo Stefan, Bernhard, ...

ich hatte nur wenig Zeit, daher die geringe Beteiligung meinerseits.

Zu SSE, damit habe bisher nur die negative Erfahrung gemacht, dass bei mir nur noch einfache statt doppelte Genauigkeit erzielt wurde, obwohl Hard- und Software angeblich SSE mit double Genauigkeit unterstützen sollten.

Zur Geschwindigkeit, bei mir kostet, wenn ich mich richtig entsinne, das Wurzelziehen beim Berechnen der Entfernungen ca. 40% der gesamten Rechenzeit. Daher speichere ich die Entfernungen in einer Matrix und berechne nur etwas weniger als die Hälfte, da die Entferungen symmetrisch sind.

Zur Parallelisierung gibt es mehrere Möglichkeiten:

Erstens kann man natürlich die Berechnung der Kräfte parallelisieren, da dies am längsten dauert. Dies sollte unabhängig vom algorithmus möglich sein. Der Nachteil ist natürlich, dass das nur für eine große Anzahl von Körpern günstig ist, da sonst der Overhead zu groß wird.

Zweitens kann man beim BS die Berechnungen für eine großen Zeitschritt mit den einzelnen Teilzeitschritten unabhängig von einander ausführen, das keine Ergebisse beim anderen benötigt werden.
Falls man den Kern bestimmen kann, auf welchen die jeweilen Teilprobleme gelöst werden kann eine optimale Beschleunigung erzielt werden.
Für 4 Kerne wäre die Aufteilung so:
Kern 0: 3 schritte + 4 Schritte
Kern 1: 2 Schritte + 5 Schritte
Kern 2: 1 Schritt+ 6 Schritte
Kern 3: 7 Schritte
Nach 7 Zeitschritten, d.h. nach 7 Berechnungen der Entfernungsmatrix ist jeder Kern fertig und die Extrapolation (nichtparallelisert, da im Vergleich zur Berechnung der Entfernungen/Kräfte schnell) kann beginnen.

Wenn man nur 3 Kerne hat, oder nutzen möchte damit man während der Rechnung noch was anderen machen kann, kann man die 7 Schritte weglassen und dadurch etwas weniger extrapolieren. Man wird etwas kürzere Zeitschritte nehmen müssen. Bei 2 Kernen legt man das, was bei 4 Kernen 2 tun zusammen.

Bei 4 Kernen hat man nun pro großem Schritt nur 7 Kraftberechnungen pro Kern statt 28. Bei 3 Kernen sind es 7 statt 21 und bei 2 Kernen sind es 14 statt 28, also optimal.

Wenn man den Kern nicht bestimmen kann, auf dem die Teilberechnungen ausgeführt werden, kann man nur hoffen, dass das Betriebssystem beim Verteilen keinen zu großen Blödsinn macht. Evtl. könnte man durch Veränderung der Reihenfolge der Starts der Berechnungen (z.b. 7 1 2 3 6 5 4 oder so) versuchen Einfluss zu nehmen.

Drittens gibt es natürlich noch die "poor man's" Parallelisierung. Wenn man ohnehin das Programm mehrmals mit verschiedenen Startwerten oder Parametern starten will, startet man das Programm mehrfach gleichzeitig mit diesen Werten.

Bei der Simmulation der Planetenentstehung gibt es den Trick, den Radius der Körper (die Sonne aber nicht, oder nicht so stark) zu vergrößern und so durch häufigere Kollisionen die notwendige Zeit zu verkürzen. In wie weit das da aber unrealisitsch wird, weiss ich nicht. Aber zum Testen oder erste, schnelle Ergebnisse könnte man das einsetzen. Vielleicht am Anfang um einen Faktor 100, (bei der Sonne nicht oder maximal Faktor 10). Das dürfte dann fast 10000mal schneller gehen.

Adaptive Zeitschritte sind bei BS sehr einfach und kosten keine Zeit, da mit dem Unterschied zwischen k und k-1 Extrapolationsschritten ein Fehlerschätzer gratis zur Verfügung steht. Ich denke, dass bei Kollisionen oder beinahe Kollisionen adaptive Zeitschritte notwendig sind.
Bei der adaptive Zeitschrittweite könnte man z.B. 3 Fehlerschranken angeben 0<f1<f2<f3.
Ist der Fehler kleiner als f1 wird der Schritt zwar akzeptiert, aber die Zeitschrittweite im nächsten Schritt etwas vergrößert. Zwischen f1 und f2 ist alles ok, schrittweite bleibt. Zwischen f2 und f3 wird ge eben gemachte Schritt zwar akzeptiert, aber die Zeitschrittweite im nächsten Schritt etwas verkleinert. Ist der Fehler größer als f3 muss der eben berechnet Zeitschritt verworfen und mit einer kleineren Schrittweite wiederholt werden (zur not mehrfach, bis der Fehler nicht mehr größer als f3 ist).

Durch den Zusatzterm wird ermöglicht nahe Vorbeigänge ohne Reduktion der Zeitschrittweite zu berechnen, ohne dass man bei der Kraftberechnung fast durch 0 teilt und im nächsten Schritt der Körper unter hohem unphysikalischem Energiegewinn davon schießt. Im Prinzip wird die Punktmasse dabei über ein größeres Gebiet "vermatscht". Das verhindert die grobe Verletzung des Enegieerhltungssatzes in der Simulation, aber der Stoßwinkel bleibt immer noch falsch. Er ist daher nur für statistische Betrachtungen bei Sternhaufen oder Galaxien geeignet, nicht aber wenn es auf individuelle Körper ankommt.

Sogenannte "Symplectic Integrators" werden verwendet, wenn sich die Bahnen gut durch ein Keplerproblem + kleine Störungen beschreiben lassen. Dann wird das Keplerproblem "exakt" gelöst und nur über die kleinen Störungen integiert. Das ist sehr gut, solange die kleinen Störungen wirklich klein sind. Bei näheren Begegnungen muss dann auf einen anderen Integrator z.B. BS umgeschaltet werden, weil es sonst zu ungenau wird.

BS ist dagegen universell einsetzbar und leichter zu implementieren.
Das BS so viel langsamer ist, kann ich mir nicht vorstellen, da beim BS die Zeitschrittweiten (großer Schritt) größer sind, als bei den "Symplectic Integrators".

Grüße UMa
 

SRMeister

Registriertes Mitglied
Zu SSE, damit habe bisher nur die negative Erfahrung gemacht, dass bei mir nur noch einfache statt doppelte Genauigkeit erzielt wurde, obwohl Hard- und Software angeblich SSE mit double Genauigkeit unterstützen sollten.
Das kann ich so nicht bestätigen. Es stimmt zwar, das SSE (SSE1) nur single precision macht, aber praktisch jeder moderne PC seit Pentium 4 (also 2000) kann auch SSE2 womit double möglich ist.
Selbst Intel empfiehlt nurnoch SSEx anstatt die Gleitkommaeinheit zu nutzen. Alle modernen Compiler tuen das auch selbstständig ohne etwas aktivieren zu müssen.
Ein Nachteil gibt es aber: Die Fließkommaeinheit (die FPU) rechnet intern immer mit 80 bit genauigkeit (long double) leider tut das die SSE Einheit nicht, die kann intern auch max. nur 64 bit (double).


Zur Geschwindigkeit, bei mir kostet, wenn ich mich richtig entsinne, das Wurzelziehen beim Berechnen der Entfernungen ca. 40% der gesamten Rechenzeit. Daher speichere ich die Entfernungen in einer Matrix und berechne nur etwas weniger als die Hälfte, da die Entferungen symmetrisch sind.
Das machen wir auch. Ich glaube der Tip kam schonmal von Dir und ist von Bernhard schon lange umgesetzt.
Zur Parallelisierung gibt es mehrere Möglichkeiten:

Erstens kann man natürlich die Berechnung der Kräfte parallelisieren, da dies am längsten dauert. Dies sollte unabhängig vom algorithmus möglich sein. Der Nachteil ist natürlich, dass das nur für eine große Anzahl von Körpern günstig ist, da sonst der Overhead zu groß wird.
das geht mit SSE quasi ohne Overhead, da der Compiler sowieso SSE Befehle benutzt, aber eben nur solche die mit einem Operanden rechnen. Diese kann man theoretisch fast komplett durch Befehle mit 4 Operanden ersetzen. Womit theoretisch kein Overhead entsteht. Die praktische Ausbeute bleibt nur deshalb hinterher weil meine Assemblerfähigkeiten mit dem optimierenden Compiler (noch?) nicht mithalten können.

Extremer Overhead entsteht nur bei Multithreading und fällt deshalb wie du sagst für kleine N aus.

Zweitens kann man beim BS die Berechnungen für eine großen Zeitschritt mit den einzelnen Teilzeitschritten unabhängig von einander ausführen, das keine Ergebisse beim anderen benötigt werden.
...
Das ist im Prinzip korrekt, es müssen halt bei der Extrapolation alle Daten an einem Ort sein, was bedeutet die einzelnen Kerne müssen die Daten über den Speicherbus austauschen, was den großen Overhead erzeugt. An diesem Punkt muss man ganz besonders vorsichtig arbeiten, damit die Synchronisation korrekt von Statten geht.
Wenn man den Kern nicht bestimmen kann, auf dem die Teilberechnungen ausgeführt werden, kann man nur hoffen, dass das Betriebssystem beim Verteilen keinen zu großen Blödsinn macht. Evtl. könnte man durch Veränderung der Reihenfolge der Starts der Berechnungen (z.b. 7 1 2 3 6 5 4 oder so) versuchen Einfluss zu nehmen.
Da würde ich mir keine zu großen Sorgen machen, das Betriebssystem verteilt die Threads optimal. Händisch würde man das nicht besser hinbekommen.
Drittens gibt es natürlich noch die "poor man's" Parallelisierung. Wenn man ohnehin das Programm mehrmals mit verschiedenen Startwerten oder Parametern starten will, startet man das Programm mehrfach gleichzeitig mit diesen Werten.

Bei der Simmulation der Planetenentstehung gibt es den Trick, den Radius der Körper (die Sonne aber nicht, oder nicht so stark) zu vergrößern ... Das dürfte dann fast 10000mal schneller gehen.
Das wäre möglich. Man kann auch noch an anderen Stellen Geschwindigkeit gegen Genauigkeit tauschen. Ich hatte beispielsweise festgestellt, dass durch Einsatz von float statt double der Fehler nur minimal zunimmt. Außerdem hat die SSE Einheit zusätzliche Varianten für 1/x (Reziprok) und 1/Sqrt die die Ergebnisse aus einer Lookup-Tabelle interpolieren und somit bspw. statt 60 Zyklen den gleichen Schritt in 5 Zyklen machen können. Natürlich auf Kosten der Genauigkeit.
Ich denke, dass bei Kollisionen oder beinahe Kollisionen adaptive Zeitschritte notwendig sind.
Genau. Allerdings muss man dann alle Körper in diesem kleinen Zeitschritt machen. Das ist das Problem. Bei Vielen Körpern hat man dann quasi fast immer 2 Körper die sich sehr nahe sind und somit läuft das ganze System ständig in der höchsten Auflösung.
Sogenannte "Symplectic Integrators" werden verwendet, wenn sich die Bahnen gut durch ein Keplerproblem + kleine Störungen beschreiben lassen. Dann wird das Keplerproblem "exakt" gelöst und nur über die kleinen Störungen integiert. Das ist sehr gut, solange die kleinen Störungen wirklich klein sind. Bei näheren Begegnungen muss dann auf einen anderen Integrator z.B. BS umgeschaltet werden, weil es sonst zu ungenau wird.
Ist halt mathematisch und programmtechnisch extrem aufwändig. Von Hamiltonian usw. hab ich auch keine Ahnung und sehe auch nicht dass sich das ändern könnte :)
BS ist dagegen universell einsetzbar und leichter zu implementieren.
Das BS so viel langsamer ist, kann ich mir nicht vorstellen, da beim BS die Zeitschrittweiten (großer Schritt) größer sind, als bei den "Symplectic Integrators".
Es gibt mehrere opensource Simulatoren. Einen davon hab ich mir mal angeschaut. Er bietet mehrere Integratoren darunter auch BS. Der Autor sagt aber der ist nur zu Testzwecken zu gebrauchen weil er so langsam wäre.
Leider konnte ich im Source aber nur die Kommentare verstehen ;) da, aus welchen Gründen auch immer, die Profis heute immernoch in Fortran programmieren :(
Ich schätze, würde man einen wie von dir skizzierten, guten BS-Ansatz unter Ausnutzung der ganzen SIMD und Multicore Hardware in C++/Assembler schreiben, wäre der sicher schneller als den ihr "mathematisch ausgereiztes" System was auf Fortran77 kompiliert wird...
 
Zuletzt bearbeitet:

Runzelrübe

Registriertes Mitglied
Kurze Zusammenfassung eines alten Eintrags:

Ich habe mich [...] mit der 3D Darstellung [...] beschäftigt [...]. Könntet ihr eure Ergebnisse [...] in eine CSV Datei gießen [...], so dass ich eure Ergebnisse [...] mal visuell darstellen kann? Danke!

Da ich ein Pathtracing eingebaut habe [...]

Es muss doch nicht alles doppelt und dreifach gebaut werden, wenn es schon vorhanden ist. ;)

Ich habe lange nicht an der Diskussion teilgenommen, wie mir gerade auffällt. Auch bin ich wohl zu schnell vorgeprescht mit dem Angebot, noch Links rauszusuchen. Irgendwie blieb in den letzten Wochen am Ende des Tages so wenig Zeit übrig. :D

Ich bin zwar kein Freund von Open-Source, kann allerdings mehrere Dinge beisteuern, die uns hier bereits weiterhelfen würden und die ich vollständig in .NET entwickelt habe: einen ASP.NET-GIF-Animator (pseudo-live durch Parametrisierung, leider nur Fullframes, wird sehr schnell sehr groß), einen Video-Animator (exportierbar in ein Wunschformat) und einen 3D-Visualizer (ganz ohne OpenGL oder DirectX). Letzteren hatte ich, wie man sehen kann, bereits vor 3 Monaten angeboten. Nur leider war wohl niemand darauf eingegangen, da der Rest des Eintrags ein Folgethema generiert hatte, das kurzfristig den Fokus verschob.

Mir fällt gerade noch ein, dass ich euch einen klitzekleinen Ausblick auf das, was euch erwartet, sogar jetzt schon geben kann. 2005 kam mir in den Sinn, eine meiner ersten 3D-Web-Visualisierungen per Shockwave zu bauen (sollte ursprünglich die Karte eines Weltraum-Spiels werden): http://www.sternkun.de/galaxy/

Die "Sterne" sind anklickbar und es existiert eine Tastaturunterstützung. Ich kann mir durchaus vorstellen, mich wieder aktiver an dem Thema zu beteiligen. Gebt mir noch ein wenig Zeit. Bis dahin. :)
 

Bernhard

Registriertes Mitglied
Hallo Runzelrübe,

das sieht interessant aus! Zeigt diese 3D-Karte echte Sterne oder sind die eher zufällig verteilt?

Vorschlag für ein neues Thema: Wie wäre es, diese Karte so auszubauen, dass man dort echte Sterne erkunden kann. Im Koordinatenursprung sitzt die Sonne, bzw. Sagittarius A (Zentrum der Milchstraße). Sichtbar sollten dann die bekanntesten Sterne des Himmels sein, wie z.B. Alpha Centauri, Sirius, Prokyon, Deneb, Wega, Atair usw. usw. Ganz besonders schön wären dann noch die galaktischen Objekte der Milchstraße aus dem Messier-Katalog (und die hellsten aus dem NGC-Katalog). Man könnte dann die Milchstraße wirklich in 3D kennenlernen und erkunden.

Wenn die Seite auf eine definierte Datenstruktur zugreift, könnte man diese Struktur (z.B. Text-Datei) schrittweise von verschiedenen Freiwilligen füllen/erstellen lassen. Das Projekt könnte dann mit der Zeit immer weiter wachsen.
Gruß
 

Bernhard

Registriertes Mitglied
Dabei gibt es 2 Probleme: 1. 1000 Körper ist wahrscheinlich für den (N²) Algorithmus zu viel.
Hallo Stefan,

der Vollständigkeit halber möchte ich hier noch ein Paper von J.W. Wadsley verlinken. Dort werden meiner Meinung nach sehr interessante Ergebnisse bestehender Simulationen des N-Körper-Problems mit großem N vorgestellt. Nach kurzem Überfliegen entpuppt sich diese Arbeit als Weiterentwicklung des Barnes-Hut-Algorithmus:

Wadsley schrieb:
Pkdgrav departed significantly from the original N-body tree code design of Barnes and Hut
Gruß

B.
 

Bernhard

Registriertes Mitglied
Hallo SRMeister,

trotz intensiven Bemühens schaffe ich es nicht die letzte Version als Konsolenanwendung für Visual Studio C++ 2010 Express herzustellen. Hast Du eventuell den letzten Code noch komplett, so dass man es ohne Fehler und ohne Warnings übersetzen kann?
Gruß
 

SRMeister

Registriertes Mitglied
okay, also lass mich folgende Vorschläge machen:
ich installiere mir jetzt selbst Express, werde meine aktuelle Version darauf testen, anpassen und dann hier veröffentlichen. Die aktuelle Version beinhaltet die von dir zuletzt veröffentliche Version soweit ich mich erinnere, der Integrator ist also auf dem aktuellen Stand.

Dann haben wir erstmal wieder den selben Startpunkt.

Ich habe das Projekt übrigens folgendermaßen weitergeführt:

- reduzieren von 3 Programmiersprachen auf 2 ( core in C++, Windows Teil in C#)
- momentan kein Assembler im core
- momentan keine Konsole im core, core wird als .dll kompiliert und der Windows Teil benutzt diese dann.
- verbesserung des Windowsteil

Es ist also folgendermaßen: Momentan ist der core ein eigenständiges Projekt in der gesamten Projektmappe, den man unabhängig und nur in C++ bearbeiten kann, aber die Schnittstelle muss so bleiben wie sie ist, damit das GUI darauf zugreifen kann.

Ich erkläre das später noch genauer.

Es wäre möglich auch wieder eine Konsole einzusetzen, aber es würde eigentlich wenig Vorteile bringen und ich würde vorschlagen, wir bleiben vorerst bei DLL und GUI als getrennte Komponenten. So kann man auch die Kompetenzen besser aufteilen und man kann durch die Schnittstelle getrennt, unabhängiger arbeiten.

Ich gehe später noch genauer darauf ein, aber evtl wäre ein SVN repository ganz gut. Ich muss mal sehen ob man AnkhSVN mit VS-Express benutzen kann.

Später mehr.

Grüße
 

SRMeister

Registriertes Mitglied
Hallo Bernhard,
für den geplanten Branch, (den würde ich gern TheiaSim nennen?)

kann ich den Code so nehmen, alle Integratoren sowie deren relativistische Variante, sowie den Ra/Dec teil, beseitigen, nur den normalen BS übernehmen und dass als Grundlage für ein kombiniertes DLL/Konsolenprojekt nehmen, welches entweder mit dem Windows Teil zusammenarbeitet oder eben als Konsole läuft?
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
kann ich den Code so nehmen, alle Integratoren sowie deren relativistische Variante, sowie den Ra/Dec teil, beseitigen, nur den normalen BS übernehmen und dass als Grundlage für ein kombiniertes DLL/Konsolenprojekt nehmen, welches mit dem Windows Teil zusammenarbeitet?
Ja klar. Der Code ist (zumindest von mir aus) frei verwendbar und darf auch verändert werden.
 

SRMeister

Registriertes Mitglied
Ich frage auch deshalb, weil ich damit eben einen neuen Branch machen will, wobei wir uns vorher, also jetzt darüber einigen, was dort als Grundausstattung enthalten ist.
Ich hoffe ja dass du dann dort auch mit dabei bist :) Wobei wir uns gern später entscheiden können wie wir weitermachen.(wegen adaptiv, kollisionserkennung usw.)
 

Bernhard

Registriertes Mitglied
Passend für ruhige Minuten an Feiertagen noch ein Lesetipp passend zum Thema: http://www.clearskyinstitute.com/xephem/index.html

Das Programm XEphem startete vor vielen Jahren als kleines Linux-Tool und hat sich mittlerweile scheinbar zu einem recht weit verbreiteten Programm gemausert. Die Homepage zeigt in beeindruckender Weise, wie weit man mit tabellarisierten Bahnelementen und der Kepler-Gleichung kommt. Für Untersuchungen zur Stabilität des Sonnensystems über Millionen von Jahren ist das Tool selbstverständlich eher schlecht geeignet.

Der Quelltext ist frei verfügbar.
 
Oben