Werbung
Seite 2 von 16 ErsteErste 123412 ... LetzteLetzte
Ergebnis 11 bis 20 von 160

Thema: Sonnensystem: Position der Planeten?

  1. #11
    Registriert seit
    11.03.2006
    Beiträge
    5.891

    Standard

    Werbung
    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
    Geändert von mac (03.04.2011 um 02:05 Uhr)

  2. #12
    Registriert seit
    08.02.2005
    Ort
    in einer deutschen Kleinstadt
    Beiträge
    2.361

    Standard

    interessant finde ich auch, daß es Asteroiden gibt, die eine hufeisenförmige Bahn beschreiben...

    Earth shares its orbit around the Sun with an asteroid in an exotic horseshoe-shaped orbit, say astronomers....
    Apostolos Christou and David Asher at the Armagh Observatory in Northern Ireland say they've found one--an asteroid called 2010 SO16
    http://www.technologyreview.com/blog/arxiv/26608/
    Gruß von Ispom

  3. #13
    Registriert seit
    10.05.2009
    Beiträge
    231

    Standard

    Zitat Zitat von mac Beitrag anzeigen
    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!

  4. #14
    Registriert seit
    11.03.2006
    Beiträge
    5.891

    Standard

    Hallo Runzelrübe,

    Zitat Zitat von Runzelrübe Beitrag anzeigen
    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.


    Zitat Zitat von Runzelrübe Beitrag anzeigen
    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?


    Zitat Zitat von Runzelrübe Beitrag anzeigen
    Informiert euch dazu bitte über robust geometric computing.
    danke für den Link!


    Zitat Zitat von Runzelrübe Beitrag anzeigen
    Das allerschlimmste an Simulationen ist das Vertrauen in den Computer!
    Ja!

    Herzliche Grüße

    MAC

  5. #15
    Registriert seit
    10.05.2009
    Beiträge
    231

    Standard

    Hi MAC,

    Zitat Zitat von mac Beitrag anzeigen
    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.

    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/

    Zitat Zitat von http://www.ima.umn.edu/~arnold/disasters/sleipner.html
    The shear stresses were underestimated by 47%, leading to insufficient design. In particular, certain concrete walls were not thick enough
    Zitat Zitat von http://www.ima.umn.edu/~arnold/disasters/patriot.html
    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.

  6. #16
    Registriert seit
    08.06.2008
    Beiträge
    322

    Standard

    Zitat Zitat von Runzelrübe Beitrag anzeigen
    Das allerschlimmste an Simulationen ist das Vertrauen in den Computer!
    Es gibt Methoden, um Simulationen sehr gruendlich zu testen. Vertrauen allein reicht niemals beim Programmieren.

  7. #17
    Registriert seit
    09.05.2006
    Ort
    Thüringen
    Beiträge
    632

    Standard

    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
    Absence of evidence does not mean evidence of absence. - Dan Werthimer

  8. #18
    Registriert seit
    11.03.2006
    Beiträge
    5.891

    Standard

    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. 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
    Geändert von mac (07.04.2011 um 01:05 Uhr)

  9. #19
    Registriert seit
    09.05.2006
    Ort
    Thüringen
    Beiträge
    632

    Standard

    Zitat Zitat von mac Beitrag anzeigen
    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.
    Zitat Zitat von mac Beitrag anzeigen
    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
    Geändert von SRMeister (09.04.2011 um 17:05 Uhr)
    Absence of evidence does not mean evidence of absence. - Dan Werthimer

  10. #20
    Registriert seit
    10.05.2009
    Beiträge
    231

    Standard

    Werbung
    Zitat Zitat von SRMeister Beitrag anzeigen
    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.

Ähnliche Themen

  1. Abstand zwischen Photon und Erde
    Von lambda im Forum Astronomie allgemein
    Antworten: 65
    Letzter Beitrag: 26.11.2009, 21:44
  2. Unser Sonnensystem einmal anders betrachtet!
    Von Elling im Forum Sonnensystem allgemein
    Antworten: 20
    Letzter Beitrag: 02.03.2007, 19:57
  3. Für ein Referat: Warum kann man nicht im Weltall überleben?
    Von Nairobie im Forum Sonnensystem allgemein
    Antworten: 7
    Letzter Beitrag: 29.09.2006, 23:39
  4. Vorschlag zur Benennung von Körpern im Planetensystem
    Von Anac im Forum Sonnensystem allgemein
    Antworten: 1
    Letzter Beitrag: 31.03.2006, 15:51
  5. Albert Einstein und unser Sonnensystem
    Von Elling im Forum Astronomie allgemein
    Antworten: 33
    Letzter Beitrag: 18.02.2006, 22:57

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
astronews.com 
Nachrichten Forschung | Raumfahrt | Sonnensystem | Teleskope | Amateurastronomie
Übersicht | Alle Schlagzeilen des Monats | Missionen | Archiv
Weitere Angebote Frag astronews.com | Forum | Bild des Tages | Newsletter
Kalender Sternenhimmel | Startrampe | Fernsehsendungen | Veranstaltungen
Nachschlagen AstroGlossar | AstroLinks
Info RSS-Feeds | Soziale Netzwerke | Flattr & freiwilliges Bezahlen | Werbung | Kontakt | Suche
Impressum | Nutzungsbedingungen | Datenschutzerklärung
Copyright Stefan Deiters und/oder Lieferanten 1999-2013. Alle Rechte vorbehalten.  W3C