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

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

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 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_serielldate
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 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 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
ansys110 -p aa_t_a < ansys.inp

# mit -p aa_r wird die Ansys Academic Research Lizenz benutzt
ansys110 -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 werden auf einer CPU bzw. einem CPU Core abgearbeitet.

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

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

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

Der LSF Inputfile namens start.lsf beinhaltet folgende Zeilen:

Hinweise

• dieser Comsoljob wird mit dem Kommando bsub<start.lsf gestartet
• dem bsub wird mit der Option "-n 2"die Anzahl der gewünschten CPUs mitgeteilt
• dem Comsol Solver wird mit der Option "-np 2" die Anzahl der zu verwendeten CPUs mitgeteilt - die bsub und die comsol Angaben müssen hinsichtlich der Anzahl der verwendeten CPUs unbedingt übereinstimmen!
• 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 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_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

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:

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 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[ptile=4]"
#BSUB -o lsf_fluent.log
#BSUB -e lsf_fluent.err
#BSUB -J Fluent_Job_parallel
#BSUB -n 4
date
cd $HOME/work/fluent
pwd
setfluent
fluent 3ddp -lsf -t4 -ssh -g < fluent.jou > fluent.log

Hinweise

• dieser Fluentjob wird mit dem Kommando bsub<start.lsf gestartet
• für den Fluentjob werden vier CPUs bzw. Cores angefordert  - durch die bsub Option #BSUB n 4 und als Option zum Fluent Kommando fluent 3ddp -lsf -t4 ...
• span[ptile=4] erzwingt das mindestens vier Fluentprozesse auf vier Core auf einem Host gestartet werden - span[ptile=2] erzwingt dass mindestens zwei Fluentprozesse 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_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

MPI Jobs LSF Optionen und Kommandos allgemein gestartet werden:

#!/bin/csh
#BSUB -q Batch24
#BSUB -n 4
#BSUB -a openmpi
#BSUB -R "mem>1000 span[ptile=4]"
#BSUB -o mpi_lsf.log
#BSUB -e MPI_lsf.err
#BSUB -J MPI_Job_LSF
date
pwd


mpirun.lsf ./a.out
date

Hinweise

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

Parallele MPI basierende LAMMPS Jobs können mit nachfolgenden LSF Beispielskript gestartet werden:

#!/bin/csh
#BSUB -q Batch72
#BSUB -R "mem>500 span[ptile=2]"
#BSUB -o lammps_lsf.log
#BSUB -e lammps_lsf.err
#BSUB -n 4
#BSUB -a mpichp4
#BSUB -J LAMMPS_parallel
cd $HOME/work/lammps
pwd
date
setlammps
pam -g mpich4_wrapper lmp_g++ < $HOME/work/lammps/in.lj
date

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

bsub < start.lammps.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:

Hinweise:

• Skript 1 und Skript 2 müssen Ausführungsrechte erhalten:
  chmod 700 start.lammps.lsf
  chmod 700 start.lammps
• 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/lammps/lammps_lsf.out
• die Option -n 4 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 3 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
• die Option -a mpichp4 gibt an dass man dass Lammps unter Verwendung das MPICH Distribution starten möchte - dieses MPICH ist auf jedem Knoten im Cluster im Verzeichnis /usr/app-soft/mpich.ch_p4 installiert
• mit pam wird innerhalb von LSF der parallel application manager bezeichnet - der pam startet und kontrolliert alle zu diesem Job zugehörigen MPI Threads

#!/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