Was ist los mit euch?

[Necci]

Könnt ihr nicht, oder wollt ihr nicht rechnen?

[ltd]

Ich für meinen Teil werde erst dann wieder für dieses Projekt rechnen wenn das ganze nicht mehr nur Beschäftigungsterapie mit bereits mehrfach berechneten Ergebnissen ist. ( Siehe Statistik Snapshot )

Wir rechnen dort doch im moment nur redundante Ergebnisse.


Lars

[Necci]

Schon mal daran gedacht, dass sich die Zeit so nur verlängert, bis wir neue WUs berechnen dürfen.

Also hopphopp... crunchen.

[ltd]

@Necci,

seh ich nicht so, da wir ja schon jenseits der geplanten Redundanz von 3 sind. Damit wird es dann eben doch Beschäftigungsterapie.

Ich habe es dann aufgegeben alle paar Wochen entweder selber zu fragen wann denn nun neue WU herausgegeben werden oder aber zu lesen das in den nächsten Tagen neue WU kommen werden, die sich dann aber doch noch um teilweise Wochen verzögern.

Lars

[Bananeweizen]

Ich kann ltd nur zustimmen. Wenn die Jungs dort nicht aus dem Knick kommen und nahezu Null Reaktion auf Anfragen der Teams zeigen, dann gibt es eben genügend andere Projekte, die den Rechner ebenfalls ordentlich beschäftigen.

Bei DF zum Beispiel reagiert der Projektbetreiber im Normalfall innerhalb von wenigen Stunden auf Anfragen in den Foren (und zwar auf jede Anfrage!). Dort wurden z.B. schon einige Features auf Anregung der User in den Client eingebaut und auch die Erläuterungen dazu, warum sich am Ablauf irgendwelche Dinge ändern, kommen viel besser (weil sehr ausführlich) bei den Usern an.

Bei TSC hingegen sehe ich seit Monaten keine wirklichen Änderungen (nocht mal vernünftige Statusreports). Und das ruft bei mir immer das Gefühl hervor, derjenige Betreiber nimmt sein Projekt selbst nicht so ganz ernst. Warum sollte ich das dann also tun.

Ciao, Michael.

[DersaureFritz]

Bei TSC hingegen sehe ich seit Monaten keine wirklichen Änderungen (nocht mal vernünftige Statusreports). Und das ruft bei mir immer das Gefühl hervor, derjenige Betreiber nimmt sein Projekt selbst nicht so ganz ernst. Warum sollte ich das dann also tun.

Ciao, Michael.

Hi Bananewizen,

Du hast den Nagel auf den Kopf getroffen.

Die Jungs bei Rothberg kommen einfach nicht in die Gänge!

Und alle 7 Tage ist der Server down.

Alles sehr stümperhaft dort aufgezogen!

[Michael H.W. Weber]

Die Jungs bei Rothberg kommen einfach nicht in die Gänge! Und alle 7 Tage ist der Server down. Alles sehr stümperhaft dort aufgezogen!

Ihr müßt den Leuten das da mal in prägnanter Form sagen, damit die das ändern. Das war doch mal ein gutes Projekt!

Michael.

[dismit]

Das Argument mit der Redundanz bei Community TSC (oder D2OL) verstehe ich nicht. Beim virtuellen Screening von Substanzen geht es doch darum möglichst realistische Konfigurationen zu finden, also solche die auch die Praxiswerte annähernd erreichen.

Un da erscheint es mir nicht sonderlich redundant zu sein, wenn man den Test für eine Substanz auf 3-5? Tasks verteilt und jedem Task 20 Konformationen zu je 750.000 Konfigurationen zuordnet. Die Zielmoleküle an die die Substanzen andocken sollen, sind ja auch nicht gerade klein!

Das sind also 45-75 Mio Tests pro Substanz.

Das ist nichts im Vergleich zu Distributed Folding, wo für eine Protein 10 Milliarden möglicher Strukturen erzeugt werden, um der Realität einigermassen nahezukommen.

Redundanz wäre etwas vollkommen anderes. Redundanz läge vor, wenn man zusätzlich Berechnungen nur deshalb durchführt um die Richtigkeit älterer Berechnungen zu prüfen. Aber dazu ist weder der Client bei D2OL/TSC noch der Client bei DF in der Lage.

Wünschenswert wäre natürlich, wenn der Client für die Testsubstanz den besten bisher gefundenen Werte für die Energie und die Andockzeit (oder deren Standardverteilungen) als Infos mitliefern würde.

Ich kann mir durchaus vorstellen, dass man die Größenordnung des Screenings davon abhängig macht, wieviele SIGMAS der beste und der schlechteste Wert vom häufigsten Wert abweicht.

Je größer die Abweichung bei den bekannten Ergebnissen ist, desto besser sollte man natürlich die Substanz testen, weil in solchen Fällen die Chance für eine Verbesserung am höchsten ist.

Wünschenswert wäre aber, wenn man direkt mit den Entwicklern Kontakt hätte und nicht immer Ken Weilbacher plagen müsste (der sicherlich auf noch eine Menge anderer Aufgaben hat) und der dann wiederum jemanden kontaktieren muss .... das ist nicht so gut gelöst

Auf der anderen Seite hat man sich mit dem Client viel mehr Mühe gegeben als z.B. dies z.B. bei ZetaGrid der Fall ist (nicht vergleichbar, ich weiss).

Man braucht für die Steuerung der Priorität gar keinen Taskmanager wie ATM dazu sondern kann die Priorität des Java-Clients über die Initialisierungsdatei LAUNCH.XEN des Launchers D2OL.EXE festlegen. Mit IDLE statt NORMAL hatte ich keine Probleme mit schwerfällig reagierenden Systemen mehr.

So weit ich das ganze Prozedere mit den Tests bei TSC und D2OL verstanden habe, hat man mit gar nicht so wenigen Substanzen in der NCI_Database Probleme mit der Codierung. Diese Substanzen werden anscheinend erneut zum Testen freigegeben, nachdem man die Codierung verbessert hat.

Ich denke, dass diejenigen, die an TSC leiden, wegen der Seltenheit des Auftretens dieser Krankheit noch lange nicht damit rechnen können, dass sich grosse Pharmafirmen ihrer annehmen. Damit ist ganz einfach kein Geld zu machen.

Deswegen werde ich den TSC-Client auch weiterhin mit 50% auf IDLE laufen lassen (wenn nicht gerade ein Einsatz für die Taskforce läuft, denn zwei Java-Clients vertragen sich nicht miteinander). Die anderen 50% IDLE-Takte gehören weiterhin Prime95

Dieter

[ltd]

Bei TSC geht es um etwas ganz anderes als zum Beispiel bei DF.

Bei TSC wird versucht Moleküle zu finden die sich an aktive Positionen eines Proteins anfügen lassen. ( so habe ich als Laie das mal verstanden)
Moleküle die diese Bedingung erfüllen sind potentiell als Medikament einsetzbar, da sie eine Reaktion im Protein hervorrufen. ( Dieses zum Beispiel inaktiv machen).

Bei TSC ist die Redundanz hauptsächlich dazu notwendig um die in der Realität nicht ideal arbeitenden Computer zu prüfen. (Zwei Rechner erzeugen bei den Angewanten Verfahren keine identischen Ergebnisse). Des weiteren werden die Startbedingungen durch eine Zufallszahl noch geringfügig verändert. Das heist hier geht es tatsächlich darum Rechnungen mehrfach durchzuführen nur um die Korrektheit zu prüfen.

Bei DF wiederum wird die zufällige Faltung eines Proteins durchgeführt. Und man hofft das man bei einer ausreichend grossen Stichprobe, eine möglichst reale Faltung findet.

Lars

P.S. Sollte ich die Vorgehensweise der beiden Projekte total falsch verstanden haben, nicht hauen sondern belehrt mich.

[Zeuge]

Könnt ihr nicht, oder wollt ihr nicht rechnen?

Ich werde nach dem TF Einsatz wieder etwas für TSC tun.
Allerdings erwarte ich von den Projektbetreibern deutlich mehr Feedback als es bislang der Fall ist.
Wie BW und andere schon schrieben: Nur wenn die Betreiber die Sache entsprechend Ernst nehmen, kann man dies auch von den Crunchern erwarten!

[Michael H.W. Weber]

Bei TSC geht es um etwas ganz anderes als zum Beispiel bei DF.

Korrekt. DF = Proteinstrukturvorhersage, TSC = Finden von Substanzen, die an die TSC-relevanten Proteine andocken können.

Bei TSC wird versucht Moleküle zu finden die sich an aktive Positionen eines Proteins anfügen lassen. ( so habe ich als Laie das mal verstanden)
Moleküle die diese Bedingung erfüllen sind potentiell als Medikament einsetzbar, da sie eine Reaktion im Protein hervorrufen. ( Dieses zum Beispiel inaktiv machen).

Wie kann man sich das in der Zelle vorstellen? Dort schwimmen die TSC-Targetproteine in wässriger Lösung herum (neben vielen, vielen anderen Molekülen). Man gibt das "Medikament" hinzu. Gelegentlich begegnen sich nun Target und Medikament (abhängig von der Menge beider Stoffe in der Zelle: je höher die Konzentration, desto höher deren "Stoßfrequenz" - ja, das ist ein Fachbegriff, hehehehe). Jedes Molekül mit Oberflächenladungen erzeugt ein elektrisches Feld in seiner Umgebung. Wenn das Medikament in dessen "Einzugsbereich" kommt, wird es interagieren und sozusagen an die Stelle gezogen, wo es binden soll. Wenn es dort bindet, verändert es dadurch die Gestalt (=Konformation) des Proteins und damit dessen Funktionstüchtigkeit. Wie sich das auswirkt, muß letztendlich das Laborexperiment zeigen, auch wenn man auf Basis von anderem Wissen Vorhersagen machen kann.

Bei TSC ist die Redundanz hauptsächlich dazu notwendig um die in der Realität nicht ideal arbeitenden Computer zu prüfen. (Zwei Rechner erzeugen bei den Angewanten Verfahren keine identischen Ergebnisse).

Ist das wirklich so? Ich kann mir nur schwer vorstellen, daß in diesen Rechnungen auf Basis derselben Startbedingungen auf zwei verschiedenen Computern unterschiedliche Ergebnisse herauskommen. Das würde mein Vertrauen in Computer doch arg schmälern. Da wäre ich mal für ein wenig Aufklärung dankbar.

Des weiteren werden die Startbedingungen durch eine Zufallszahl noch geringfügig verändert.

Das wirkt sich aber so aus, daß eine andere Gruppe von Konformationen der potentiellen "Medikamente" durchgetestet wird. Das kann man in keinem Fall als redundant bezeichnen. Im Gegenteil. Bloß weil ich dasselbe Molekül zweimal teste, mache ich nicht dasselbe, wenn ich dabei jeweils einen anderen Kornformatinsraum absuche. Ich glaube das muß man ganz scharf unterscheiden!

Das heist hier geht es tatsächlich darum Rechnungen mehrfach durchzuführen nur um die Korrektheit zu prüfen.

Das eben bezweifele ich, sofern Du nicht mit dem oben gesagten Recht hast. Ich glaube, die Rechnungen sind nicht identisch. Vielleicht gibt die Website da ja ein paar Details her?

Bei DF ... man hofft das man bei einer ausreichend grossen Stichprobe, eine möglichst reale Faltung findet.

Korrekt.

Michael.

[dismit]

Ltd schrieb:

Bei TSC ist die Redundanz hauptsächlich dazu notwendig um die in der Realität nicht ideal arbeitenden Computer zu prüfen. (Zwei Rechner erzeugen bei den Angewanten Verfahren keine identischen Ergebnisse). Des weiteren werden die Startbedingungen durch eine Zufallszahl noch geringfügig verändert. Das heist hier geht es tatsächlich darum Rechnungen mehrfach durchzuführen nur um die Korrektheit zu prüfen.

Ich glaube nicht, dass das so stimmt. Meines Wissens sind die Ergebnisse unterschiedlich, weil die Startparameter in einem bestimmten Wertebereich zufällig variiert werden. Das hat nichts damit zu tun, dass Computer nicht ideal arbeiten, z.B. wegen der Rundungsfehler, denn die sind ja auf allen Rechnern, die mit einfacher oder doppelter Genauigkeit rechnen, diesselben.

Sowohl das Zielprotein als auch die Testsubstanz können ja nicht mit unendlicher Genauigkeit codiert werden. Deswegen rechnet man auf einem Gitter mit einer endlichen Zahl von Elementen. Die beste Anpassung in diesem Gitter zu finden, darin besteht nach meiner Meinung die Kunst

Gerade weil die Ergebnisse nicht identisch sind, besteht die Chance auf eine Veränderung in die gewünschte Richtung und daher ist es keine Redundanz, weil der Client die Korrektheit älterer Ergebnisse nicht bestätigen kann.

Das wäre ja auch ziemlich unnötig, denn einen Ausreisser wegen Manipulation würde man bei der Berechnung der Standardabweichung ohnehin erkennen, z.B. eine Normalverteilung mit einem Ausreisser bei 10 Sigmas .....

Redundanz würde voraussetzen, dass die Zufallszahlen nicht vom Client sondern vom Server vor dem Download an den Client generiert werden und zwar gleiche Zufallszahlen für jeden Client. Mit der Folge, dass keine besseren Ergebnisse gefunden würden, weil die Ergebnisse redundant wären, d.h. mit früheren Berechnungen übereinstimmen würden .... Redundanz macht hier einfach keinen Sinn! (Bei DF genauso wenig)




Nachtrag:

Es sind mehrere Gitter und nicht nur eines (3 bis 7 Gitter).