Gravitationssimulation: Simulationsgeschwindigkeit - Berechnungsintervall

[fishbrain]

Für die anstehende Seminararbeit (Thema: Planetenbahnen im Doppelsternsystem) brauche ich eine anständige Simulation.
Nun habe ich selbst was geschrieben bin aber jetzt schon auf Probleme gestoßen:

In Sonnensystemen allgemein und in Doppelsternsystemen im Besonderen gibt es enorme unterschiede in den Umlaufzeiten der Planeten/Sonnen.
Zb. hat Merkur nur eine Umlaufzeit von ca 87 Tagen während schon Jupiter 12 Jahre braucht.
D.h. man kann nicht beide gleichzeitig sinnvoll anzeigen. (prinzipiell kein Problem)
Das Problem an der Sache ist aber nun, dass wenn eine Simulationsgeschwindigkeit gewählt wird, die für das Betrachten von Jupiter geeignet ist, dass die Berechnungsintervalle für Merkur zu klein werden.

Praktisch endet das meist in einer Änderung der Umlaufbahn wenn nicht sogar in einem Verlassen des Systems.


Meine bisherige Lösung:

Zeichenmethode und Berechnungsmethode trennen:
Die Zeichenmethode wird per Timer alle 30ms aufgerufen und die Berechnungsmethode bei Application.onIdle.

Dabei kriege ich im Leerlauf 150.000 Berechnungen pro Sekunde und 33 FPS.
Bei allen inneren Planeten + Sonne (also 5 Körper) sind es ca 50.000 BPS.

Nun meine Frage:
Macht meine bisherige Lösung (konstante FPS soviel BPS wie möglich) Sinn?
Bzw. ist dieses Problem mit normalen Rechnern überhaupt lösbar?

Für meine Seminararbeit sollten Merkur + Saturn gut laufen.

Wäre über Ideen dankbar

[jfheins]

Zitat:

Zitat von fishbrain (Beitrag 1047120)

Nun meine Frage:
Macht meine bisherige Lösung (konstante FPS soviel BPS wie möglich) Sinn?
Bzw. ist dieses Problem mit normalen Rechnern überhaupt lösbar?

Für meine Seminararbeit sollten Merkur + Saturn gut laufen.

Wäre über Ideen dankbar

Ob das Sinn macht musst du wissen ;) Das kommt auch drauf an, wie weit in die Zukunft du denn rechnen möchtest. Bei kleinen Intervallen wird das System später chaotisch als bei großen intervallen, weil bei großen Intervallen der Fehler größer ist. (Im Normalfall)

Um Merkur und Saturn gut darzustellen bräuchtest du eben Intervalle, mit denen Merkur noch funktioniert. Saturn geht dann ziemlich sicher auch noch. Wenn das dann zuviele Berechnungen werden kannst du versuchen, z.b. Jupiter und Saturn nur jeden 2. Berechnungsschritt zu berechnen.

[igel457]

Dazu gibt es IMHO mehrere mögliche Lösungsvorschläge, die sich auch kombinieren lassen:

1. Musst du wirklich simulieren oder kannst du die Bahnen nicht auch Berechnen?
2. Verwende keine Fließkommazahlen sondern ein Record mit zwei Int64, einen für den Ganzzahl- und einen für den Dezimalteil. Durch Operatorüberladung kannst du diesen Typen dann ganz normal verwenden.
3. Trenne Darstellung und Berechnung - Lagere die Simulation in einen eigenen Thread aus, der mit voller Systemauslastung und somit kleinstmöglichen Intervallen läuft und lasse nur die Darstellung im Timer

Ich hatte mal ein ähnliches Problem - dabei ging es aber nur um die Indexierung von Audiosamples in einem großen Zeitraum - meine Lösung war es keinen Extended (80 Bit) sondern einen Int64 mit festen 16 Bit Nachkommastellen zu verwenden.

[BUG]

Zitat:

Zitat von igel457 (Beitrag 1047164)

1. Musst du wirklich simulieren oder kannst du die Bahnen nicht auch Berechnen?

Das sollte schwer werden: Dreikörperproblem

[igel457]

Überzeugt ;-)

[fishbrain]

@jfheins:
Es geht nicht darum, dass Saturn zu kleine Zeitintervalle in der Berechnung hat, sondern Merkur zu große. Du musst dir vorstellen: wenn man Saturn so anzeigen will, dass man nicht einschläft bevor er die Sonne einmal umkreist braucht man eine Geschwindigkeit die bewirkt, dass Merkur in einer Sekunde mehrmals die Erde umkreist.
Bei der Umrechnung von Kraft auf Beschleunigung ruft das dann erhebliche Ungenauigkeiten hervor. Je größer das Intervall zwischen den Berechnungen desto größer die Ungenauigkeiten.



Also zusammengefasst habe ich zwei Möglichkeiten das hinzukriegen:
1. Optimierung des Berechnungsprozesses
2. Extra Thread nur für die Berechnung

Ich denke, dass alleine langt nicht. Wahrscheinlich werde ich eine Art Notbremse einbaun, die die Simulationsgeschwindigkeit bei kritischen Werten einfach automatisch senkt.

Wird der Pc halt nacht für nacht durchlaufen ;).

[Die Muhkuh]

Zitat:

Zitat von fishbrain (Beitrag 1047581)

Geschwindigkeit die bewirkt, dass Merkur in einer Sekunde mehrmals die Erde umkreist.

Interessant :mrgreen:

[Sir Rufo]

Zitat:

Zitat von Die Muhkuh (Beitrag 1047601)

Zitat:

Zitat von fishbrain (Beitrag 1047581)

Geschwindigkeit die bewirkt, dass Merkur in einer Sekunde mehrmals die Erde umkreist.

Interessant :mrgreen:

Das kommt durch die erwähnten Ungenauigkeiten :mrgreen:

[fishbrain]

Zitat:

Zitat von Sir Rufo (Beitrag 1047603)

Zitat:

Zitat von Die Muhkuh (Beitrag 1047601)

Zitat:

Zitat von fishbrain (Beitrag 1047581)

Geschwindigkeit die bewirkt, dass Merkur in einer Sekunde mehrmals die Erde umkreist.

Interessant :mrgreen:

Das kommt durch die erwähnten Ungenauigkeiten :mrgreen:

Ok das war fail. Natürlich die Sonne. War etwas müde als ich das geschrieben hab.

[Klaus01]

..ups, ist die Erde denn nicht mehr der Mittelpunkt des Universums ;-)

Grüße
Klaus

[ub60]

Also, ich hab das Ganze vor mehr als 15 Jahren in Pascal geschrieben. Geschwindigkeit ist kein Problem, Genauigkeit bei "normalen" Planetenbewegungen auch nicht.
Mein damaliger Ansatz war einfach das Gravitationsgesetz (zwischen beliebig vielen Körpern) und eine ständige Neuberechnung des x- und y-Anteils der Geschwindigkeit.

ub60

[fishbrain]

Zitat:

Zitat von ub60 (Beitrag 1047712)

Also, ich hab das Ganze vor mehr als 15 Jahren in Pascal geschrieben. Geschwindigkeit ist kein Problem, Genauigkeit bei "normalen" Planetenbewegungen auch nicht.
Mein damaliger Ansatz war einfach das Gravitationsgesetz (zwischen beliebig vielen Körpern) und eine ständige Neuberechnung des x- und y-Anteils der Geschwindigkeit.

ub60

Wie hast du das genau gemacht? Hast du die Kraft von der Sonne auf jeden Planeten gerechnet oder von jeder Masse zu jeder Mass? Bzw hast du alle Planeten angezeigt oder nur die inneren / äußeren?
Das mit der ständigen neuberechnung des x/y anteils versteh ich auch nicht. Hast du nur einmal die Geschwindigkeit berechnet und dann nurnoch die Richtung der Geschwindigkeit geändert?

[ub60]

Zitat:

Zitat von fishbrain (Beitrag 1047713)

Wie hast du das genau gemacht? ... oder von jeder Masse zu jeder Masse?

Genau so.

Hier einige Details:

• Ich habe nur zweidimensional gerechtet, dreidimensional würde aber analog gehen.
• Wählen eines (kartesischen) Koordinatenursprungs für die Berechnung (beliebig, die Sonne wäre aber ganz gut, muss jedoch nicht sein).
• Eingabe der Anfangsgeschwindigkeiten bezüglich des Ursprungs, dabei Geschwindigkeit in x- und y-Anteil trennen.
• Als Beispiel: Wenn die Sonne in der Mitte ist und die Erde unter der Sonne (bei 270°) nach rechts fliegen soll (also Umkreisen gegen den Uhrzeigersinn), so ist der x-Anteil die Bahngeschwindigkeit, der y-Anteil gleich 0.
• Jetzt in einer Schleife für alle beteiligten Objekte:
  • Berechnung der Abstände untereinander (verschachtelte Schleife),
  • Berechnung der Kräfte, über die Positionen Berechnung der x- und y-Anteile der Kräfte,
  • Addition aller Kräfte,
  • mit Hilfe der Masse Berechnung der Beschleunigungs- bzw. Geschwindigkeitsanteile,
  • mit Hilfe des gewählten Intervalls Bestimmung der neuen Koordinaten.

So, ich hoffe, das hilft. Ist ja schon fast das ganze Programm :):)

ub60

[Caps]

Ich habe sowas auch schonmal geschrieben, allerdings nicht mit "Merkur" und "Saturn" sondern mit einem anonymen Massepunkt. Ich weiß ja nicht, was von Dir erwartet wird, aber ich glaube schonmal eine Sonnensystem-Animation gesehen zu haben (Abenteuer Forschung o.ä.) und da waren die Bewegungen aller Planeten noch relativ gut erkennbar.
So (http://www.youtube.com/watch?v=ZGKCYRGotGc) sollte es wahrscheinlich lieber nicht werden, da erscheint mir einiges falsch, ich dachte ich suche mal ein Beispiel, aber das hier ist anscheinend totaler Schrott.
Die zu großen Geschwindigkeitsunterschiede waren doch das eigentliche Problem, oder?

Viele Grüße
Caps

[fishbrain]

So ich habe nun die Berechnung in nen extra thread ausgelagert. Bei 3 Objekten hab ich noch 200k Berechnungen pro Sekunde. Das sollte für die meisten Fälle langen. In kritischen Situationen wird die Notbremse gezogen ;)

Vielen Dank für eure Ideen

[fishbrain]

Ok hab noch eine Verbesserung falls es jemanden interressiert:
Anstatt den Zeitunterschied zwischen den Messungen mit gettickcount zu messen benutze ich jetzt QueryPerformanceCounter. Logischerweise eine signifikante Verbesserung.

[ub60]

Zitat:

Zitat von fishbrain (Beitrag 1048328)

Ok hab noch eine Verbesserung falls es jemanden interressiert:

Also, mich interessiert nicht nur die Verbesserung, sondern das ganze Programm :-D
Gibt es das irgendwo?
Vorzugsweise den Quelltext?
Aber die Hauptfrage: In welchen zeitlichen Abständen berechnest Du die Phasen der Simulation (die einzelnen Schritte der Bewegung)?

ub60

[fishbrain]

hm ich denke ich werde bald (1-2 Wochen) die erste Version uploaden. Ob OS oder nicht weiß ich noch nicht.

Zu den zeitlichen Abständen:
Angenommen wir simulieren 2 Objekte, dann wird im Schnitt 800000 mal pro Sekunde gerechnet. Wenn wir jetzt eine Simulationsgeschwindigkeit von 1s entspricht 1 Jahr nehmen macht das eine Berechnung alle 38s Simulationszeit. Das sollte für die meisten Fälle genügen. Aber das wirklich interressante daran ist ja, dass dieses Intervall in der realität Null ist ;). Crazy wenn man drüber nachdenkt