TheiaSim

Bernhard

Registriertes Mitglied
Ich denke, 20° Streuung um die Ekliptik sind realistisch (man kann das ja mal als freien Parameter gestalten und immer noch ändern, wenn nötig / EDIT: Bernhard hat das offenbar bereits gemacht).
Hallo Bynaus,

ich habe vorerst nur den Tip von Ich eingebaut um die Kugelsymmetrie zu gewährleisten. Die Beschränkung auf 20° Streuung baue ich dann noch ein. Hier bietet sich ein define in der Datei Constants.h an.
 

SRMeister

Registriertes Mitglied
ja Bernhard, werde ich ab jetzt so machen.
Wo wir gerade dabei sind: Nur Membervariable mit m_Xyz benennen, Parameter von Funktionen bitte als Xyz benennen.
Und wenn man merkt, dass in 2 klassen 90% gleich ist, dann am besten gleich beide von einer gemeinsamen Basisklasse ableiten. Das habe ich jetzt nochmal gemacht, also nicht wundern. Basisklasse CParticle abgeleitete Klassen CPlanet, CTestParticle.
Das musste ich jetzt auch machen, da die Schnittstelle nurnoch möglichst wenig geändert werden soll.
Ich will ja eigentlich in Deiner Baustelle nicht viel rumdoktorn, aber jetzt musste das nochmal sein :)

Das GUI ist bald fertig!
 

Bernhard

Registriertes Mitglied
Wo wir gerade dabei sind: Nur Membervariable mit m_Xyz benennen, Parameter von Funktionen bitte als Xyz benennen.
Das kenne ich genauso und macht auch wirklich Sinn. Dummerweise haben wir vermutlich immer noch massenweise Membervariablen ohne das Prefix.

Basisklasse CParticle abgeleitete Klassen CPlanet, CTestParticle.
Wäre da nicht CBody besser?

Das GUI ist bald fertig!
Sehr gut.
 

SRMeister

Registriertes Mitglied
okay, gib mir bitte bis morgen zeit, bevor du große Veränderungen einbaust, sonst kommen wir uns evtl irgendwo in die Quere. Ich mach jetzt alles ordentlich objektorientert (abstrakte Basisklassen) und vor allem versuche ich alle "doppelten Algorithmen" noch aufzulösen - also alles auf einen Ursprung zurückzuführen.
 

SRMeister

Registriertes Mitglied
so ich konnte jetzt alle redundanten Klassen und Funktionen aufräumen und das GUI erstmal damit lauffähig bekommen.

Link

Ich habe dabei auch die doppelten Integratorfunktionen wieder gelöscht. Deswegen ist die Komplexität momentan quadratisch steigend. Das kann man auch mit dem GUI beweisen, denn bei doppelt so vielen Körpern dauert die Berechnung pro Step viermal so lange.

Kannst du bitte versuchen in die CNewton::Evaluate() wieder Bedingungen einzubauen, damit die Berechnung für die Testpartikel wieder stimmt (und Komplexität wieder linear wird)?

Außerdem ist da auch ein Fehler, wodurch die Testpartikel wild durch die Kante springen, da ist wohl die Rechnung irgendwo falsch.

Außerdem werden die Testpartikel jetzt immer an der aktuellen Stelle der Erde (plus Entfernung) erstellt.
Es gibt noch 100 andere kleine Änderungen.
Ich bin soweit fertig mit dem Integrator und würde Dir das Feld wieder überlassen, aber worum ich Dich jetzt bitten würde:
Die Klasse PSystem benötigt vorerst keine Änderungen - das ist quasi die Schnittstelle für die DLL, das heißt, dass du bitte das Programm nur soweit verändern solltest, dass die dort genannten Funktionen ihre Gültigkeit behalten, also du kannst den Inhalt (Definition in CNewton) gern ändern, nur die Deklaration(Funktionsname in PSystem) nicht. Und bitte versuchen, neue Funktionalität immer "unterhalb" dieser Funktionen zu implementieren. Ich hoffe das ist jetzt verständlich erklärt, sonst nochmal bescheid sagen.


Wenn du jetzt Änderungen vornimmst und im GUI testen willst, brauchst du nur oben bei Projektkonfigurationen "Release - DLL" auswählen, dann erzeugt er die DLL, die musst du einfach in das Verzeichnis vom GUI kopieren.
Grüße
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Ich habe dabei auch die doppelten Integratorfunktionen wieder gelöscht. Deswegen ist die Komplexität momentan quadratisch steigend.
Hallo SRMeister,

die Testkörper werden anders berechnet, als die Planeten, weil diese gravitativ nicht auf die Planeten einwirken. Du hast beim Aufräumen also eine ganze Menge Arbeit von mir zerstört!! Die Trennung in der Berechnung zwischen Planeten und Testkörper sollte erhalten bleiben, so wie es in Version 23 noch implementiert war. Ich hatte das hier im Forum übrigens auch so erwähnt. EDIT: Aber gut. Nachdem ich auch heute etwas Zeit über habe, baue ich die Funktionen halt wieder ein. Lass Sie zukünftig aber bitte drin. Bynaus hat diese Strukturierung ebenfalls gut geheißen.

Das kann man auch mit dem GUI beweisen, denn bei doppelt so vielen Körpern dauert die Berechnung pro Step viermal so lange.
Scheinbar geht die Laufzeit für die Berechnung der Planeten eben quadratisch. Hättest Du die alten Funktionen drin gelassen, würde die Laufzeit mit der Anzahl der Testkörper linear steigen

Außerdem ist da auch ein Fehler, wodurch die Testpartikel wild durch die Kante springen, da ist wohl die Rechnung irgendwo falsch.
Bei der Initialisierung der Geschwindigkeit der Testkörper habe ich die Geschwindigkeit der Erde vergessen. Das läßt sich relativ leicht beheben.

Außerdem werden die Testpartikel jetzt immer an der aktuellen Stelle der Erde (plus Entfernung) erstellt.
So soll es ja auch sein. Die Testpartikel sollen an der Erdoberfläche starten.

Und bitte versuchen, neue Funktionalität immer "unterhalb" dieser Funktionen zu implementieren.
So lange sich alles übersetzen läßt einverstanden.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Die Trennung in der Berechnung zwischen Planeten und Testkörper sollte erhalten bleiben, so wie es in Version 23 noch implementiert war.
Hallo SRMeister,

Du hast vergessen die Dateien der Implementierung von CBody hinzuzufügen -> rechte Maustaste TotoiseSVN/Add. Ich werde dann doch warten, bis das Projekt wieder übersetzbar ist. Vielleicht fügst Du dabei auch gleich die Funktionen EvaluateTP, DoStepMidpoint4TP, DoStepBS4TP wieder mit ein. Die unterscheiden sich nämlich von den Funktionen ohne TP.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Bedenke z.B. dass die Fragmente am Anfang eine Geschwindigkeit von ~<1.4 v_esc relativ zur Erde haben.
Hallo Bynaus,

erste Rechnungen mit einer lokalen Kopie des Programmes zeigen, dass sich bei einer relativen Startgeschwindigkeit von 1.0 * v_esc bis 1.4 * v_esc die Fragmente (bis auf statistische Ausnahmen) nach ein paar Jahren z.T. bei über 5e4 AE Abstand von der Sonne befinden, also wirklich sehr weit draußen. Kann das stimmen?
 

Bynaus

Registriertes Mitglied
erste Rechnungen mit einer lokalen Kopie des Programmes zeigen, dass sich bei einer relativen Startgeschwindigkeit von 1.0 * v_esc bis 1.4 * v_esc die Fragmente (bis auf statistische Ausnahmen) nach ein paar Jahren z.T. bei über 5e4 AE Abstand von der Sonne befinden, also wirklich sehr weit draußen. Kann das stimmen?

Nun, schon möglich, je nach dem, in welche Richtung die Trümmer davonfliegen. Wenn die Erde eine Orbitalgeschwindigkeit von 30 km/s hat, dann ist die Fluchtgeschwindigkeit da sqrt(2)*30km/s, also etwa 42 km/s. Die Fluchtgeschwindigkeit der Erde beträgt 11 km/s, und 1.4 mal diese Geschwindigkeit ist 15 km/s. Das heisst, viele der Trümmer werden wohl mit lokaler Fluchtgeschwindigkeit (rel. zur Sonne) unterwegs sein, was durchaus erklären könnte, warum sie so schnell soweit weg sind (und wohl auch nie zurück kommen...).

Hm. Mit wievielen Teilchen hast du denn das bisher getestet? bzw., wieviele "statistische Ausnahmen" gibt es? Ich geh dem mal nach, 1 - 1.4 v_esc ist die Anfangsgeschwindigkeit von Theia relativ zur Erde im Modell, ich hab das jetzt einfach "ungebremst" auf die Trümmer übertragen, aber es kann natürlich sein, dass die Trümmer üblicherweise langsamer unterwegs sind. Anderseits können sie wohl kaum langsamer als mit 1 v_esc unterwegs sein, sonst wären sie wohl gebremst worden und zur Erde zurückgefallen.

Übrigens: hier könnte man sich auch noch inspirieren lassen: http://www.jstor.org/stable/2890263

EDIT: Aha, halt, natürlich (siehe Bemerkung 15 im oben verlinkten Paper). Um die Endgeschwindigkeit eines Teilchens, das ein Gravitationsfeld verlässt, zu berechnen, kann man natürlich nicht einfach addieren. Die Endgeschwindigkeit relativ zum Planeten wird v_inf = sqrt (v_0^2 - v_esc^2) betragen, wobei v_0 den oben genannten Wert von 1 - 1.4 v_esc haben soll. Ich denke, das sollte das Problem lösen.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
In der Berechnung ist noch ein Fehler, weil die Ortsänderungen der Testkörper noch größer sind, als Startgeschwindigkeit * Simulationszeit. Ich versuche dann mal denn Fehler zu finden...
 

Bernhard

Registriertes Mitglied
Hallo zusammen,

habe den Fehler schon gefunden. Bei der Berechnung der Fluchtgeschwindigkeit habe ich die Fluchtgeschwindigkeit einmal zu oft berücksichtigt und dadurch quadriert. Die neuen Zahlen über 10 Jahre sind sehr interessant. Die 10 Trümmer verteilen sich dabei auf ein Gebiet zwischen 0.66 und gut 6 AE!! :cool: :cool: .

Sobald SRMeister mit seinen Änderungen fertig ist, können wir nach Lust und Laune simulieren, was das Zeug hält... :)
 

SRMeister

Registriertes Mitglied
okay ich hab es wieder eingesetzt, auch wenn es meiner Ansicht nach nicht schön ist, weil die Funktionen zu 99% identisch sind, wie ich sehe sind DoStepMidpoint und DoStepMidpoint4TP sogar komplett identisch, bis auf die Elemente für die sie ausgeführt werden. Schöner wäre es, wenn man jeweils nur eine Funktion hätte, und die Berechnung je nach (if Mass() == 0) unterschiedlich wäre. Aber das überlasse ich jetzt dir.

Übrigens habe ich einen Bug entdeckt, der möglicherweise die ganze Zeit da war, und der möglicherweise die letzten 60km Differenz erklären könnte, die wir damals noch zum JPL hatten.

PHP:
void CNewton::Evaluate(double dt, int i)
{
...
for( m_source = m_sun; m_source != m_Last; m_source = m_source->next )
}
2 forSchleifen waren unvollständig, da sie bereits beim vorletzten Element der LinkedList aufhörten.
korrekt wäre (und war auch fast überall korrekt):
PHP:
for( m_source = m_sun; m_source != NULL; m_source = m_source->next )

Die Testparticle fliegen immer noch wild umher. Kann man im GUI bei Detail View gut sehen. (Edit: oh okay dann bis gleich :) )

Grüße
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Hallo SRMeister,

Nochmal zur generellen Struktur des Programmes:

a) Planeten und Testkörper sollten wirklich strikt voneinander getrennt werden. D.h. getrennte Listen und getrennte Funktionen damit die Performance nicht leidet. Wenn Du bei jeder Funktion die gemeinsame Liste erst filterst wird das Programm meiner Meinung nach zu langsam.

b) TP soll immer für Test Particle stehen und nicht für Planet. Sonst verliert man viel zu leicht den Überblick, was das Programm eigentlich berechnet.

c) Die Bedingung m=0 halte ich für eine Unterscheidung der zwei Listen deswegen für ungeeignet, weil ein Testkörper später vielleicht auch mal eine Masse haben kann/soll.

Die Fehler in der Bewegung der Testkörper (= Test particle) sind übrigens sehr schnell behoben, weswegen ich zuerst die allgemeine Struktur des Programmes klären möchte. Wir müssten auch noch klären, wer jetzt weiter machen soll/will.
 

SRMeister

Registriertes Mitglied
Hallo SRMeister,

Nochmal zur generellen Struktur des Programmes:

a) Planeten und Testkörper sollten wirklich strikt voneinander getrennt werden. D.h. getrennte Listen und getrennte Funktionen damit die Performance nicht leidet. Wenn Du bei jeder Funktion die gemeinsame Liste erst filterst wird das Programm meiner Meinung nach zu langsam.
Das würde ich so nicht sagen. Getrennte Listen, vielleicht. Aber getrennte Funktionen? Schau mal, die sind fast identisch. Sowas ist keine ordentliche Programmierung. Die Performance leidet ganz sicher nicht, wenn man ganz zu Anfang der Fkt. einmal den Startpunkt oder Endpunkt festlegt (FirstTP = erster TP)
eine simple if abfrage wegen der Masse ist sogut wie kostenlos (die CPU schafft sowas in 1/2 Taktzyklus und der Compiler versteckt das wahrscheinlich sowieso weshalb es ganz kostenlos ist)

b) TP soll immer für Test Particle stehen und nicht für Planet.
Hab ich es irgendwo falsch verwendet? Dachte eigentlich nicht.

c) Die Bedingung m=0 halte ich für eine Unterscheidung der zwei Listen deswegen für ungeeignet, weil ein Testkörper später vielleicht auch mal eine Masse haben kann/soll.
Dann kann man es ja so machen, dass Mass() nur unter bestimmten Bedingungen eine Masse ausgibt. Schon jetzt kann man theoretisch dem TP eine Masse geben die aber nicht über Mass() ausgegeben wird. Das wäre die elegantere Variante und auch aus objektorienterter Sicht sinnvoll. Denn nur das Objekt selbst soll seine Eigenschaften bestimmen, nicht die Funktionen die es benutzen.


Die Fehler in der Bewegung der Testkörper (= Test particle) sind übrigens sehr schnell behoben, weswegen ich zuerst die allgemeine Struktur des Programmes klären möchte. Wir müssten auch noch klären, wer jetzt weiter machen soll/will.
Also mein Vorschlag wäre wirklich, dass wir einheitliche Funktionen für alle Klassen von Objekten benutzen. Es kann ja auch später noch andere Unterteilungen geben (zb mit Radius, ohne Radius usw) willst du dann wieder alle Integratorfunktionen verdoppeln?

a) Man könnte ja 2 getrennte LinkedLists machen und die beiden dann unabhängig durchlaufen.

b) Zu den TP-Fehler: Ich würde außerdem noch das Objekt Erde direkt an den TP-Konstruktor übergeben, dann kann er sich dort die Pos und Vel rausziehen. Ist doch besser als über 6 Argumente.

Wenn a+b okay ist, dann würde ich das noch schnell machen.
 

UMa

Registriertes Mitglied
Hallo,

ich würde es so implementieren:
Keine Unterscheidung zwischen Planeten und Testköpern, aber alle massebehafteten Körper zuerst im Array. Dann braucht man nur die Beschleunigungsberechnung so zu ändern, dass dort die Schleife nur bis "nm" geht. Alle anderen Schleifen weiterhin bis "n". Wenn "n" die Gesamtzahl der Körper ist und "nm" die Anzahl der ersten "nm", die eine Masse haben und deren Gravitation berücksichtigt wird.

Grüße UMa
 

SRMeister

Registriertes Mitglied
so wie du vorschlägst ist das Array(eig. Verkettete Liste) ja aufgebaut, aber es gibt trotzdem 2 Sätze von Integratorfunktionen, obwohl die fast identisch sind, bis auf eine.
 

Bernhard

Registriertes Mitglied
Damit wir uns hier nicht endlosen Formfragen verlieren habe ich meine aktuelle Version eingespielt. Die Verteilung nach zehn Jahren geht doch etwas weiter raus, aber probiert es einfach selbst mal aus.
 
Zuletzt bearbeitet:
Oben