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.

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

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.

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.

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:

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:

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

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:

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.

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 = "<slurm@statistik.tu-dortmund.de>"
mail.to = "<login@statistik.tu-dortmund.de>"
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

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:

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.