Rechenkraft.net e.V.

Norman hat geschrieben:gibt es noch das team "gütesiegel" ?

Ja, das gibt es noch.

Norman hat geschrieben:auch könnte irgendwie mal realisiert werden, dass alle user bewertungen abgeben können zu den einzelnen kategorien

Ist doch schon längst geschehen. Die letzten beiden Gütesiegel wurden auf Grund dieser neuen Methode und mittels der von hias geschriebenen Weboberfläche getätigt. Mir fehlt leider gerade die Zeit, die entsprechenden Forenbeiträge zu suchen.

Viele Grüße,
Torbjörn

siehe hier: http://siegel.rechenkraft.net/

Steht aber auch auf der RKN Startseite

Ich hab versucht, die Roadmap mal auf den aktuellen Stand zu bringen, also in erster Linie Erledigtes zu entfernen.

Hier nun ein paar Gedanken, in die u.a. Ergebnisse und Gespräche des IDGF und BOINC Workshops eingeflossen sind. Dennis, hast du Zeit und Lust die oben einzuarbeiten? Natürlich kann auch jeder andere sie einarbeiten, indem er im Wiki diese Seite hier füllt: Verein:Rechenkraft.net_e.V./Roadmap

• Ältere Gütesiegel sollten erneuert werden. (z.B. WCG) (@hias: bitte sprich mit nico/LF ab, wie deine Gütesiegelskripte wieder aktiviert werden können)
• Die elektronische Bibliothek sollte vollständig als BibTeX oder RIS erfasst werden (z.B. mit FireFox-Plugin Zotero) und mit der von David Anderson (http://boinc.berkeley.edu/wiki/Publicat ... C_projects) zusammengelegt werden. Einige Publikationen habe ich bereits in meinem Zotero drin. Bitte mich anschreiben.

Soviel von mir erst einmal.

Grüße,
Torbjörn

Aus https://www.rechenkraft.net/phpBB/viewt ... 75&t=12107

Michael H.W. Weber hat geschrieben:Since we are planning to discontinue the indeed *insanely long WUs* as soon as the current batches are done, we are not planning to introduce another run time selection mechanism.

Wie weit sollen die langen WUs denn zurück geschnitten werden? Gibt es eine alternative Bearbeitungsmöglichkeit oder lassen wir die größen Genome bis auf weiteres ganz raus?

mxplm hat geschrieben:Wie weit sollen die langen WUs denn zurück geschnitten werden? Gibt es eine alternative Bearbeitungsmöglichkeit oder lassen wir die größen Genome bis auf weiteres ganz raus?

Im Gegentail, wir werden sogar noch größere Genome untersuchen. Basis hierfür ist ein von uns entwickelter Ansatz zur Aufspaltung der Arbeitseinheiten in kleinere Fragmente. Wir können im damit im Prinzip die Laufzeiten aller WUs so weit runterschrauben, wie wir wollen, werden dies in der Praxis aber nur auf wirklich große Genome anwenden, da alles andere eigentlich sehr zufriedenstellend läuft.

Michael.

Michael H.W. Weber hat geschrieben:... kleinere Fragmente. Wir können im damit im Prinzip die Laufzeiten aller WUs so weit runterschrauben, wie wir wollen, werden dies in der Praxis aber nur auf wirklich große Genome anwenden, da alles andere eigentlich sehr zufriedenstellend läuft. ...

Vielleicht als Erklaerung, warum es nicht sinnvoll ist, zu klein zu stueckeln, das ist naemlich keine Willkuer sondern hat ganz praktische Gruende :

Beim Zerstueckeln ist jeder Schnitt mit etwas Redundanz verbunden, je kleiner die Stuecke werden um so mehr Redundanz handelt man sich ein (anteilig an der Gesamtberechnung).

Der Grund dafuer liegt darin, dass man an der Schnittstelle immer in beide Richtungen sozusagen "Reserve zugeben" muss, weil man sonst Treffer, die genau auf dem Schnitt liegen, nicht erfassen wuerde. Mit den Ueberlappungen erreicht man, dass jeder Treffer immer vollstaendig innerhalb eines Pakets liegt, sie verlaengern aber die Rechenzeit (in Summe) der Teilstuecke gegenueber der Abhandlung der kompletten Sequenz am Stueck.

Ah, ok, dann hatte ich den Kommentar falsch gedeutet.
Die Idee gab's es ja schon vor längerer Zeit. Wisst ihr mittlerweile, wie groß die Redundanz sein muss, damit die Qualität der Ergebnisse dieselbe ist? Also, wie viele Basen um die Schittstelle herum muss man in zwei WUs stecken, damit das Matching gegen die RNA die gleichen Werte hat wie bei einer einzigen WU?

...soviel, dass jeder RNA Kandidat, der am Ende eines Fragments liegt, nicht abgeschnitten wird. Also mindestens muß der Überlappungsbereich die Länge der längsten zu findenden RNA haben - besser das Doppelte.

Michael.

Unsere Defaulteinstellung ist im Split-Programm verdrahtet : ChunkSize=100000, Overlap=1000

Das passte fuer unsere Tests ganz gut, beide Werte koennen aber ueber Parameter angepasst werden, falls sich herausstellt, dass sie nicht reichen.

Das Combine-Programm (Zusammenfummeln der Teilstuecke) bekommt die Information ueber eine Modifikation des FASTA-Kommentares mit, man muss also nur das Splitprogramm parametrieren.

Beide Programme sind uebrigens Kurzlaeufer, durch den Mechanismus selbst verlieren wir also nicht noch zusaetzlich Zeit und auch wenn es auf dem Server gemacht wird, duerfte sich dort die CPU-Belastung in engen Grenzen halten. Was natuerlich etwas hochgeht ist die I/O-Last, da die dicken FASTA-Dateien ja gelesen und die Teilstuecke geschrieben werden muessen.

Die DB muss auch noch ein paar mehr WUs und Results halten und indexieren. Das sollte aber kaum spürbar sein, wenn nur die großen WUs geteilt werden.

Reden wir bei "ChunkSize=100000, Overlap=1000" von der Anzahl der Zeichen in der FASTA (=Basenpaare)? Das würde bei den großen WUs wirklich viele Segemente ergeben. Außerdem hätte ich - ohne wirklich Ahnung zu haben - geschätzt, dass RNAs auch mehr als 1000 Basen umfassen können.

Zeichen in der Kette, ja. Ich habe die Tests oft mit 1.000.000 gemacht, das ist auch noch gut zu handhaben - beim Entwurf stand aber auch noch die Idee dahinter, so durch die Hintertuer an Checkpoints zu kommen. Der Verlust durch die Ueberlappung erreicht bei dicken Results bei weitem nicht den Verlust durch den Schaden, den die Heartbeats anrichten.

Was die Trefferlaenge angeht : dazu kann ich ueberhaupt nichts sagen, da muessen wir auf Michael warten.