http://www.tu-ilmenau.de

Logo TU Ilmenau


Ansprechpartner

UniRZ

IT Service Desk

Telefon +49 3677 69-1111

E-Mail senden

Ihre Position

INHALTE

Overview

Der Zugang zu den Computeservern erfolgt über das TUILAN.
In einer interaktiven Session erfolgt der Start der Software auf einem interaktiven Knoten der Clusterinfrastruktur - und die grafische Ausgabe  erfolgt auf dem Clienten - auf dem PC oder auf auf dem Notebook an dem Arbeitsplatz des Nutzers.

Das Jobverwaltungssytem LSF (Load Sharing Facility) ermöglicht durch das Starten von Batchjobs aus einer interaktiven Session den Zugriff auf die Computeknoten der Clusterinfrastruktur. Ein direkter Zugriff zu einzelnen Computeknoten der Clusterinfrastrukur ist nicht möglich.
Jeder Job wird beim Starten durch eine von LSF zugeteilte Jobnummer (JobID) eindeutig gekennzeichnet. Bevor ein Job gestartet wird muß der Job hinsichtlich seiner Ressourcen (CPU Zeit, RAM) klassifiziert werden. Im Ergebnis dessen wird der Job vom Nutzer durch LSF einer passenden Queue zugeordnet.

Welche Ressourcen benötigt mein Job?
Bevor ein Job auf dem Computeserver ablaufen kann, muß der Nutzer seinen Job hinsichtlich der erforderlichen Ressourcen klassifizieren. Ressourcen können zum Beispiel sein:

  • Interaktiver oder Batchjob
  • Betriebssystem
  • gewünschte CPU- Zeit
  • erforderlicher Hauptspeicher
  • Anzahl der Prozessoren

Die für den Job erforderlichen Ressourcen (Jobparameter) werden mit den vorgegebenen Queuekonfigurationen verglichen und damit einer bestimmten Queue zugeordnet.

batchjob

Als Batchjob wird der Job bezeichnet, welcher keine grafische Ausgabe auf den Clienten benötigt. Die in diesem Job sequentiell abzuarbeitenden Kommandos werden in einem Skriptfile aufgeführt und zeilenweise ausgeführt.

Eine allgemeine Kommandozeile zum Absetzen eines Batchjobs lautet:

bsub -q Batch24 $HOME/start.ansys

Das bsub- Kommando mit den Optionen wird auf dem Clienten ausgeführt. Die Skriptdatei namens start.ansys, welche die abzuarbeitenden Kommandos enthält, muß sich in dem obigen Beispiel in dem Homeverzeichnis ($HOME) des Nutzer befinden! Die Datei start.ansys kann zum Beispiel folgende Kommandos enthalten:

#!/bin/csh
date
cd $HOME/work/ansys
pwd
ls
setansys
ansys100 -p ansysrf < stab.inp
echo endlich fertig mit dem Beispiel

Dieser Job erhält eine Job-ID und wird in die Queue mit dem Namen Batch24 eingeordnet und auf dem Rechenknoten mit der geringsten Belastung (Load) gestartet. Mit dem Kommando bjobs kann der Jobstatus angezeigt werden. Der Output des Jobs kann während der Jobabarbeitung mit dem Kommando bpeek JobID angesehen werden.

Das bsub- Kommando ermöglicht beim Absenden eines Jobs die Angabe vieler Optionen. Daher ist es sinnvoll, sich mit einem Editor (vi, nedit, ieditor) ein Skript zu generieren, welches das bsub- Kommando mit den nachfolgenden Optionen enhält. So ein Skript kann zum Beispiel mit dem Namen start.ansys.lsf bezeichnet werden und folgende Zeile beinhalten:

bsub -q Batch72 -J AnsysJob -o $HOME/ansys.log $HOME/start.ansys

Dieser Job mit dem Namen AnsysJob soll in die Queue Batch72 eingeordnet werden und abgearbeitet werden. Der Job- Outputwird in einer Datei namens ansys.log im Homeverzeichnis gespeichert. Letztendlich wird in diesem Skript das im Homeverzeichnis des Nutzers befindliche Skript start.ansys aufgerufen - welches z. B. folgende Kommandos enthält.

Diese Vielzahl von Optionen beim Absenden eines Batchjobs kann sehr unübersichtlich sein. Im nachfolgenden Abschnitt wird eine weitere Möglichkeit zur kombinierten Abspeicherung der Joboptionen und der auszuführenden Kommandos beschrieben.

Die bsub- Optionen und die Jobbefehle in einem Skriptfile

Für die gemeinsame Abspeicherung der bsub- Optionen und der abzuarbeitenden Kommandos ist notwendig, eine einzige Skriptdatei zu erstellen. Dieser Datei kann der Name "start.ansys.lsf" gegeben werden und folgendermaßen aufgebaut sein:

#!/bin/csh
#BSUB -q Batch72
#BSUB -R linux
#BSUB -J AnsysJob
#BSUB -o ansys.log
date
cd $HOME/work
pwd
setansys
ansys100 -p ansysrf ansys.inp
echo Endlich fertig!
echo War das anstrengend!

Eine Option für das bsub- Kommando wird in der Datei namens Batch mit der Zeichenfolge #BSUB gekennzeichnet. Nachdem alle Optionen aufgeführt sind, folgen dann die auszuführenden Kommandos.

Das Absetzen des Batchjobs mit den aufgeführten Optionen und die Abarbeitung der Kommandos, welche im Skript namens start.ansys.lsf aufgeführt sind, erfolgt dann mit:

bsub < start.ansys.lsf

Dieser Job wird in der Queue namens Batch72 eingeordnet und auf einem vom LSF Jobverwaltungssystem zugeteilten Knoten gestartet. Der Jobname lautet AnsysJob und der Joboutput wird nach Jobende in einer Datei namens ansys.log in dem Verzeichnis abgelegt, aus dem dieser Job gestartet wurde.

Es wird zuerst das Kommando date ausgeführt und anschließend mit dem Kommando cd $HOME/work in das Homeverzeichnis des Nutzers und weiter in das Verzeichnis work gewechselt. Es wird mit pwd das aktuelle Verzeichnis abgefragt und dann das Programm oder Skript namens ansys100 ausgeführt. Zum Schluß werden noch zwei kleine Bemerkungen mit Hilfe des echo Kommandos ausgegeben.

serial batchjobs

Serielle Comsoljobs

Serielle Comsoljobs werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1500 && mapacc"
#BSUB -o lsf_comsol.log
#BSUB -e lsf_comsol.err
#BSUB -J Comsol_Job_seriell
date
pwd

comsol -tmpdir /usr/tmp batch input

date

 

Hinweise

  • dieser Comsoljob wird mit dem Kommando bsub<start.lsf gestartet
  • es muss ein Comsol Inputfile namens input.m existieren - der Name des Inputfiles kann geändert werden - die *.m Extension muss beibehalten werden
  • es wird der Inputfile ohne Extension angegeben
  • die mit #BSUB beginnenden Zeilen stellen die Optionen für das bsub Kommando dar
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1500 MB Hauptspeicher und bekommt den Jobnamen "Comsol_Job_seriell"
  • der (LSF) Output wird in eine Datei namens "lsf_comsol.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_comsol.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Comsoljob mit dem Kommando bsub < start.lsf gestartet wird
  • der Comsolbatchjob wird aus diesem Verzeichnis gestartet - daher befindet sich auch der Comsolinputfile als auch sämtliche Logfiles in diesem Verzeichnis
  • eine Erläuterung aller Comsol Optionen erhält man mit dem Kommando comsol -help

Serielle Matlabjobs

Serielle Matlabjobs werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1500 && mapacc"
#BSUB -o lsf_matlab.log
#BSUB -e lsf_matlab.err
#BSUB -J Matlab_Job_seriell
date
pwd
setmatlab

matlab -nodisplay -nojvm -nodesktop -nosplash < matlab.m > matlab.log

date

 

Hinweise

  • dieser Matlabjob wird mit dem Kommando bsub<start.lsf gestartet
  • es muss ein Matlab Inputfile namens matlab.m existieren - der Name des Inputfiles kann geändert werden - die *.m Extension sollte beibehalten werden
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1500 MB Hauptspeicher und bekommt den Jobnamen "Matlab_Job_seriell"
  • der (LSF) Output wird in eine Datei namens "lsf_matlab.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_matlab.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Matlabjob mit dem Kommando bsub < start.lsf gestartet wird
  • der Matlabbatchjob wird aus diesem Verzeichnis gestartet - daher befindet sich auch der Matlabinputfile als auch sämtliche Logfiles in diesem Verzeichnis
  • eine Erläuterung der Matlab Optionen -nodisplay -nojvm -nodesktop -nosplash erhält man mit dem Kommando matlab -help

Serielle Fluentjobs

Serielle Fluentjobs werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf kann folgende Zeilen beinhalten:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1000 && mapacc"
#BSUB -o lsf_fluent.log
#BSUB -e lsf_fluent.err
#BSUB -J Fluent_Job_seriell
date
cd $HOME/work/fluent
pwd
setfluent
fluent 3d -g < fluent.jou > fluent.log

Hinweise

  • dieser Fluentjob wird mit dem Kommando bsub<start.lsf gestartet
  • es muss ein Fluent Inputfile namens fluent.jou existieren
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • der Fluent Jornalfile namens fluent.jou hat folgenden Inhalt
    file/read-case-data fluent_input.cas
    solve/initialize initialize
    solve/iterate 10
    file/write-data fluent_output.dat
    exit
    yes
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1000 MB Hauptspeicher und bekommt den Jobnamen "Fluent_Job_seriell"
  • der (LSF) Output wird in eine Datei namens "lsf_fluent.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_fluent.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Fluentjob mit dem Kommando bsub < start.lsf gestartet wird

Serielle Ansysjobs

Serielle Ansysjobs werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf kann folgende Zeilen beinhalten:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1500 && mapacc"
#BSUB -o lsf_ansys.log
#BSUB -e lsf_ansys.err
#BSUB -J Ansys_Job_seriell
date
cd $HOME/work/ansys
pwd
setansys11

# mit -p aa_t_a wird die Teaching Advance Lizenz benutzt
ansys140 -p aa_t_a < ansys.inp

# mit -p aa_r wird die Ansys Academic Research Lizenz benutzt
ansys140 -p aa_r  < ansys.inp

date

 

Hinweise

  • dieser Ansysjob wird mit dem Kommando bsub<start.lsf gestartet
  • es muss ein Ansys Inputfile namens ansys.inp existieren - oder der Name des Inputfiles geändert werden
  • die Ansys "Teaching Advanced" Lizenz (aa_t_a) ist knotenpunktlimitiert, die Ansys "Academic Research" Lizenz (aa_r) beinhaltet kein Knotenpunktlimit - die unlimitierte Ansys Lizenz sollte bei entsprechender Notwendigkeit benutzt werden
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1500 MB Hauptspeicher und bekommt den Jobnamen "Ansys_Job_seriell"
  • der (LSF) Output wird in eine Datei namens "lsf_ansys.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_ansys.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Fluentjob mit dem Kommando bsub < start.lsf gestartet wird
  • sinnvollerweise sollten sich der Ansysinputfile (hier: ansys.inp) und die LSF Datei im gleichen Verzeichnis befinden - dann kann das "cd ..." Kommando entfallen

Serielle Maxwelljobs

Serielle Maxwelljobs werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1500 && mapacc"
#BSUB -o lsf_maxwell.log
#BSUB -e lsf_maxwell.err
#BSUB -J Maxwell_Job_seriell
date
pwd
maxwell -BatchSolve -Local -Ng Projektname1.mxwl
date

 

Hinweise

  • dieser Maxwelljob wird mit dem Kommando bsub<start.lsf gestartet
  • es muss ein maxwell Projekt  namens Projektname1.mxwl existieren
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1500 MB Hauptspeicher und bekommt den Jobnamen "Maxwell_Job_seriell"
  • der (LSF) Output wird in eine Datei namens "lsf_maxwell.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_maxwell.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Maxwelljob mit dem Kommando bsub < start.lsf gestartet wird
  • der Maxwellbatchjob wird aus diesem Verzeichnis gestartet - daher befindet sich auch das Maxwellprojekt in Form eines Projektfiles
  • Mit dem Kommando maxwell -help  werden alle Maxwell Startoptionen in einem grafischen Fenster angezeigt

parallel batchjobs

Parallele Comsoljobs

Parallele Comsoljobs werden auf mehr als einem CPU Kern abgearbeitet.

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1500
span[hosts=1]"
#BSUB -oo lsf_comsol.log
#BSUB -eo lsf_comsol.err
#BSUB -J Comsol_Job_parallel
#BSUB -n 4
date
pwd
module purge
module load comsol/v51
comsol batch -np $LSB_DJOB_NUMPROC -tmpdir /usr/tmp/${LSB_JOBID}.tmpdir -autosave on -inputfile  input.mph

date

 

Hinweise

  • eine Vorlage des LSF Batchjob Skript befindet sich im Verzeichnis
    /usr/app-soft/comsol/comsol.lsf 
  • dieser Comsoljob wird mit dem Kommando bsub<start.lsf gestartet
  • dem bsub wird mit der Option "-n 4"die Anzahl der gewünschten CPUs mitgeteilt
  • dem Comsol Solver wird mit der Option "-np $LSB_DJOB_NUMPROC" die Anzahl der zu verwendeten CPUs mitgeteilt
  • es muss ein Comsol Inputfile namens input.mph existieren - der Name des Inputfiles kann geändert werden - die *.mph Extension muss beibehalten werden
  • es wird der Inputfile mit (!) Extension angegeben
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1500 MB Hauptspeicher und bekommt den Jobnamen "Comsol_Job_parallel"
  • der (LSF) Output wird in eine Datei namens "lsf_comsol.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_comsol.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Comsoljob mit dem Kommando bsub < start.lsf gestartet wird
  • der Comsolbatchjob wird aus diesem Verzeichnis gestartet - daher befindet sich auch der Comsolinputfile als auch sämtliche Logfiles in diesem Verzeichnis
  • eine Erläuterung aller Comsol Optionen erhält man mit dem Kommando comsol -help

Parallele ABINIT Jobs

Parallele shared memory MPI basierende ABINIT Jobs können mit nachfolgenden LSF Beispielskript gestartet werden:

#!/bin/csh
#BSUB -q Batch72
#BSUB -R "mem>500 span[ptile=2]"
#BSUB -o abinit_lsf.log
#BSUB -e abinit_lsf.err
#BSUB -n 2
#BSUB -J ABINIT_parallel
cd $HOME/work/abinit
pwd
date
mpirun -np 2 ./abinip < ./inputfile
date

Diese Zeilen müssen in einer Datei abgespeichert werden - z. B. mit dem Namen start.abinit.lsf - und der parallele LSF Job wird mit dem Kommando

bsub < start.abinit.lsf

gestartet.

Alternativ können die obigen Zeilen in zwei Skripte aufgeteilt werden - Skript 1 für das bsub Kommando und seine Optionen - Skript 2 enthält die auszuführenden Kommandos:

Skript 1: start.abinit.lsfSkript 2: start.abinit
bsub
-q batch72
-R "mem>500 span [ptile=2]"
-o abinit_lsf.log
-e abinit_lsf.err
-n 2
-J ABINIT_parallel
$HOME/start.abinit

cd $HOME/work/abinit
pwd
date
mpirun -np 2 ./abinip < ./inputfile
date


Hinweise:

  • für das Starten eines ABINIT Jobs mit LSF ist das am Anfang dieser Seite aufgeführte Skript namens start.abinit.lsf zu bevorzugen weil sich hier die gesamten LSF Joboptionen und die eigentlichen Kommandos in einer Datei befinden
  • Skript 1 und Skript 2 müssen Ausführungsrechte erhalten:
    chmod 700 start.abinit.lsf
    chmod 700 start.abinit
  • die Angabe der Inputfiles sollte vorzugsweise unter Verwendung des vollen Pfadnamens erfolgen - die $HOME Variable kann im Skript 1 und im Skript 2 verwendet werden
  • Die mit der Option -o und -e angegebenen Output- und Errordateien werden - wenn wie im Beispielskript bezeichnet - in dem Verzeichnis abgelegt aus welchem dieser Job gestartet wird. Wenn diese Logfiles in einem anderem Verzeichnis abgespeichert werden sollen - z. B. im Homeverzeichnis - dann muss der komplette Pfadname angegeben werden - es dürfen dabei keine Umgebungsvariablen wie $HOME verwendet werden; z. B. mit:
    #BSUB -o /usr/wrk/people9/otto/work/abinit/abinit_lsf.out
  • die Option -n 2 gibt die Anzahl der angeforderten CPU- Cores an - zusammen mit der Option span[ptile=2] fordert dieser Job damit von zwei Hosts je zwei CPU Cores an; wird die Option span[ptile=2] nicht verwendet entscheidet LSF über die Verteilung und Auswahl der CPU Cores innerhalb des Clusters - z. B. 1 CPU Core auf Host 1 und 1 CPU Core auf Host 13
  • die Option -mem 500 fordert zum Startzeitpunkt 500 MByte Hauptspeicher (RAM) ueber alle (!) Parallelprozesse (= MPI Threads) an
  • die Option -q Batch72 ordnet diesen Job in die Queue Batch72 ein - und erhaelt eine max. CPU Zeit von 72 h über alle (!) MPI Threads
  • der ABINIT Job ist nach dem Starten noch einige Minuten zu "beobachten" - falsche Settings, die zum Abbruch des Programms führen (kommentiert mit "decision to take exit") - werden am Ende der Ausgabe mit einem Tip zur Reparatur ausgegeben
  • ein Tutorial und weitere Infos zu ABINIT findet man unter www.abinit.org

Parallele Fluentjobs

Parallele Fluentjobs werden auf mehr als einer CPU bzw. einem CPU Core abgearbeitet. 

Der LSF Inputfile namens start.lsf kann folgende Zeilen beinhalten:

#!/bin/csh
#BSUB -q Batch24
#BSUB -R "mem > 1000 && mapacc span[hosts=1]"
#BSUB -oo lsf_fluent.log
#BSUB -eo lsf_fluent.err
#BSUB -J Fluent_Job_parallel
#BSUB -n 8
date
pwd
module purge
module load ansys1/v16
fluent 3ddp -lsf -t$LSB_DJOB_NUMPROC -g < fluent.jou > fluent.log

date

Hinweise

  • dieser Fluentjob wird mit dem Kommando bsub<start.lsf gestartet
  • für den Fluentjob werden acht CPUs bzw. Cores angefordert  - durch die bsub Option #BSUB n 8 und als Option zum Fluent Kommando fluent 3ddp -lsf -t4 ...
  • span[hosts=1] erzwingt das alle Fluentprozesse auf acht Core auf einem Host gestartet werden
  • werden für diesen parallelen Fluentjob user defined function (UDF) verwendet - ist vorher unbedingt das UDF Handbuch zu konsultieren!!!
  • es muss ein Fluent Inputfile namens fluent.jou existieren
  • die mit #BSUB beginnenden Zeilen stellen die Optionen fuer das bsub Kommando dar
  • der Fluent Jornalfile namens fluent.jou hat folgenden Inhalt
    file/read-case-data fluent_input.cas
    solve/initialize initialize
    solve/iterate 10
    file/write-data fluent_output.dat
    exit
    yes
  • dieser Job wird entsprechend den oben verwendeten Optionen in die Queue Batch24 eingeordnet, benötigt mindestens 1000 MB Hauptspeicher und bekommt den Jobnamen "Fluent_Job_parallel"
  • der (LSF) Output wird in eine Datei namens "lsf_fluent.log" geschrieben
  • eventuelle Fehlermeldungen werden in eine Datei namens "lsf_fluent.err" geschrieben
  • die Output- und Errordatei befinden sich in dem Verzeichnis, von dem aus dieser Fluentjob mit dem Kommando bsub < start.lsf gestartet wird

MPI Jobs

MPI Jobs LSF Optionen und Kommandos allgemein gestartet werden:

#!/bin/csh
#BSUB -q BatchXL
#BSUB -n 128
#BSUB -a openmpi
#BSUB -R "mem>1000 span[ptile=32]"
#BSUB -oo mpi_lsf.log
#BSUB -eo MPI_lsf.err
#BSUB -J MPI_Job_LSF
date
pwd

module purge
module load intel/intel_cs_xe_2013sp1
make clean
make
mpirun.lsf ./a.out
date

Hinweise

  • das MPI Binary muss vor dem Starten des Jobs oder wenn möglich wie in diesem Beispiel zu Beginn des Batchjobs übersetzt werden
  • dieser Job wird in der Queue BatchXL eingeordnet
  • die bsub Option -a openmpi zeigt die Verwendung der OpenMPI Implementation an
  • die bsub Option span[ptile=32] erzwingt dass auf einem Knoten mindestens 32 MPI Threads laufen müssen
  • das Batchsystem weist diesem MPI Job die freien Knoten im Cluster zu

Parallele FDTD Jobs

Parallele FDTD Jobs können mit nachfolgenden LSF Beispielskript gestartet werden:

#!/bin/csh
#BSUB -q BatchXL
#BSUB -R "mem>3500 span[hosts=1]"
#BSUB -oo lsf_fdtd.log
#BSUB -eo lsf_fdtd.err
#BSUB -J FDTD_Job
#BSUB -L /bin/csh
#BSUB -n 4,8
date
pwd
module purge
module load lumerical/fdtd/v8
fdtd-run-local.sh  -n $LSB_DJOB_NUMPROC input.fsp
date

Diese Zeilen müssen in einer Datei abgespeichert werden - z. B. mit dem Namen fdtd.lsf - und der parallele LSF Job wird mit dem Kommando

bsub < fdtd.lsf

gestartet. Dieses Beispieljobskript finden Sie unter /usr/app-soft/lumerical/fdtd.lsf

Hinweise:

  • Die mit der Option -oo und -eo angegebenen Output- und Errordateien werden - wenn wie im Beispielskript bezeichnet - in dem Verzeichnis abgelegt aus welchem dieser Job gestartet wird. Mit jedem Jobstart werden dieses error und logfiles überschrieben (overwrite)
  • die Option -n 4,8 gibt die Anzahl der angeforderten CPU- Cores an - hier werden auf einem Computeknoten mindestens vier und maximal acht CPU Cores angefordert
  • mehr der Option span[hosts=1] werden Cores auf einem Computeknoten zugewiesen
  • die Option -mem 3500 fordert zum Startzeitpunkt 3500 MByte freien Hauptspeicher (RAM) auf dem Computeknoten in Sume für alle mit diesem Job verbundenen Prozesse an
  • die Option -q BatchXL ordnet diesem FDTD Job in die Queue BatchXL ein - und erhält eine max. Laufzeit von vier Woche

Gaussian Jobs

#!/bin/csh
#BSUB -q Batch72
#BSUB -R "mem>500 span[ptile=4]"
#BSUB -o gaussian_lsf.log
#BSUB -e gausian_lsf.err
#BSUB -n 4
#BSUB -J Gaussian_parallel
cd $HOME/work/gaussian
pwd
date
setgaussian
g03 < $HOME/work/gaussian
date

queueconfig

Welche Ressourcen benötigt mein Job?

Bevor ein Job auf dem Computeserver ablaufen kann, muß der Nutzer seinen Job hinsichtlich der erforderlichen Ressourcen klassifizieren. Ressourcen können zum Beispiel sein:

  • Interaktiver oder Batchjob
  • gewünschte Maschine
  • gewünschte CPU- Zeit
  • erforderlicher Hauptspeicher
  • Anzahl der Prozessoren

Die für den Job erforderlichen Ressourcen (Jobparameter) werden mit den vorgegebenen Queuekonfigurationen verglichen und damit einer bestimmten Queue zugeordnet.

Die Queues und ihre Konfiguration

In diesem Abschnitt sind alle verfügbaren Queues mit ihren jeweiligen Ressourcen bzw.Parametern aufgeführt. Die Ressourcen einer Queue (Queueparameter) sind:

  • maximale Anzahl der Jobs in dieser Queue
  • maximale Anzahl der Jobs je Nutzer
  • maximale Anzahl der Jobs je Computeserver
  • maximale Laufzeit der Jobs
  • maximale CPU-Zeit (Usertime) der Jobs
  • maximal verfügbarer Hauptspeicher
  • die Namen der verfügbaren Computeserver
  • gewünschte CPU-Zeit
  • maximale Anzahl der Prozessoren

Folgende Queues mit ihren Parametern sind für allgemeine Anwendungen verfügbar:

Queues mit Parametern
QueuenameMax. Anzahl der JobslotsMax. Anzahl der Jobsslots je NutzerMax. Laufzeit
Inter82548 Stunden
InterXL15034 Wochen
Batch241003024 h
Batch721006072 h
BatchXL240018004 Wochen


Für spezielle Applikationen und Nutzer können bei Bedarf zusätzliche Queues eingerichtet werden.

LSF commands

Häufig verwendete LSF-Kommandos

In dem nachfolgenden Abschnitt werden die einzelnen LSF-Kommandos in ihrer grundlegenden Aufgabe erläutert. Soweit nicht angegeben, erhält man tiefergehende Informationen zu dem jeweiligen Kommando über die Man Pages.

Häufig verwendete LSF-Kommandos
lsinfoInformationen zu der LSF- Konfiguration bezüglich Maschinentyp, -bezeichnung, -modell und der vorhandenen Ressourcen
lsmonAusgabe der Belastung (des Loads) aller Rechenknoten
bhostsAnzeige des Status aller Masterhosts
bhosts -lausführliche Ausgabe der Hostparameter
man bhostsAnzeige aller Optionen zum Kommando
bqueuesAnzeige das Queuestatus
bqueues -lausführliche Ausgabe aller Queuparameter
man bqueuesAnzeige aller Optionen zum Kommando
bjobsAnzeige des Jobstatus der eigenen (!) Jobs
bjobs -l Anzeige aller Jobparameter
bjobs -u allAnzeige der Jobs aller Nutzer
bjobs -l 1153Jobinformationen des Jobs mit der JobID 1153
man bjobsAnzeige aller Optionen zum Kommando
bpeek JobIDAnzeige des Joboutputs, also der ASCII- Zeichen, die der Job auf dem Bildschirm ausgibt
bpeek -f JobIDkontinuierliche Ausgabe des Joboutputs (wie tail -f )
man bpeekAnzeige aller Optionen zum Kommando
xlsmonGrafisches Frontend für die Anzeige der Load- Informationen und Ressourcen allerbeteiligten Hosts im CS-Cluster
xbsubGrafische Frontend zum Absetzen eines Jobs
xlsbatchGrafisches Frontend zur Ansicht aller Jobs, Hosts, Queues, Users, Hostgroups