Benutzung des Computeclusters ============================= An der Fakultät betreiben wir einen kleinen HPC Cluster. Dieser ersetzt die früheren Computeserver der Lehrstühle. Im Vergleich zu einem großen HPC Cluster wie LiDO, der vom ITMC betrieben wird, bietet unser System einige Komfortextras um das interaktive Arbeiten zu erleichtern. Die Softwareausstattung ist dabei genauer auf die Ansprüche an unserer Fakultät abgestimmt. Vor dem erstmaligen Zugriff muss ein Account für die Nutzung freigeschaltet werden. Dies ist auch für Studenten problemlos möglich. Hierzu einfach die `Sysadmins `_ kontaktieren. Grundlegende Benutzung ----------------------- Die Ressourcenverwaltung des Clusters übernimmt der Resource Manager SLURM. Die Kommunikation mit unserem Cluster erfolgt immer von unserem Server mit Shellzugang ``shell.statistik.tu-dortmund.de`` aus. Dies hat den Vorteil, dass man auch von zu Hause aus Jobs absenden oder ihren Status überprüfen kann. Zur direkten Interaktion mit dem Cluster dienen die Befehle ``salloc``, ``sbatch`` sowie ``srun`` zum Starten von Jobs, ``scancel`` zum Abbrechen Jobs, ``squeue`` zum Ansehen der momentanen Jobwarteschlange und ``sacct`` zur Betrachtung der Jobhistorie. Mit der Option ``-u $USER`` kann man die Ausgaben der Jobwarteschlange und -historie auf den eigenen Account einschränken. Das Starten von Jobs sollte nur in Ausnahmefällen über die zuvor genannten Befehle notwendig sein. Im Normalfall wird man eines der im weiteren Verlauf beschriebenen Skripte benutzen. Das Abbrechen eines Jobs erfolgt mit ``scancel $JobID`` Die JobID ist eine laufende Nummer, die jeder Job beim Start zugewiesen bekommt. Man kann sie auch mit dem Befehl ``squeue`` nachschlagen. Hat man sehr viele Jobs, die man alle abbrechen möchte, da man zum Beispiel einen Fehler im Skript gefunden hat, kann man den Befehl ``kill_all_jobs`` verwenden. Dieses Skript macht nach einer Sicherheitsabfrage genau das, was der Name sagt und bricht alle Jobs des eigenen Accounts ab. Die offiziellle Dokumentation des verwendeten Resource Managers SLURM gibt es `hier `_. Walltime und Speicher --------------------- Um jedem Job einen passenden Computeknoten zuweisen zu können, benötigt der Resource Manager Angaben über die zu erwartende Laufzeit und den Speicherverbrauch. Darüber muss man sich vor dem Start eines Jobs einen Moment Gedanken machen. Dafür ist es aber nicht notwendig, von Hand einen Rechner mit freien CPUs und ausreichend freiem Speicher zu suchen. Bei der Wahl von Walltime und Memory ist zu bedenken, dass diese Grenzen hart sind. Wenn sie überschritten werden, wird der Job automatisch beendet. Aber je kleiner die Werte sind, desto einfacher ist es für das Batchsystem einen freien Platz zu finden. Die Walltime sollte man aber trotzdem eher konservativ wählen, da unsere Computeknoten unterschiedlich schnell sind. Während die virtuellen Maschinen Compute1/2 und der Linuxpool etwa gleich schnell sind, ist die Geschwindigkeit der neuen Computemaschinen variabel und abhängig von Auslastung und Umgebungstemperatur (von vergleichbarer Geschwindigkeit zu den anderen Knoten bis ca. 2-fache Geschwindigkeit ist möglich). Die maximale Walltime für Batchjobs beträgt 2 Tage. Interaktive Jobs können bis zu 14 Tage Walltime anfordern. Es ist aber nicht zu empfehlen, so lange Jobs zu verwenden. Wir behalten es uns vor diese Werte noch zu ändern. Wenn man nicht weiß, wie lange Jobs laufen und wie groß ihr Speicherbedarf ist, empfiehlt es sich ein oder zwei Testjobs zu starten. *R* gibt im Batchbetrieb standardmäßig am Ende die Laufzeit des Jobs in der Logdatei aus. Durch einen manuellen Aufruf des Garbage Collectors mit ``gc()`` als letzten Befehl in einem *R* Skript bekommt man zusätzlich eine Ausgabe über den maximalen Speicherbedarf. Falls ein Job vorzeitig durch den Ressourcenmanager beendet wird, dann steht der Grund meistens am Ende der Logdatei. Falls dort nichts steht (kann passieren, wenn der Job hart beendet wurde), kann man mit ``sacct`` nachträglich Informationen über die eigenen Jobs beim Ressourcenmanager abfragen. Die Standardausgabe enthält Kurzinformationen vom aktuellen Tag. Ausführliche Informationen ab einem bestimmten Datum erhält man mit ``sacct -S MMDD -l``. Für aktuell laufende Jobs bekommt man Informationen mit ``sstat``. Insgesamt stehen in unserem Cluster 85 CPUs und 358 GB an Speicher zur Verfügung, die aber nicht gleichmäßig über die 11 Rechenknoten verteilt sind. Von diesen 85 CPUs kann ein einzelner Benutzer maximal 65 gleichzeitig belegen. Weitere Jobs werden in der Warteschlange eingereiht und automatisch nach Abschluss von laufenden Jobs ausgeführt. Falls ein Computeknoten ausfällt (Hardwaredefekt, Stromausfall, etc.) wird das Batchsystem die darauf laufenden Batchjobs automatisch auf einem anderen Knoten erneut starten. Die Ausführreihenfolge von Jobs in der Warteschlange hängt von ihrer Priorität ab. Die Priorität wird auf Basis von verwendeter Rechenzeit innerhalb der letzten Wochen und der Wartezeit berechnet, um eine ausgeglichene Ressourcenzuteilung zwischen den verschiedenen Benutzern zu gewährleisten. Hier noch eine Übersicht wie viele Jobs mit einem bestimmten Speicherverbrauch gleichzeitig auf unserem Cluster ausführbar sind. ================= =========== Speicher bis x MB Anzahl Jobs ================= =========== 2600 85 3000 78 4000 71 8000 41 16000 18 32000 8 64000 4 ================= =========== Lücken in der Knotenauslastung werden natürlich vom Batchsystem bestmöglich gefüllt. Selbst wenn 4 64000MB Jobs laufen, könnte das System zum Beispiel durchaus noch 2 16000MB Jobs, 15 4000MB Jobs und 5 2000MB Jobs oder 37 2600MB Jobs auf den Knoten mit geringerem Speicherausbau starten. Interaktive Jobs ------------------- Wie zuvor erwähnt bietet unser Cluster die Möglichkeit, sehr komfortabel einen Job zum interaktiven Arbeiten zu bekommen. Im Gegensatz zu einem gewöhnlichen HPC Cluster muss man sich nicht in die normale Jobwarteschlange einreihen. Die Anzahl der interaktiven Jobs ist (abhängig von Speicherverbrauch und genutzter Anzahl an CPU Kernen) zur Zeit auf maximal 36 limitiert. Wenn gleichzeitig mehr interaktive Jobs angefragt werden, wird auch hier eine Warteschlange gebildet. **Es ist daher zu empfehlen, wenn immer möglich den Batchbetrieb zu nutzen.** Zum Starten eines interaktiven Jobs benutzt man das Skript ``interactive``. Dieses Skript startet eine interaktive Shell auf einem Computeknoten. Man kann dies wie von den alten Lehrstuhlcomputeservern gewohnt natürlich auch innerhalb von ``screen`` machen um zwischenzeitlich die Verbindung trennen zu können. Ruft man das Skript ohne Optionen auf, fragt es nach der Walltime (gewünschte Nutzungsdauer) und Speicherbedarf. Danach stellt es eine Verbindung mit dem zugewiesenen Knoten her. Die manuelle Suche nach einem Rechner mit ausreichend freiem Speicher und freien CPUs entfällt. Im Anschluss kann man ganz normal seine Programme (z.B. *R*) starten. Gibt man bei der Walltime und dem Speicher nichts an, bekommt man 12h Zeit und 1024 MB an Speicher. .. warning:: Nach Ablauf der Walltime oder bei Überschreitung des angemeldeten Arbeitsspeichers wird in jedem Fall die Sitzung automatisch beendet. Das Skript kennt noch zwei zusätzliche Argumente ``ncpus`` und ``queue``. Mit ``ncpus`` (angelehnt an die LiDO PBS Option ``ppn``) kann man sich mehrere CPUs für den interaktiven Job reservieren (z.B. ``ncpus=4`` für 4 Kerne). Dies ist interessant, wenn man unter *R* mit dem Paket ``parallel`` parallelisieren will. Mit der Option ``queue`` kann man auf eine andere Queue im Cluster wechseln. Dies macht nur für Testzwecke der Admins Sinn. Die Matlab Queue ist nur für die Mitglieder der Gruppen LSIckstadt und LSRahnenfuehrer zugänglich. Die komplette Hilfe des Befehls bekommt man mit ``interactive help`` Diese komfortable Möglichkeit der Computenutzung hat aber einge Nachteile. Wenn man einen Job vergisst (z.B. weil man seine Screensitzung getrennt hat), wird er vom Batchsystem ohne weitere Nachfrage nach Ende der Walltime beendet. Es gibt hier keinen Admin, der vorher noch einmal nachfragt. Dafür können vergessene Jobs auch keinen Rechner mehr dauerhaft blockieren. Falls der zugewiesene Computeknoten ausfällt, können im interaktiven Modus gestartete Jobs nicht vom Batchsystem automatisch neu gestartet werden. Beispiel: Starten eines interaktiven Jobs mit Abfrage der Ressource (hier 3:30h Nutzungsdauer, 512 MB Speicher), Starten von *R*, Beenden von *R* und Abschluss des interaktiven Jobs. .. code-block:: none skrey@shell:~$ interactive Walltime ([dd-hh:]mm[:ss]) : 3:30:00 Memory : 512 salloc: Granted job allocation 9898 skrey@computed:~$ R > > quit() Save workspace image? [y/n/c]: n skrey@computed:~$ exit logout salloc: Relinquishing job allocation 9898 skrey@shell:~$ Weiteres Beispiel: Starten eines interaktiven Jobs ohne Abfrage der Ressourcen (direkte Übergabe als Argument), Anfrage von 2 Kernen und Wechsel in die Queue ``matlab`` .. code-block:: none skrey@shell:~$ interactive walltime=3:30:00 memory=512 ncpus=2 queue=matlab salloc: Granted job allocation 9899 skrey@computec:~$ matlab >> >> quit skrey@computec:~$ exit logout salloc: Relinquishing job allocation 9899 skrey@shell:~$ Man sieht hier direkt, wie der Resourcen Manager unterschiedliche Computeknoten zugewiesen hat. Gibt man bei der Walltime nur eine Zahl ohne Doppelpunkt an, so wird diese Zahl als Minuten interpretiert (LiDO geht dagegen von Sekunden aus). Alle optionalen Argumente kann man auch in eine Konfigurationsdateien für das Skript (`.interactiveconf` im Homeverzeichnis des Benutzers) eintragen. Dann werden sie nicht mehr abgefragt. R im Batchbetrieb -------------------- Das Skript ``submitR`` dient zum Starten von *R* Batchjobs. Im Vergleich zu ``interactive`` fragt es zusätzlich noch eine Mailadresse zur Benachrichtigung von Jobstart, -ende und -fehler ab (abschaltbar über die Option ``mail=false``). Der Standard dafür ist `login@statistik...` Der Standardwert für den Arbeitsspeicher ist hier aber nur 512 MB. Zusätzlich gibt es noch die Optionen ``outdir``, die den Ort für die Logdateien des Jobs festlegt (Standard ist das aktuelle Verzeichnis, wenn das angegeben Verzeichnis nicht existiert, wird es angelegt), und ``autosubmit``. Der Standard für Autosubmit ist ``autosubmit=true`` (im Gegensatz zu dem einigen LiDO Nutzern bekannten Skript von Olaf Mersmann) und schickt den Job direkt an das Batchsystem. Mit ``autosubmit=false`` wird nur eine Jobdatei generiert, die man mit ``sbatch`` von Hand abschicken muss (praktisch, wenn man Optionen setzen möchte, die ``submitR`` nicht unterstützt). Dieses Skript kennt die Option ``ncpus`` zur Reservierung mehrere Prozessoren nicht. Dafür gibt es ein paar andere Optionen um einfach parallelisierte Jobs oder eine große Anzahl von Jobs mit nur geringen Änderungen (z.B. bei einer Simulationsstudie) zu starten. Braucht man keine Prozesskommunikation, dann kann man ein Skript mit unterschiedlichen Einstellungen mit Hilfe der Option ``replicate`` (z.B. ``replicate=3``, was äquivalent zu ``replicate=1-3`` ist, oder ``replicate=1,3-5``) starten. Dies startet dann die entsprechende Anzahl an Jobs und setzt für jeden Job eine Umgebungsvariable mit der Replikatnummer, die man mit ``Sys.getenv("PBS_ARRAYID")`` abfragen kann und zur Indizierung eines Objekts mit Parametern, setzen von Seeds oder Ähnlichem benutzen kann. Diese Variante der Erzeugung von mehreren *R* Jobs hat gegenüber der Parallelisierung über mehrere CPU Kerne oder MPI den Vorteil, dass die Jobs kleiner sind und damit einfacher einen freien Platz auf dem Cluster bekommen. Außerdem kann man mit dieser Method sehr einfach parallelisieren, da nur minimale Änderungen an seriellen Rskripten notwendig sind. Nach dem Ende der Jobs sollte man auf jeden Fall die Logdateien ansehen, um evtl. aufgetretene Fehler zu erkennen. Falls es zu einem Abbruch wegen Walltime- oder Speicherüberschreitung kommt, steht dies ebenfalls in der Logdatei. Ein schnelles Durchsuchen von Logdateien nach Abbrüchen wegen Walltime- oder Speicherüberschreitung ermöglicht der Aufruf von ``fgrep -i -e killed -e cancelled *.out|awk '{print $1}'``. Möchte man für die Vergleichbarkeit der Laufzeit von Jobs sicherstellen, dass sie immer auf der gleichen Art von Knoten ausgeführt werden, dann kann man bei ``submitR`` mit der Option ``excludenodes`` die Knotenauswahl auf gleichartige Knoten einschränken. Mit der Option ``Rversion`` lässt sich die *R* Version festlegen, zum Beispiel ``Rversion=3.0.3``. Die Voreinstellung ist die jeweils aktuellste installierte Version, die auch im interaktiven Betrieb durch einen einfachen Aufruf von ``R`` gestartet wird. Beispiel: *R* Batchjob mit Standardwerten. .. code-block:: none skrey@shell:~$ submitR test.R Notify address : Using default address 'skrey@statistik.tu-dortmund.de'. Walltime ([dd-hh:]mm[:ss]) : Using default walltime of 12:00:00. Memory : Using default memory of 512 MB. Chosen queue : all Chosen job id : 1369223637 Working directory : /home/skrey PBS Job ID : Submitted batch job 9904 skrey@shell:~$ Das Skript hat jetzt einen Job für 12h Laufzeit mit 512MB zugewiesenem Speicher gestartet. Benachrichtungen werden an meine Statistikmailadresse geschickt. Die `PBS Job ID` ist die Nummer des Jobs innerhalb des Batchsystems. Um diesen Job abzubrechen, gibt man den Befehl ``scancel 9904`` ein. Beispiel: Mehrere bis auf eine Parameterliste identische *R* Batchjobs mit ``replicate``. Walltime per Befehlszeile auf 2 Minuten gesetzt und die Logfiles gehen in das Verzeichnis `artest`. .. code-block:: none skrey@shell:~$ submitR artest.R walltime=2 replicate=1,3-5 outdir=artest Notify address : Using default address 'skrey@statistik.tu-dortmund.de'. Memory : Using default memory of 512 MB. Chosen queue : all Chosen job id : 1369225331 Working directory : /home/skrey PBS Job ID : Submitted batch job 9913 PBS Job ID : Submitted batch job 9914 PBS Job ID : Submitted batch job 9915 PBS Job ID : Submitted batch job 9916 skrey@shell:~$ Das zugehörige *R* Skript sieht so aus: .. code-block:: none p <- as.integer(Sys.getenv("PBS_ARRAYID")) print(p) param <- list(list(ar = c(1, -0.9, 0.3)), list(ar = c(1, -0.4, 0.1)), list(ar = c(1, -0.4, 0.1)), list(ar = c(0.8897, -0.4858), ma = c(-0.2279, 0.2488)), list(order = c(1,1,0), ar = 0.7) ) # Sinnvolle Initialisierung des Zufallszahlengenerators fuer parallele # Berechnungen: library("rlecuyer") .lec.SetPackageSeed(c(6,13,73,4,52,1)) # rlecuyer Aequivalent zu set.seed() nstreams <- 5 # Anzahl der Zufallszahlenstreams names <- paste("myrngstream",1:nstreams,sep="") # Irgendein Name fur den RNG Stream .lec.CreateStream(names) # Zufallszahlenstreams erstellen .lec.CurrentStream(names[p]) # Auswahl des p-ten Streams. y <- arima.sim(n = 1000, param[[p]]) z <- ar(y) print(z) save(z, file=paste("artest-", p, ".RData", sep="")) Zuerst wird die Umgebungsvariable `PBS_ARRAYID` ausgelesen und als Integer in `p` gespeichert. Mit diesem `p` wird dann die Parameterliste inidiziert. Im Anschluss werden mit `rlecuyer` 5 unabhängige Zufallszahlenströme erzeugt und der Strom `p` ausgewählt (für Reproduzierbarkeit von Simulationen wichtig) Damit werden dann Daten simuliert, ein AR Modell geschätzt und das Modell gespeichert. Der Dateiname setzt sich auch wieder aus einem selbstgewählten Teil und dem Parameterindex `p` zusammen. ``submitR`` bietet auch die Möglichkeit die verschiedenen Parallelisierungssysteme von *R* zu nuten. Startet man ``submitR`` mit der Option ``mcparallel`` vor der auszuführenden `.R`-Datei (z.B. ``submitR mcparallel mctest.R``) dann können die Mehrkernfunktionen der Pakete `parallel` und `multicore` (``mclapply``, ``mcparallel``, etc.) direkt wie auf einem Desktop Computer verwendet werden. Es ist keine Initialisierung notwendig. Zusätzlich zu den zuvor beschriebenen Einstellungen wird hier noch die Anzahl der zu verwendenden CPU Kerne abgefragt. Diese kann auch über die Option ``ntasks`` auf der Befehlszeile angeben werden. Die maximale Anzahl an CPU Kernen liegt für die neue Computemaschine bei 12. Die VMs Compute1/2 und der Linuxpool haben weniger Kerne zur Verfügung (6 bzw. 5). Ein sinnvoller Kompromiss aus Geschwindigkeitssteigerung durch Parallelisierung und Minimierung der Wartezeit auf einen ausreichend großen Computeknoten ist ``ntasks=4``. Mit der Option ``parallel`` vor der `.R`-Datei startet *R* in einer MPI Umgebung und es kann das Paket `parallel` (sowie die veralteten Pakete `snow` und `snowfall`) mit `Rmpi` verwendet werden.. Bei der Verwendung von `Rmpi` muss man daran denken zum sauberen Beenden des Jobs am Ende des Rskripts ``mpi.exit()`` aufzurufen. Ohne diesen Aufruf denkt das Batchsystem, dass der MPI Job nicht sauber beendet wurde und meldet einen Abbruch des Jobs in der zugehörigen E-Mail. Mit MPI ist man nicht auf die CPU Kerne eines Rechenknotens beschränkt. Daher können mit ``ntasks`` bis zu 65 CPU Kerne verwendet werden (die maximale Anzahl von einem Nutzer gleichzeitg auf unserem Cluster verwendbaren CPU Kerne). Die Knotenzuteilung für MPI Jobs bevorzugt sortenreine Knoten um die Ausführungsgeschwindigkeit zu maximieren, indem über die Option ``excludenodes`` von ``submitR`` alle Knoten mit abweichender Hardwareausstattung ausgeschlossen werden. Dies kann die Schedulingzeit unter Umständen deutlich verlängern. Die automatische Auswahl kann durch manuelles Übergeben der Option übersteuert werden. Alternativ kann durch die Option ``sensiblempi=false`` eine möglichst schnelle Zuteilung der gewünschten Anzahl der CPUs erreicht werden (mit dem Risiko nicht sortenreine Knoten zu bekommen, was die Ausführungsgeschwindigkeit reduziert). Zum Schluss noch ein Beispiel für einen parallelen R Job mit MPI: .. code-block:: none skrey@shell:~$ submitR parallel testp.R autosubmit=true email=skrey walltime=10 memory=2048 Number of tasks (#) : 12 Chosen queue : all Chosen job id : 1369228604 Working directory : /home/skrey PBS Job ID : Submitted batch job 9919 skrey@shell:~$ Nach einer Abfrage der Anzahl an Tasks (kann auch mit der Option ``ntasks`` direkt übergeben werden), startet der parallele *R* Prozess. Im folgenden ein paar minimale Beispiele, wie man ein Skript für einen parallelen *R* Job mit MPI aufbauen kann (sollte). Parallel mit MPI .. code-block:: none library("Rmpi") library("parallel") # Da R immer einen Kontrollprozess benötigt muss die Anzahl der Worker um 1 # kleiner als die Anzahl der vom Batchsystem zugewiesenen Tasks sein. ntasks <- mpi.universe.size() - 1 # Cluster initialisieren cl <- makeCluster(ntasks, type = "MPI") # Zufallszahlengeneratoren auf allen Workern des Clusters mit einem bestimmten # seed initialisieren (verhindert Zyklen in den Zufallszahlen zwischen den # Workern) clusterSetRNGStream(cl, iseed=42) # Paralleler Code, z.B. mit clusterApply, parSapply(), clusterEvalQ(), etc. # Cluster und MPI beenden stopCluster(cl) mpi.exit() Snowfall mit MPI: .. code-block:: none library("Rmpi") library("snowfall") # Da R immer einen Kontrollprozess benötigt muss die Anzahl der Worker um 1 # kleiner als die Anzahl der vom Batchsystem zugewiesenen Tasks sein. ntasks <- mpi.universe.size() - 1 # Snowfall initialisieren sfInit(parallel=TRUE, type="MPI", cpus=ntasks) # Zufallszahlengeneratoren auf allen Workern des Clusters mit einem bestimmten # seed initialisieren (verhindert Zyklen in den Zufallszahlen zwischen den # Workern) sfClusterSetupRNGstream(seed=c(6,13,73,4,52,1) # Paralleler Code, z.B. mit sfSapply() # Snowfall und MPI beenden sfStop() mpi.exit() Beim Schreiben von Skripten für parallele MPI Jobs sollte man das Paket `parallel` verwenden. Dieses stellt alle relevanten Funktionen von `snow` zur Verfügung und ist in der Standardinstallation von *R* enthalten. `snowfall` ist zwar sehr komfortabel in der Benutzung, aber leider auch sehr langsam in der Kommunikation mit den einzelnen Workerprozessen, wodurch man einen großen Teil des Geschwindigkeitgewinns durch Parallelisierung verschenkt. Von der Verwendung des Pakets `multicore` ist abzuraten. Es erkennt nicht die Anzahl der zugewiesenen CPU Kerne und startet daher viel zu viele *R* Prozesse. Dies erhöht den Speicherverbrauch unnötig und macht die Berechnung langsam, da das Betriebssystem ständig zwischen den viele R Prozessen hin und her springt. Die `mc*` Funktionen des Pakets `parallel` haben dieses Problem nicht. Alle optionalen Argumente kann man auch hier in eine Konfigurationsdateien für das Skript (`.submitrconf` im Homeverzeichnis des Benutzers) eintragen. Dann werden sie nicht mehr abgefragt. R mit Batchjobs --------------- Zur Verwendung des *R* Pakets `BatchJobs` ist eine clusterspezifische Templatedatei und eine persönliche Konfigurationsdatei notwendig. Die Templatedatei für unseren Cluster liegt unter ``/opt/R/BatchJobs/dortmund_fk_statistik.tmpl``. In diesem Verzeichnis ist auch eine Beispielkonfigurationsdatei, die man sich kopieren kann: ``cp /opt/R/BatchJobs/.BatchJobs.R ~/`` Vor der Benutzung müssen noch die E-Maileinstellungen (insb. der Empfänger in ``mail.to``) angepasst werden. Je nach Job wird man auch die Laufzeit ``walltime`` und den Speicherverbrauch ``memory`` pro Job anpassen müssen. Die Walltime wird hier in Sekunden angegeben. .. code-block:: none cluster.functions = makeClusterFunctionsSLURM("/opt/R/BatchJobs/dortmund_fk_statistik.tmpl") default.resources = list( walltime = 3600L, memory = 1024L, ntasks = 1L, ncpus = 1L ) mail.start = "first+last" mail.done = "first+last" mail.error = "all" mail.from = "" mail.to = "" mail.control = list(smtpServer="mail.statistik.tu-dortmund.de") debug = FALSE Die vollständige Dokumentation ist auf der Projektseite von `BatchJobs `_ zu finden. Insbesondere die Seite zur Benutzung in `Dortmund `_ sollte man sich durchlesen. Matlab im Batchbetrieb ---------------------- Für die Mitglieder der Gruppen LSIckstadt und LSRahnenfuehrer steht die Matlab Installation von Nein-Tim zur Verfügung. Das Skript ``submitM`` dient zum Starten von Matlab Batchjobs. Im Vergleich zu ``interactive`` fragt es zusätzlich noch eine Mailadresse zur Benachrichtigung von Jobstart, -ende und -fehler ab (abschaltbar über die Option ``mail=false``). Der Standard dafür ist `login@statistik...` Die Option ``queue`` fehlt, da nur die `matlab` Queue in Frage kommt. Der Standardwert für den Arbeitsspeicher ist hier aber nur 512 MB. Zusätzlich gibt es noch die Optionen ``outdir``, die den Ort für die Logdateien des Jobs festlegt (Standard ist das aktuelle Verzeichnis, wenn das angegeben Verzeichnis nicht existiert, wird es angelegt), und ``autosubmit``. Der Standard für Autosubmit ist ``autosubmit=true`` (im Gegensatz zu dem einigen LiDO Nutzern bekannten Skript von Olaf Mersmann) und schickt damit den Job direkt an das Batchsystem. Mit ``autosubmit=false`` wird nur eine Jobdatei generiert, die man mit ``sbatch`` von Hand abschicken muss (praktisch, wenn man Optionen setzen möchte, die ``submitM`` nicht unterstützt). Beispiel: Matlab Batchjob für 5 Minuten, Logdateiausgabe in das Verzeichnis `testjob` .. code-block:: none skrey@shell:~$ submitM test.m outdir=testjob Notify address : Using default address 'skrey@statistik.tu-dortmund.de'. Walltime ([dd-hh:]mm[:ss]) : 5 Memory : Using default memory of 512 MB. Chosen queue : matlab Working directory : /home/skrey PBS Job ID : Submitted batch job 9900 skrey@shell:~$ Ich habe hier bei der Mailadresse und Speicher keine Angaben gemacht, daher wurden die Standardwerte verwendet. Im nächsten Beispiel habe ich Autosubmit abgeschaltet und alle Optionen beim Aufruf direkt angegeben: .. code-block:: none skrey@shell:~$ submitM test.m autosubmit=false ncpus=2 email=skrey walltime=5 memory=256 Chosen queue : matlab Working directory : /home/skrey --- Generated batch job -------------------------------------------------------- -------------------------------------------------------------------------------- Run sbatch submitM.Nb2YWX to submit the job to the batch system. You can then safely remove the job file: rm -f submitM.Nb2YWX Das Skript hat jetzt die Jobdatei `submitM.NB2YWX` generiert, die man noch anpassen kann und danach mit ``sbatch`` startet. Alle optionalen Argumente kann man auch hier in eine Konfigurationsdateien für das Skript (`.submitmconf` im Homeverzeichnis des Benutzers) eintragen. Dann werden sie nicht mehr abgefragt.