Skript hängt an willkürlicher Stelle! Threadproblem?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Donnerstag 1. November 2007, 13:15

Hallo!

Ich möchte Lösungen für die stationäre Schrödingergleichung finden per Iteration. Während der Iteration soll die entstehende Kurve auf ein TKinter.Canvas ge"malt" werden. Dafür hab ich die Iteration und den "Mal-Befehl" in einen eigenen Thread gepackt, sodass diese Dinge von der Tkinter mainloop unabhängig laufen. Mit diesem Verfahrensprinzip hatte ich auch schonmal Erfolg bei einem anderen Problem, wo ich auch Punkte während einer Rechnung/Iteration auf ein Canvas gezeichnet habe.

Mein jetziges Skript hängt sich samt IDLE (ich arbeite unter Windows) aber zu einem willkürlichen Zeitpunkt auf, bzw. ich habe nichtmal die Möglichkeit, den Punkt genau zu erkennen. Der Zeitpunkt ist aber immer weniger als eine Sekunde nach Programmstart. Ich habe soviele Log-Ausgaben in eine Ausgabe-Datei gemacht, wie ich konnte und nur anhand dieser stelle ich fest, dass das Skript mal weiter und mal weniger weit kommt in der Iteration. Das IDLE Fenster und mein Tkinter Fenster sind dann "eingefroren". Fehlermeldungen kommen nicht in der Shell (zumindest nicht, bevor das Shellfenster einfriert).

Aber: Ohne den extra Thread hängt sich die Iteration in genau derselben Form (also die gleichen Funktionen FindPsi(),NumerovInt(),NumerovUpdate(),k(),x(),V() ) NICHT auf!

Mir fällt nichts anderes ein, als Euch erstmal den gesamten Quelltext zu zeigen. Habe ihn mal hier ausgelagert:

http://nopaste.ch/e61060a444eb25d.html

Kurz zur Erläuterung:
In Zeile 24/25 wird der Rechen/Zeichnen-Thread definiert und gestartet:

Code: Alles auswählen

 calcPsiThread = CalcThread(sgn=1, E=0.7, dE=0.03, dEabort=1e-013)
 calcPsiThread.start()
Innerhalb des Threads calcPsiThread wird (s. Zeile 63) dann mit

Code: Alles auswählen

E = FindPsi(self.sgn, self.E, self.dE, self.dEabort)
die Iteration gestartet.

In Zeile 116

Code: Alles auswählen

      if n%20 == 0: #window.Point((n*breite/N),newPsi,2)
soll dann während der Iteration eigentlich jeder 20. Punkt gezeichnet werden. Ich habs hier auskommentiert; trotzdem gleiches Verhalten des Programms. Am Zugriff auf die Globale "window" liegts also schonmal nicht.

Überhaupt interagiert durch dieses Auskommentieren der Thread calcPsiThread gar nicht mehr mit dem Hauptprogramm. Wo könnte nur der Fehler liegen?

Ich wünschte ich könnte mein Problem ein bisschen besser durchschauen oder eingrenzen...
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

Donnerstag 1. November 2007, 13:46

Ich habe mir Dein Programm nicht angeschaut. Tkinter-Scripts sollte man aber nicht in IDLE ausführen, da diese selbst ein Tkinter-Programm ist und das zu unvorhersehbarem Verhalten führen kann. Verhält sich Dein Script denn auch so, wenn Du es aus der Konsole startest?
MfG
HWK
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Donnerstag 1. November 2007, 14:09

Ja, tut es. Aber es hängt sich erst ein kleines bisschen später auf!
EDIT: es verhält sich nicht exakt gleich. Das Fenster friert nicht ein! Aber die Berechnung bricht trotzdem irgendwann ab. Laut Log-Datei mit Timestamp auch innerhalb der ersten Sekunde. Aber es wird trotzdem mehr geschafft, als wenn ichs aus IDLE starte.
BlackJack

Donnerstag 1. November 2007, 14:15

Und auf die GUI darf man nur von dem Thread aus zugreifen, in dem auch die `mainloop()` läuft!
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Donnerstag 1. November 2007, 14:23

BlackJack:

Ich sehe bei meiner Methode gar nicht die Möglichkeit dazu! Übersehe ich etwas? Ich habe ja keine Interaktion des Nutzers mit der GUI.

Wenn die `mainloop()` erstmal gestartet wird und läuft, dann hängt das Programm bzw der Hauptthread, in meiner naiven Sprache zumindest, in dieser "Zeile" fest und verarbeitet Befehle, die an die GUI kommen. (So hab ich das bisher verstanden).

Nehmen wir mal an, ich will in diesem Zustand meine Methode `Point(self, x, y, dotsize)` aufrufen, um einen Punkt auf mein Canvas zu malen. Von wo aus soll ich bzw. der Iterationsalgorithmus (der muss dann doch auf jeden Fall in einem anderen Thread laufen?!) denn diese Methode aufrufen?
BlackJack

Donnerstag 1. November 2007, 16:05

Man kann wohl mittels Tkinter-Variablen (StringVar, IntegerVar, …) threadsafe kommunizieren. (Da bin ich mir jetzt aber nicht 100% sicher)

Man kann mit der `after()`-Methode auf den Widgets regelmässig Code ausführen lassen, zum Beispiel um über eine `Queue.Queue` mit den Threads zu kommunizieren. Die Threads packen Ergebnisse in die Queue und man schaut mit `after()` regelmässig nach ob's was zu tun gibt.

Und man kann seine eigene Mainloop schreiben. Muss man natürlich aufpassen, dass man regelmässig die GUI aktualisiert, damit die nicht scheinbar "einfriert" wenn nur gerechnet wird und gerade nichts anzuzeigen ist.
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Donnerstag 1. November 2007, 17:19

hm... also in diesem Thread gings vor ein paar Monaten um ein sehr sehr ähnliches Problem. http://www.python-forum.de/topic-8622.html

bei effbot.org hab ich folgende verschachtelung gefunden:

Code: Alles auswählen

class App:
    def __init__(self, master):
        self.master = master
        self.poll() # start polling

    def poll(self):
        ... do something ...
        self.master.after(100, self.poll)
koennte ich statt "... do something ... " meine FindPsi(self.sgn, self.E, self.dE, self.dEabort) - Methode aufrufen? Hab ich richtig verstanden, dass die `after` Methode niemals zum einfrieren der GUI führt? Selbst, wenn ich mit ihr etwas extrem aufwändiges, wie meine Iteration, aufrufe?
BlackJack

Donnerstag 1. November 2007, 18:39

Die führt zum Einfrieren wenn sie lange braucht. Wie der Name andeutet ist die zum Abfragen gedacht, ob etwas zu tun ist, also Ergebnisse vorliegen die gezeichnet werden müssen.
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Freitag 2. November 2007, 09:35

Guten Morgen!

Ich hab mich jetzt bisschen von Euch irritieren lassen.. :-) Ich schrieb ja folgendes:
Überhaupt interagiert durch dieses Auskommentieren der Thread calcPsiThread gar nicht mehr mit dem Hauptprogramm. Wo könnte nur der Fehler liegen?
Also: So, wie das Skript im Moment gestrickt ist, kommt es auch zu dem Fehler, ohne, dass ein Thread etwas mit dem anderen zu tun hat. Daher bin ich jetzt wieder total hilflos :/ Wie kann es dann zu so einem willkürlichen Hänger kommen?

Ich sehe ein, dass das vielleicht ne ganze Menge Quelltext ist und keiner Lust hat, sich da reinzudenken. Mit meinen Hinweisen aus dem ersten Posting gelingt das aber, hoffe ich, schon relativ zügig..
BlackJack

Freitag 2. November 2007, 15:24

Also bei mir läuft das Programm. Ich habe zwar keine Ahnung was es tut, aber es logt fleissig vor sich hin. Darum ein paar allgemeine Anmerkungen:

Punkt eins: Style Guide. Du machst es ja nicht einmal konsistent "falsch", sondern mischt munter alle möglichen Stile. :-)

``global`` ist böse! Nicht benutzen! Auf Modulebene ist es völlig sinnlos und in den meisten Funktionen brauchst Du es auch gar nicht! Man braucht es nur wenn man in einer Funktion einem Namen auf Modulebene etwas zuweisen möchte. Und das sollte man nicht wollen, weil es den Datenfluss im Programm undurchsichtiger macht. Zum Beispiel wird in `canvasWindow.__init__()` ein lokales `breite` benutzt und nicht das globale. Das sind Sachen die man sich immer überlegen muss, wenn man ``global`` im Programm hat ─ wo kommt der Name hier jetzt eigentlich gerade her und wo wird er verändert.

Überflüssig ist zum Beispiel ``global`` für `breite` in `main()` oder `h` in `x()` und `NumerovUpdate()`.

`canvasWindow.onQuit()` ist in der Form überflüssig, man könnte gleich `sys.exit` als Funktion für 'WM_DELETE_WINDOW' angeben.

Bei `canvasWindow.Point()` wird das `dotsize`-Argument nicht benutzt.

`CalcThread` ist ein wenig kompliziert um eine Funktion zu starten. Das geht auch mit dem `target`-Argument von `threading.Thread()`.

Ansonsten könnte es der Übersichtlichkeit helfen, wenn die ``global``\s verschwinden und die Berechnung von der GUI abgekoppelt wird.
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Freitag 2. November 2007, 17:13

Danke fuer die Tipps, BlackJack.

Es loggt bei Dir FLEISSIG vor sich hin? Heißt das, dass es ca 100 Zeilen loggt und dann nicht mehr (das ist das Problem) oder treibt es wirklich mit hoher Geschwindigkeit die log.txt in die MegaBytes?

Wie gesagt. In der Form, wie es da jetzt steht, hängt das GUI nicht mehr. Aber der Rechenthread hängt trotzdem nach sehr kurzer Zeit und nix wird mehr gelogged. Könntest Du das bei Dir nochmal angucken und mir das Verhalten beschreiben? Das wär lieb :-)

Den Styleguide werde ich mir zu Herzen nehmen. Hatte ich sogar schonmal gelesen. Ich hab bei dem Skript nur sehr viel rumgeschustert und hin und her gecopy/pasted und bei sowas mach ich das "schöne" immer erst hinterher. Ist blöd, ich weiß.

Zu den Globals: Die hätte ich auch gerne vermieden. Nur habe ich nach einer Möglichkeit gesucht, im Datei"kopf" einfach Werte / Parameter für das Skript einzustellen. Übersichtlich ganz oben in der Datei. Sowas wie define in php oder c++ gibts in python nicht oder? Wie kann man das in Python lösen ohne dafür extra eine Funktion zu schreiben?
BlackJack

Freitag 2. November 2007, 19:03

Es loggt wirklich fleissig Textzeilen. Ich habe sie mal nummerieren lassen: ``python test.py | nl`` und nach ca. 5 Sekunden war es bei Logzeile 67779.

Werte und Parameter über globale Namen ist kein Problem, die schreibt man in Grossbuchstaben, damit man erkennen kann, dass es sich um Konstanten handelt. Die Konvention gibt's ja in vielen Programmiersprachen. ``global`` braucht man nur, wenn man so einem Namen innerhalb einer Funktion einen neuen Wert zuweisen möchte. Also Konstanten ändern ─ das hört sich ja schon falsch an.
gurke111
User
Beiträge: 28
Registriert: Freitag 26. Oktober 2007, 22:55

Freitag 2. November 2007, 20:59

Okay.. ich räume den Quelltext jetzt ein bisschen auf. Hm... auf die Idee, dass ich ohne irgendein DEFINE oder so für Konstanten im Skript auskomme, bin ich nicht gekommen. ;)

Nebenbei..:
Warum geht

Code: Alles auswählen

def Point(self, x, y, dotsize=self.dotsize):
nicht? Es kommt "NameError: name 'self' is not defined". Kann man allgemein in einer Methode einer Klasse keine Standardparameter auf diese Weise festlegen?




Und..:
Woran kann es liegen, dass das Skript bei Dir ewig logged und bei mir der Rechenthread offenbar hängen bleibt? Ich hab den Python 2.5.1 Interpreter unter Windows laufen.

edit: OUAAAH:
Also. Bei mir läuft es jetzt auch. Meine Dateiendung des Skripts war .pyw . Ich weiß nicht genau, was das unter Windows dann bedeutet. Ich hatte es gemacht, weil dann das Konsole-Fenster nicht auftaucht. Mit .py und dem normalen Konsolefenster läuft alles glatt. Kann das jetzt jemand erklären? :)


edit2: Also:
Wenn ihr mal selbst Energieeigenwerte zur stationären Schrödingergleichung für das Potential V=|x| per Numerov - Iteration bestimmen wollt:
http://paste.pocoo.org/show/8714/
Jetzt läuft es :-) Die Grafikausgabe funktioniert auch nach meinen vorstellungen. Und das Ergebnis war sogar noch ein Stück genauer als das von Mathematica.. ich freu mich :)

Was kann ich an dem Skript noch verbessern? Bezogen auf Style / Aufbau und vielleicht auch Ausführungsgeschwindigkeit? Kommentieren werde ich noch vernünftig. Aber ich hätte gern noch ein bisschen Kritik..
BlackJack

Samstag 3. November 2007, 12:51

Die default-Werte werden ausgewertet wenn die ``def``-Anweisung ausgeführt wird und nicht beim Aufruf. Zu dem Zeitpunkt gibt es noch keine Instanz die an `self` gebunden ist. Üblicherweise benutzt man `None` und ein Überprüfung innerhalb der Funktion oder Methode:

Code: Alles auswählen

def point(self, x, y, dotsize=None):
    if dotsize is None:
        dotsize = self.dotsize
Mit `*.pyw` wird das Programm als "Windowsprogramm" gestartet d.h. da sind die Standardein und -ausgabe nicht mit einem Terminal verbunden das Ausgaben mit ``print`` entgegennimmt und darstellt. Wenn man etwas ausgibt blockiert das Programm solange bis die Daten abgenommen wurden. Ohne Terminal passiert das nie.

Zum Quelltext:

Die Einrückung ist jetzt wenigstens konsequent "falsch". ;-)

Ein paar Zeilen sind länger als 80 Zeichen.

Bitte nochmal die Wirkungsweise von ``global`` nachlesen. Auf Modulebene hat das absolut keinen Effekt. Wäre schön, wenn der Compiler da zumindest eine Warnung ausgeben würde. Und ``global`` ist auch immer noch "böse". In `NumerovUpdate()` ist das ``global`` überflüssig weil `PSI` nichts zugewiesen wird. Gleiches gilt für `window` in `NumerovInt()`.

Falls das Argument `logtime` bei `logit` als Schalter gedacht ist, wären `True` und `False` als mögliche Werte selbsterklärender.

Da Funktionen auch nur Objekte wie jedes andere sind, kann man `V` ganz einfach so definieren: ``V = abs``. Denn im Grunde ist `V` ja einfach nur die `abs`-Funktion unter einem anderen Namen.

Insgesamt würde ich immer noch Vorschlagen die globalen Namen loszuwerden bzw. nicht direkt darauf zuzugreifen, sondern sie den Funtkionen als Argumente mitzugeben. Und die Berechnung ist immer noch an die GUI gekoppelt.

Psyco bringt bei diesem Programm was. Ohne dauerte es bei mir ca. 5½ Minuten, mit nur 3½.
BlackJack

Samstag 3. November 2007, 18:06

Nachtrag: Ich habe `NumerovUpdate()` und was damit zusammenhängt mal zusammengefasst und etwas umgeschrieben:

Code: Alles auswählen

def f(a, n, E):
    return (H * H * (E - abs(n - a) * H)) / 6.0;


def NumerovUpdate(E):
  n = len(PSI)
  newPsi = ((2 * PSI[-1] * (1 - 5 * f(1.5, n, E))
             - PSI[-2] * (f(2.5, n, E) + 1))
            / (f(0.5, n, E) + 1))
  PSI.append(newPsi)
  return newPsi
`k()`, `x()` und `V()` sind ersatzlos gestrichen. Dann habe ich die GUI "ausgebaut" und zwei Testläufe gemacht. Ohne Psyco: 1 Minute und 6 Sekunden, mit Psyco nur 15 Sekunden Laufzeit.

Die GUI bremst das Program gewaltig aus, weil bei jedem neuen Punkt alle alten erneut gezeichnet werden. Vektorgrafik halt. Je mehr Punkte um so langsamer wird's.
Antworten