Probleme mit dem RMSD

[Pascal]

Da einige DF-Mitglieder über einen Fehler im aktuellen DF-Client berichtet haben, schlage ich vor, unsere Rechenpower von DF auf MD@home umzuschwenken.

Gelegentlich wird in entsprechenden Text-Dateien oder der aktuellen dfGUI über einen RMSD von 1000000000 o. ä. berichtet.

[Norman]

Hi !

Ja, einige und nicht alle Pascal ! Wenn du unbedingt bei den Russen rechnen willst, dann tuh das bitte und verunsichere jetzt nicht die anderen noch, bei denen DF gut und sauber läuft. Es sind halt nur wenige und deshalb zu MD zu wechseln halte ich für unangebracht !

Im DF-Forum ist das Problem schon durch die "obersten" aufgenommen worden und es wird an einem FIX fix gearbeitet. Das Problem taucht nur auf wenn das System crasht oder andere Prozesse sehr sehr viel RAM und CPU-Leistung verpulvern und nicht genug Ressourcen vorhanden sind, dann ist nämlich wie bei mir die filelist.txt im Ar... und durch die Checksum-Funktion nicht mehr manipulierbar und du musst die filelist.txt an trades@mshri.on.ca schicken und erhälts dann evtl. eine Antwort, aber nur wenn die Datei nicht komplett zerstört ist !

Also jeder der CPU- oder RAM-lastiges Zeug startet sollte ein Auge auf den Client werfen und/oder die filelist.txt öfters mal irgendwo sichern!

Bleibt also ruhig bei DF und uploaded immer, dann kann euch kaum was verloren gehen !



so long...

[Michael H.W. Weber]

Das Problem taucht nur auf wenn das System crasht oder andere Prozesse sehr sehr viel RAM und CPU-Leistung verpulvern und nicht genug Ressourcen vorhanden sind

Das muß ich kurz dementieren. Die "quasi-unendlichen" RMSD-Werte treten bei mir z.B. völlig "crash"-unabhängig und auch ohne RAM-Belastung auf und ich nehme hier einen "bug" im Client an.

Was mich viel mehr interessiert: Bitte achtet mal auf das Verhältnis von RMSD und "laxness level". Mein Eindruck ist, daß der RMSD bis zu einem gewissen Grad sinkt, dann fängt der Client massiv an zu "stottern", es folgt ein Ansteigen des RMSDs. Daraufhin erhöht der Client den "laxness level" - erlaubt also eigentlich physikalisch illegale Atompositionierungen. Daraufhin sinkt der RMSD. Aber er scheint zu schwingen: Hoher "laxness level", niedriger RMSD und umgekehrt. Was aber ist der Trend der Gesamtkurven über einen langen Zeitraum? Und wie hoch ist der "laxness level am Ende"? Ihr braucht dfGUI, um das beobachten zu können.

Michael.

[Norman]

Hi Michael!

Das würde ja heißen, daß sehr viele Resultate die zurückgeliefert werden fakto FALSCH sind und ich glaube nicht, daß nach so langer Testzeit der Client sch... ist und die testenden Wissenschaftler solche Mankos nicht bemerkt haben.

Der Client hat doch ziemlich viel Beta-Zeit hinter sich und da ändert die GUI auch nix daran. Sie visualisiert dies zwar, aber die Herren Profs brauchen diese ja nicht, um festzustellen ob die Ergebnisse richtig sind.

Ich nehme nicht an, daß es ein Bug ist, sondern eher ein kosmetisches Problem der GUI ! Der Client läuft wirklich ein wenig instabiler als der vorherige, da muß ich dir Recht geben, aber falsche Resultate würde ich ihm jetzt noch nicht unterstellen wollen !



so long...

[Mercutio]

Hiho,

also ich denke das Platz 9 nicht das Maß aller Dinge ist. Wir sollten den 3ten Platz anstreben. Sollten allerdings jetzt mehr Leute abspringen, und so sieht es zur Zeit aus, dann werde ich auch wieder Seti rechnen.

carpe diem
Mercutio

PS: Nichts ist so wie es scheint

[Michael H.W. Weber]

Das würde ja heißen, daß sehr viele Resultate die zurückgeliefert werden fakto FALSCH sind und ich glaube nicht, daß nach so langer Testzeit der Client sch... ist und die testenden Wissenschaftler solche Mankos nicht bemerkt haben.

Der Client hat doch ziemlich viel Beta-Zeit hinter sich und da ändert die GUI auch nix daran. Sie visualisiert dies zwar, aber die Herren Profs brauchen diese ja nicht, um festzustellen ob die Ergebnisse richtig sind.

Ich nehme nicht an, daß es ein Bug ist, sondern eher ein kosmetisches Problem der GUI ! Der Client läuft wirklich ein wenig instabiler als der vorherige, da muß ich dir Recht geben, aber falsche Resultate würde ich ihm jetzt noch nicht unterstellen wollen!

Ich bin auch (noch) nicht dazu übergegangen, dem Client falsche Resultate zu unterstellen - bitte beachten! Ich darf darauf hinweisen, daß die GUI während der Betaphase in dieser Form NICHT zur Verfügung stand und also auch keine Vergleiche der EINZELGENERATIONEN möglich waren - bedenke, daß der Client stets nur die beste Struktur eines jeden Sets hochlädt. Ich hoffe natürlich auch darauf, daß Howard seine Hausaufgaben gemacht hat. Weiß aber aus eigener Erfahrung, daß auch Wissenschaftler gegen Fehler alles andere als gefeit sind. Genauso kannst Du natürlich Recht haben, daß es sich um einen Fehler in der GUI handelt - ausschließen kann ich das nicht.
Allerdings habe ich inzwischen ein paar andere Rechner angesehen und hier zeigt sich ein kontinuierlicher Trend hin zu niedrigerem RMSD. Das bestätigt meine Annahme, daß man pauschal hier nicht argumentieren kann. Daher hatte ich ja auch um Beobachtung gebeten.

Sollten allerdings jetzt mehr Leute abspringen, und so sieht es zur Zeit aus, dann werde ich auch wieder Seti rechnen.

Falls es dazu kommt, könntest Du uns nicht mal bei MDH unterstützen statt SETI zu rechnen? Dort haben wir echte Chancen und es ist auch ein gutes Projekt.

Michael.

[trickfinger]

@Mercutio
Etwas mehr als der 9. Platz sollte längerfristig drin sein. Ich denke, gerade jetzt am Anfang der II. Phase hängen sich alle richtig rein. Ob es aber bis zu den Top3 langt?
Ich werde DF auf alle Fälle treu bleiben

[Pascal]

Klick

Hier sieht man den Verlauf des besten RMSD über die gesamten gerechneten Generationen. In der letzten Betaversion gab es wohl noch dieses Problem, dass der RMSD in späteren Generationen nicht mehr kleiner wird. Dies müssten wir aber mal intensiv beobachten, das geht nur mit der dfGUI.

[Arnim Weber]

Eine neue Version der DF-GUI ist ja nun auch erhältlich, sodass man das evt. jetzt ja beobachten kann....
Ich bleib jeden falls auch erst mal bei DF.

[Wurmi]

Ich glaube, das Verhalten ist o.k.: den hohen RMSD halte ich für einen schlichten Defaultwert, den die einzelnen Individuen anfangs zugeordnet bekommen. Es kann Sinn machen, einen "richtigen" Wert erst dann einzutragen, wenn man ein gewisser Schwellwert unterschritten wurde. Alles darüber ist "einfach schlecht".

Ebenso ist es o.k., daß der RMSD wieder anwächst. Das passiert genau dann, wenn man ein lokales Minimum hinreichend ausgekundschaftet hat. Danach muß man versuchen, durch Erhöhung der Mutationsrate eine andere Senke zu finden. Immerhin geht es hier um die Suche eines globalen Minimums in einem Problemraum mit hunderten von Dimensionen.

Mendelsche Grüße, Wurmi .

[Michael H.W. Weber]

Ich glaube, das Verhalten ist o.k.: den hohen RMSD halte ich für einen schlichten Defaultwert, den die einzelnen Individuen anfangs zugeordnet bekommen.

Ich habe mir das jetzt ein paar Tage genauer angesehen und es scheint tatsächlich so zu sein, daß dieser hohe Wert zu Beginn einer neuen Generation als Voreinstellung eingesetzt wird. Ich denke daher, daß dies evt. auch mit dfGUI zusammenhängt (was soll das Programm auch anzeigen, wenn die erste Struktur noch nicht berechnet wurde?)

Ebenso ist es o.k., daß der RMSD wieder anwächst. Das passiert genau dann, wenn man ein lokales Minimum hinreichend ausgekundschaftet hat. Danach muß man versuchen, durch Erhöhung der Mutationsrate eine andere Senke zu finden. Immerhin geht es hier um die Suche eines globalen Minimums in einem Problemraum mit hunderten von Dimensionen.

Das ist richtig, was mich jedoch irritiert ist, daß innerhalb einer 250-Generationenserie über die Zeit der RMSD alles andere als sinkt. Zu Anfang geht er runter, dann wird ein Minimum erreicht (und zwar recht früh - etwa um die 60. Generation) und ab da steigt der RMSD bei mir nur noch an. Es kann allerdings sein, daß nach Erreichen des besten RMSD-Wertes die restliche Zeit damit verbracht wird, den zu diesem Zeitpunkt vorliegenden "laxness level" herunterzudrücken. Ich gehe inzwischen auch davon aus, daß genau das die Idee bei der Sache ist. Und das wäre dann okay. Allerdings habe ich nur zwei Rechner hier, wo ich mir das ansehen kann und daher mit Sicherheit keinen statistisch relevanten Überblick. Und jetzt ist der eine Client wegen eines neuen Fehler gar nicht mehr zu reaktivieren ohne Neuinstallation:

Code: Alles auswählen

========================[ Jun 22, 2003  1:27 PM ]========================
ERROR: [000.000] {foldtrajlite2.c, line 3951} Cannot find structure from previous generation .\7vp7eh5y_0_7vp7eh5y_protein_95_0000036_min.val; find it manually or delete filelist.txt to continue
ERROR: [000.000] {foldtrajlite2.c, line 4127} Error during upload: Previous generation missing
ERROR: [001.001] {trajtools.c, line 3480} Unable to open trajectory distribution file 7vp7eh5y_protein_97.trj
FATAL ERROR: [002.003] {foldtrajlite2.c, line 4700} Unable to read trajectory distribution, please create a new one

Nein, meine Maschine hat dies NICHT durch Crash oder Stromausfall verursacht...

Michael.