Howard Feldman meinte zu meiner Mail: das Autoupdate funktioniert nicht. Man muß manuell aktualisieren.
Ich habe ihm wegen der liegenbleibenden Daten auch schon Bescheid gegeben und ihm mitgeteilt, daß ihm bei derlei Aktionen auf Dauer die Teilnehmer davonlaufen.
Ich kenne auch keinen, bei dem das Aktualisieren funktioniert hätte.
Seit gestern macht der Server Streß: der Client meldet, er hätte Netzwerk-Probleme entdeckt und könne nicht senden. Die Stats sind aber korrekt angestiegen. Startet man dann neu, lädt er brav hoch (oder rechnet einfach weiter). Schaut man dann in den Statistiken nach, sind die Credits um exakt denselben Betrag angestiegen, den man im vorherigen Durchgang (offenbar doch) abgeliefert hat. Danach rechnet das Ding dann wie üblich weiter. Ich hatte ein Backup von diesem Verzeichnis gemacht und wollte dem mal nachgehen. Kopiert man dieses Backup über das Arbeitsverzeichnis, wiederholt sich das Ganze, d.h. die Credits steigen um denselben Betrag an (die Fehlermeldungen sind auch die gleichen). Das hat mich neugierig gemacht, da der Verdacht nahelag, daß der Server nicht unterscheiden kann, ob er ständig dieselben Ergebnisse zugeschickt bekommt. In der Tat würde dies auch mit dem Konzept des Projekts übereinstimmen, denn es wird ja ausdrücklich gesagt, daß NUR DIE STRUKTUR MIT DEM BESTEN RMSD GESPEICHERT wird. Außerdem wird die Berechnung auf Zufallsbasis gestartet, d.h. es ist nicht nachvollziehbar, ob die Ergebnisse zufällig dieselben sind oder ob jemand doppelt schickt. Und tatsächlich:
auch wenn der Client korrekt durchgelaufen ist, kann man mit einem Backup stets redundante Ergebnisse senden und damit die Statistiken manipulieren.
Das Ganze hat einen entscheidenden Haken und hier sieht man auch mal wieder den Unterschied zu FAH/GAH, wo soetwas nicht geht (ich habe das Problem übrigens vor langer Zeit auch bei FAH1 entdeckt, nachdem sich mein Client in einer interessanten Endlosschleife befand, und Vijay in einer privaten Mail gemeldet, woraufhin er das Problem dann schnellstens behoben hat). Howard Feldman geht nämlich davon aus, daß nach Berechnung von 1 GigaStruktur STATISTISCH GESEHEN keine weitere Verbesserung des RMSD zu erwarten ist, da RECHNERISCH der Konformationsraum ausreichend ausgeschöpft worden sein sollte. Das setzt aber voraus, daß auch alle geschickten Strukturen von seriösen Rechnungen ausgehen. Wie nun, wenn die Leute die Stats manipulieren? Dann zieht die gesamte Überlegung nicht und das Projekt verliert dann seine Ausssagekraft. Man will hinterher ja auch etwas veröffentlichen in der Form: "mit diesem Denkansatz haben wir nach Berechnen von 1 GigaStruktur einen RMSD von ... erzielt." - Tja, die Zahl der Strukturen stimmt aber schon nicht. Damit werden weitere Abschätzungen irrelevant und die angegebenen Daten inkorrekt. Das einzig Schöne daran ist, daß der Algorithmus unter diesen Überlegungen eher besser ist, als er eingeschätzt wird. Und acuh: der RMSD ist es, worauf es ankommt, d.h. die Rechenergebnisse als solche werden natürlich NICHT beeinflußt - es geht NUR um die Stats.
Ich kann jetzt nur noch dazu aufrufen, dies nicht auszunutzen.
Das eigentliche Rennen findet also um den niedrigsten RMSD statt, denn der ändert sich nur, wenn auch seriöse Rechenergebnisse abgeliefert werden.
Fazit: Statistiken haben bei DF überhaupt keine Bedeutung & Aussagekraft.
Noch eins zum Thema schnelleres Rechnen mit dem neuen Client: das Protein ist einfach kleiner (36 Aminosäuren statt 56). Der Algorithmus aber gleichschnell.
Michael.
