UserJobSubmission Workflow

[ChristianB]

Ausgehend von der Diskussion um die Grenzwerte für die einzelnen cmsearch Pipelines wurde eine Diskussion zum UserJobSubmission und dem damit verbundenen Workflow angestoßen. Diese soll hier stattfinden.

Zum Überblick der jetzige Workflow:

• Der Nutzer (Wissenschaftler) erstellt ein ZIP-Archiv (*.cm Dateien und *.fasta Dateien sowei eine optionale para.txt welche die Kommandozeilenparameter für einzelne oder alle cm/fasta Kombinationen enthält)
• Das Archiv wird per FTP in das Inputverzeichnis des Nutzers auf den RNA Server kopiert
• (Job-Forecaster): Der Server überprüft alle 10min ob ein neues Archiv hochgeladen wurde und erstellt für jede cm/fasta Kombination innerhalb des Archivs einen forecast (unter Beachtung der para.txt)
• (Job-Generator): Der Server prüft alle 10min ob neue BOINC-Jobs erzeugt werden müssen, wenn ja dann prüft er ob ein neues Archiv hochgeladen wurde und dafür schon der komplette forecast erzeugt wurde, wenn ja dann werden für alle cm/fasta Kombinationen innerhalb des Archivs BOINC-Jobs erzeugt. Dabei werden die Grenzwerte zur Bündelung, wie bereits diskutiert, berücksichtigt.

Der Job-Forecaster und Job-Generator sind bereits fertige Skripts, auf dem Server, die das Format des Archivs kennen und auch das Format der erstellten forecast kennen. Der Job-Forecaster kann dabei auch auf einem anderen Rechner als dem Server laufen so lange die forecast-Datei mit dem Archiv zusammen hochgeladen wird.

Wie man leicht sieht ist das Erstellen des Archivs und das Hochladen per FTP der bisher nicht automatisierte Teil dieses Workflows. Wenn wir also das UserJobSubmission Web-Interface so gestalten, dass wir dabei ein ZIP-Archiv im richtigen Format erzeugen, müssen wir den restlichen Workflow nicht ändern und können sogar den bisherigen Teil (per FTP hochgeladenes Archiv) beibehalten.

Das Web-Interface was wir in Berlin entwickelt hatten erlaubt nur das hochladen einer .cm und einer .fasta Datei. Das ist zwar akzeptabel aber würde nicht den Workflow wie oben beschrieben unterstützen. Wir müssen also in dem neuen Interface die (weitere) Möglichkeit schaffen mehrere *.cm und mehrere *.fasta Dateien hochzuladen die dann überprüft und in ein Archiv gepackt werden.

Was wir also bräuchten ist ein Web-Interface was eine oder mehrere *.cm und *.fasta Dateien akzeptiert sowie die Eingabe (Auswahl?) der Parameter für diese Batch ermöglicht. Die Überprüfung der cm und fasta Dateien kann entweder beim hochladen oder in einem Zwischenschritt erfolgen je nachdem wie das Interface implementiert wird. Eventuell könnte man dem User eine Staging Area (oder Sandbox) anbieten wo er cm und fasta Dateien hochladen kann (per WebInterface), die Dateien validiert werden und erst dann die Batch erzeugt wird (also die ZIP-Datei welche dann an den Job-forecaster übergeben wird).

Der neue Workflow könnte also wie folgt aussehen:

• Der Nutzer lädt seine *.cm und *.fasta Dateien per WebInterface auf den Server
• (RNA-Validierer): Der Server prüft nach dem hochladen einer *.cm oder *.fasta Datei in die Sandbox eines Nutzers die Datei. Ist alles ok wird die Datei akzeptiert, stimmt etwas nicht bekommt der Nutzer eine Nachricht (entweder Mail, PM oder Text im Browser je nach Implementierung)
• Der Nutzer hat alle Dateien hochgeladen und alle Parameter eingegeben, er gibt jetzt die Batch in Auftrag (dabei wird ein ZIP-Archiv erzeugt und vom Server in das input-Verzeichnis des Nutzers gelegt)
• (Job-Forecaster): Der Server überprüft alle 10min ob ein neues Archiv im input Verzeichnis der Nutzer erzeugt wurde und erstellt für jede cm/fasta Kombination innerhalb des Archivs einen forecast (unter Beachtung der para.txt)
• (Job-Generator): Der Server prüft alle 10min ob neue BOINC-Jobs erzeugt werden müssen, wenn ja dann prüft er ob ein neues Archiv im input Verzeichnis der Nutzer erzeugt wurde und dafür schon der komplette forecast erzeugt wurde, wenn ja dann werden für alle cm/fasta Kombinationen innerhalb des Archivs BOINC-Jobs erzeugt. Dabei werden die Grenzwerte zur Bündelung, wie bereits diskutiert, berücksichtigt.

Zu beachten ist dabei das der Nutzer natürlich jederzeit wissen möchte welchen Status seine Batch hat. Mit diesem Workflow können wir den aktuellen Job-Forecaster und Job-Generator behalten und auch etwaige zukünftige Apps/UseCases unterstützen. Was man noch separat betrachten müsste wäre der Use-Case das der Nutzer Rohdaten hochladen möchte die dann automatisch die gesamte infernal-Pipeline durchwandern sollen. Das wäre schon was feines, benötigt aber auch etwas mehr Hirnschmalz und Zeit. Ich denke der vorgeschlagene Workflow ist dafür schon gut vorbereitet.

@Michael: Du bist ja der Hauptnutzer von RNAWorld und kennst dich mit der Wissenschaftlichen Seite aus. Welche Anwendungsfälle siehst du am weitesten verbreitet bzw. würdest du gern haben? Das hochladen einer einzelnen cm/fasta Kombination oder von mehreren? Das automatische durchlaufen der Pipeline oder Anpassung der Dateien zwischen den einzelnen Anwendungen weil man schon bestimmte Dinge ausschließen kann?

[Michael H.W. Weber]

OK. Also ich wollte regulären Nutzern die Möglichkeit eröffnen bis zu 5 Jobs einzustellen. Keine Archive.
Der Grund: Leute, die ganze Archive abarbeiten wollen, mögen sich bitte mit mir in Verbindung setzen, damit wir die Berechnungen für sie durchführen und das Ganze dann im Rahmen eines Kooperationsprojektes auch ZUSAMMEN mit den Auftraggebern publiziert wird. Wir wollen ja veröffentlichbare Ergebnisse mit unserem System generieren und darin auch genannt werden.

Wir brauchen Interfaces für alle jetzt schon implementierten Apps, also CMBUILD, CMCALIBRATE, CMSEARCH und CMALIGN. Hinzu kommt der InReAlyzer. CMSEARCH benötigt zwingend CMBUILD und CMCALIBRATE, wenn man eigene Jobs erstellen will. Dennoch sollte der Fokus auf CMSEARCH liegen, da dieses ja bereits lief.

Das bislang als "private queue" angezeigte Job Submission Interface, sollen Leute nur nutzen können, wenn sie selbst an RNA World teilnehmen und eine Mindestzahl an Jobs selbst erfolgreich validiert abgeliefert haben.

Wie die Inputdateien auf Integrität geprüft werden, besprechen wir aber aus Sicherheitsgründen im internen RNA World Entwicklerforum...

Michael.

[Michael H.W. Weber]

Das Erstellen eines Archivs aus den Eingabedateien auf dem Server und die damit mögliche Nutzung des bestehenden Workflows ab da ist natürlich sinnvoll. Das noch kurz nachgeschoben...

Michael.

[Michael H.W. Weber]

Ich nochmal zum typischen Einsatz des Systems: Der Forscher hat ein Genom eines Bakteriums und will eigentlich nur wissen, ob "seine" RNA darin vorkommt und wo. Also lädt der ein Genom und eine CM-Datei hoch. Wir ermöglichen mit unserem System immerhin 5 Suchen parallel. Das sollte wirklich für den Hausgebrauch reichen. Natürlich muss er "seine" RNA als Datei erst mal präparieren. Dazu braucht er auf jeden Fall CMBUILD und (fast immer) CMCALIBRATE (wen er statistisch relevante Aussagen haben will).

Michael.

[ChristianB]

Die Beschränkung auf 5 Jobs gibt es nur in der bisherigen Private Queue Implementierung, die aus bisher unbekannten Gründen nicht ehr funktioniert und eh nur ein Hack war. Die in BOINC implementierte UJS arbeitet mit Prioritäten anstatt festen Grenzen. Das könnte man aber eventuell noch als zusätzlichen Hack nachrüsten. Aus technischer Sicht ist mir das Zitieren/kooperieren/whatever ziemlich egal. Wenn das System jemand nutzt dann sollte der das schon angeben, egal ob er nur 5 Jobs oder ein ganzes Archiv berechnet hat.

Wie willst du denn das UserArchiv dann in das System einschleußen? Als eines deiner Archive? Dann musst du aber auch die Daten wieder ausliefern. Überlassen wir das dem Nutzer haben wir den Überblick und brauchen nicht so viele Extrawürste braten.

[yoyo]

Unser jetziges UserJobSubmission interface nutzt den von Christian am Anfang beschriebenen Workflow bereits.

Richtig ist, dass im jobSubmissionInterface eine .cm und eine .fasta (und evtl. Parameter) hochgeladen werden. Aber das cgi script welches diese Daten entgegen nimmt erzeugt daraus ein zip file, welches genau so aussieht wie die von Michael per ftp hochgeladenen zips, mit der Einschränkung, dass eben nur eine cm und eine fasta enthalten sind.
Dieses wird dann dem existierenden wu Generator vorgeworfen. Der wu Generator macht dann selber einen forecast, weil er keine forecast Datei gefunden hat.

Der WU Generator ist der gleich, nur das input zip wird eben nicht aus einem Inputverzeichnis genommen, sondern aus dem UserInput erzeugt.

Wie ich schon im anderen Thread sagte, finde ich auch dass das UserJobInterface nicht für Massen WU Erzeugung genutzt werden sollte. Dafür sollte der User uns schon direkt kontaktieren und wir (bzw. Michael) können dann das zip erzeugen und einstellen. Schließlich kann man mit diesem Interface gleichmal Milliarden von WUs erzeugen, die eben auch Tausende von Stunden laufen. Das sollten wir mehr unter unserer Steuerung laufen lassen.

[ChristianB]

Das ist aber in meiner Skizze auch möglich. Dafür muss die beschriebene Sandbox einfach nur beschränkt werden. Ich verstehe aber die Bedenken durchaus. Dafür kann man aber Schranken einbauen.

[Michael H.W. Weber]

Wir machen es jetzt bitte so, wie Yoyo/ich oben schrieb: Also keine Archiventgegennahme ermöglichen und maximal 5 (oder auch nur 3) Jobs pro App pro User zulassen. Jobs werden nur einspeisbar, wenn jemand einen Account hat und schon einiges an WUs (wieviel, überlasse ich gerne Dir) erfolgreich berechnet hat.

Das System war übrigen kein "hack", sondern voll funktionell für CMSEARCH. Ich habe damit etliche WUs durchgerechnet und lokal validiert. Auch "fakes" habe ich in diversen Varianten eigespeist; sie wurden alle als solche erkannt und zurückgewiesen. Da muss ich jetzt mal Maximilian Palm in Schutz nehmen, der das alles ursprünglich als "Klon" von Leiden Classical aufgesetzt hat.
Einen Fehler hatte es: Bestimmte zusammenfassende Symbole für mögliche Basen waren nicht berücksichtigt. Zum Beispiel der Buchstabe N als Platzhalter für irgend eine Base aus der Menge A,C,G,T,U wurde nicht erlaubt. Das muss bei den neuen Interfaces noch verbessert werden.

Christian: Mir ist völlig klar, dass David da jetzt irgendwas an generalisierten, neuen Möglichkeiten für JobSubmissions geschaffen hat und daher jetzt wohl einiges anders organisiert ist. Aber das Prinzip ist im Grunde dasselbe, was wir schon erfolgreich nutzten.
Diese Interfaces gibt es (genau wie die VM-Möglichkeiten) nur, weil wir es vorgeschlagen haben und seit Jahren konsequent fordern.

Die Fertigstellung der Interfaces wäre für das Projekt ein Riesenschritt nach vorne, weil es dann endlich für Externe offen wird!!! Es wird den Wert, d.h. den praktischen Nutzen von RNA World verfielfachen. Ich hoffe darauf schon seit Jahren...

Michael.

[Michael H.W. Weber]

Das ist aber in meiner Skizze auch möglich. Dafür muss die beschriebene Sandbox einfach nur beschränkt werden. Ich verstehe aber die Bedenken durchaus. Dafür kann man aber Schranken einbauen.

Deine Skizze ist doch nichts anderes, als was wir wollen. Bloss keine Archive zulassen...

Michael.

[yoyo]

Einen Fehler hatte es: Bestimmte zusammenfassende Symbole für mögliche Basen waren nicht berücksichtigt. Zum Beispiel der Buchstabe N als Platzhalter für irgend eine Base aus der Menge A,C,G,T,U wurde nicht erlaubt.

Die hatte ich noch eingebaut.

[ChristianB]

Das es nicht funktionabel war sagt ja keiner. Nur ist es in meinen Augen nicht gut wartbar und nicht gerade Zukunftsfreundlich. Ich werde mich jetzt mal bemühen das Queue System wieder zum laufen zu bekommen.

[Michael H.W. Weber]

Christian, niemand hat gesagt, Du sollst das Ding von Max einfach reaktivieren. Nein, Du sollst Dein Ding da machen - was wie üblich sauber durchdacht ist.

Allerdings möchten Yoyo und Ich, dass die User keine Archive einstellen können. Aus verschiedenen Gründen. Zum einen möchte ich gerne Kooperationsprojekte mit anderen Forschergruppen weltweit etablieren. Zum anderen möchte ich nicht erleben müssen, dass doch mal etwas eingestellt wurde, was dann Fehler verursacht und wir haben 1 Mio Jobs vor die Wand gefahren.

Irgendwie reden wir etwas aneinander vorbei. Da sehen wir wieder den Unterschied zwischen einem Verein, der auf Forenkommunikation basiert und einer Gruppe, die vor Ort etwas umsetzt. Ich freue mich auch diesbezüglich schon wieder auf Chemnitz!

Ist denn jetzt klar geworden, was ich meine?
Nico & Du hatten doch in Berlin schon für CMSEARCH ein neues Interface gebaut, wenn ich mich richtig erinnere, wo nur noch Kleinigkeiten zu tun waren?

Michael.