Newtons Gravitation mit GNUPlot und Python

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

@birkenfeld: Das Problem lag an einer falschen Formel von Agroschim. Bei ihm und bei mir klappte es zufällig weil ** (1/2) <=> ** 0 bzw. ** (3/2) <=> ** 1. Bei Dir funktionierte es aber nicht mehr, da Du korrekt r ** 3 berechnet hast, im Gravitationsgesetz muss es aber natürlich im Nenner r ** 2 sein.

Edit: Kommando zurück. In der vektoriellen Form muss natürlich doch r ** 3 im Nenner stehen. Die bisher schönen Grafiken dürften deshalb wohl einfach falsch schön sein. Man muss wohl einfach ein paar andere Planetendaten ausprobieren. Hier ein etwas besser funktionierendes Beispiel mit halbwegs attraktiven Grafiken: http://paste.pocoo.org/show/4022/. Die Skalierung der Kraftvektoren ist allerdings noch nicht ideal, so dass diese z.T. etwas wüst verlaufen.

MfG
HWK
Benutzeravatar
Agroschim
User
Beiträge: 28
Registriert: Sonntag 16. September 2007, 15:19

Hui, hier wird einem ja geholfen! Ich arbeite mich die Tage mal dadurch, heute finde ich keine Zeit mehr dafür! Vielen Dank jedenfalls schon mal!
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

So, jetzt ist auch das Problem mit der Vektordarstellung gelöst. Plot stellt scheinbar Vektoren in der Form (x y dx dy) dar und nicht (x1 y1 x2 y2). Ich habe eine Variante geschrieben, wo die Skalierung statisch im Programm festgelegt wird, http://paste.pocoo.org/show/4033/ und eine Version mit dynamischer Skalierung je nach der größten Kraft http://paste.pocoo.org/show/4032/. Aber auch diese Variante scheitert bei großen Kräften zwischen Punkten am Bildschirmrand.
MfG
HWK

Edit: Ich habe noch eine Variante mit Numpy geschrieben: http://paste.pocoo.org/show/4101/. Diese ist nicht so schön wie birkenfelds Vorschlag, aber auch nicht so schlecht. Einen Geschwindigkeitsgewinn kann ich subjektiv bisher nicht erkennen. Möglicherweise ist sie aber bei deutlich mehr Planeten effektiver.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

Ein "physikalischer Fehler" entstand dadurch, dass die Vektoren berechnet wurden, nachdem a, v und s bereits geändert wurden. Diese waren deshalb nicht mit F konsistent. Es muss somit korrekt heißen:

Code: Alles auswählen

    for i, p in enumerate(planeten):
        # Die nächsten 4 Zeilen müssen vor den letzten 3 stehen
        plot[i].append([p.s.x, p.s.y])
        if iteration % 20 == 0:
            vektor[i].append(
                [p.s.x, p.s.y, F[i].x / 250, F[i].y / 250])

        p.a = F[i] / p.m
        p.v += p.a * dt
        p.s += p.v * dt
Nach dieser Änderung sehen die Kraftvektoren wesentlich glaubhafter aus. Am besten sieht man das bei lediglich 2 Planeten.
MfG
HWK
andreas1965
User
Beiträge: 9
Registriert: Dienstag 19. Dezember 2006, 21:13

Am rande bemerkt...
vielleicht kann decimal die fehlende genauigkeit der floats liefern. Bei Python2.5 unter Maxosx10.4 ist decimal wesentlich schneller als Numpy.

Andreas
BlackJack

Das ist ein Vergleich zwischen Äpfeln und Birnen. `numpy` ist für Matrix-Operationen und `decimal` sind einzelne Zahlen. Ich glaube kaum das entsprechende Klassen, die Matrizenoperationen mit `decimal` implementieren, schneller sind als `numpy`-Code.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

BlackJack hat geschrieben:Ich glaube kaum das entsprechende Klassen, die Matrizenoperationen mit `decimal` implementieren, schneller sind als `numpy`-Code.
Das kann ich mir auch nicht gut vorstellen. Und ob die größere Genauigkeit von 'decimal' hier wirklich einen Vorteil darstellt, wage ich auch zu bezweifeln.
MfG
HWK
Antworten