https://itp.tugraz.at/wiki/api.php?action=feedcontributions&user=Cheil&feedformat=atomPhysik - Benutzerbeiträge [de-at]2024-03-29T05:32:39ZBenutzerbeiträgeMediaWiki 1.34.2https://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7465HTCondor2010-07-16T09:44:21Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Programme, die mit den Matlabversionen 2008 und aktueller kompiliert wurden brauchen bei den ''Requirements'' den Zusatz ''MatlabVersion == "R2009b"'', da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/<username>/bh_disorder_mott_function/temp;MATLAB_PREFDIR=/temp/<username>/bh_disorder_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/<username>/bh_disorder_mott_function/distrib/error<br />
log = /temp/<username>/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7464HTCondor2010-07-16T09:41:26Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Programme, die mit den Matlabversionen 2008 und aktueller kompiliert wurden brauchen bei den ''Requirements'' den Zusatz ''MatlabVersion == "R2009b"'', da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7463HTCondor2010-07-16T09:39:51Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Programme, die mit den Matlabversionen 2008 und aktueller kompiliert wurden brauchen bei den ''Requirements'' den Zusatz ''MatlabVersion == "R2009b"'', da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7462HTCondor2010-07-16T09:39:26Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Programme, die mit den Matlabversionen 2008 und aktueller kompiliert wurden brauchen bei den ''Requirements'' den Zusatz ''MatlabVersion == "R2009b"'', da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7461HTCondor2010-07-16T09:39:05Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Programme, die mit den Versionen 2008 und aktueller kompiliert wurden brauchen bei den ''Requirements'' den Zusatz ''MatlabVersion == "R2009b"'', da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7460HTCondor2010-07-16T08:55:13Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
Requirements = MatlabVersion == "R2009b"<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7459HTCondor2010-07-14T09:48:43Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7458HTCondor2010-07-14T09:48:25Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7457HTCondor2010-07-14T09:47:40Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.:<br />
<br />
if ischar(parameter) == 1<br />
parameter = str2double(parameter); % bzw. str2num(parameter)<br />
end<br />
<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7456HTCondor2010-07-14T06:18:28Z<p>Cheil: </p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt.<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp;LD_LIBRARY_PATH=/afs/itp.tugraz.at/opt/matlab/<br />
R2009/runtime/glnx86<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7455HTCondor2010-07-13T16:03:15Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgeben würde, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt.<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp;LD_LIBRARY_PATH=/afs/itp.tugraz.at/opt/matlab/<br />
R2009/runtime/glnx86<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7454HTCondor2010-07-13T16:02:44Z<p>Cheil: /* Matlab-Programme unter Condor */</p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgeben würde, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt.<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp;LD_LIBRARY_PATH=/afs/itp.tugraz.at/opt/matlab/<br />
R2009/runtime/glnx86<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7453HTCondor2010-07-13T15:34:58Z<p>Cheil: </p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. Die ''environment''-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler ''Could not access the MCR component cache'' auftreten. In diesem Fall muss man dann den Ort für ''MCR_CACHE_ROOT'' per Hand festlegen.<br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgeben würde, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt.<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp;LD_LIBRARY_PATH=/afs/itp.tugraz.at/opt/matlab/<br />
R2009/runtime/glnx86<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=HTCondor&diff=7452HTCondor2010-07-13T15:30:49Z<p>Cheil: </p>
<hr />
<div>= Was ist Condor? =<br />
<br />
[http://www.cs.wisc.edu/condor/ Condor] ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. Condor unterstützt das ''High Throughput Computing'' (HTC), das im Gegensatz zum ''High Performance Computing'' (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.<br />
<br />
Weitere Informationen finden Sie in einem [http://itp.tugraz.at/~ahi/Uni/AppSoft/HTC/ älteren Artikel].<br />
<br />
Wir haben die nötigen Libraries fürs ''High Performance Computing'' zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die [http://www.zid.tugraz.at/cs/support/nic/nic.html dedizierten Cluster] des [http://www.zid.tugraz.at/ Zentralen Informatikdienstes].<br />
<br />
<br />
<br />
= Benutzung =<br />
<br />
Die wichtigsten Befehle sind:<br />
<br />
* condor_status - Status der Rechner im Condor-Pool<br />
* condor_submit - Starten von Batchjobs<br />
* condor_q -global - Anzeige der laufenden bzw. wartenden Programme<br />
<br />
Leider haben nicht alle Programme der Condor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette [http://www.cs.wisc.edu/condor/manual/v6.6/ Dokumentation im Internet] - dort gibt es auch das empfehlenswerte Tutorial [http://www.cs.wisc.edu/~roy/effective_condor/ Using Condor Effectively].<br />
<br />
Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von etwa 10 Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und der File-Server bei kurzen Programmlaufzeiten wesentlich belastet wird. <br />
<br />
== Zugriff auf das Homedirectory ==<br />
<br />
Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum [[AFS]] daher nicht "erben" können. Wir haben daher einige Ergänzungen zu den [[Homedirectories#Ausweichmöglichkeiten]] vorgenommen:<br />
<br />
* /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem NFS-Server und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.<br />
* /lager/ funktioniert ähnlich wie /temp/; allerdings sind nur wenige Benutzer berechtigt, dort Daten zu speichern. Den Grund für die Einführung von /lager/ war die permanente Überlastung des Fileserver für /temp/ durch unvorsichtige Benutzer.<br />
<br />
== Effiziente Programme ==<br />
<br />
Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:<br />
<br />
; unpassende Algorithmen : sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes. <br />
<br />
; Swappen : Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS. <br />
<br />
; Überlastung der File-Server: Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:<br />
<br />
:: Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde. <br />
<br />
:: Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden. <br />
<br />
:Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.<br />
<br />
== Obskure Fehlermeldung: Shadow exception! ==<br />
<br />
Manchmal tritt die Fehlermeldung<br />
<br />
Shadow exception!<br />
Can no longer talk to condor_starter on execute machine (129.27.xx.xx) <br />
<br />
auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.<br />
<br />
Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste [http://www.cs.wisc.edu/~lists/archive/condor-users/msg00007.html condor users].<br />
<br />
<br />
== Fehlersuche ==<br />
<br />
Wenn Programme unter Condor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.<br />
<br />
<br />
<br />
= Matlab-Programme unter Condor =<br />
<br />
Wenn [[Matlab]]-Programme unter Condor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem [http://itp.tugraz.at/Comp/Stat_LICENSE/ Pool] der TU Graz. Daher müßen [[Matlab]]-Skripte unbedingt kompiliert werden.<br />
<br />
Damit das erzeugte Binary dann unter Condor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig: <br />
<br />
Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt: <br />
<br />
* Unser ausführbares Programm heißt ''bh_disorder_mott_function'' und das dazugehörige Shell-Skript ''run_bh_disorder_mott_function.sh''. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss ''Getenv = True'' gesetzt werden. <br />
<br />
* Ein sehr wichtiger Punkt ist, dass man ''transfer_files = always'' setzt. Das erste Argument von ''transfer_input_files'' muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall ''bh_disorder_mott_function''. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. ''mott_4_2.mat'')<br />
<br />
* Als ''Input'' wird nun wieder die ausführbare Matlab-Datei angegeben, der ''Output'' ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgeben würde, würde sie in Matlab ausgeführt werden. Die Befehle für die ''error''- und ''log''-files sind wie ''Output'' frei wählbar.<br />
<br />
* Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also ''/afs/itp.tugraz.at/opt/matlab''. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.<br />
<br />
'''Achtung:''' Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt.<br />
<br />
* Zum Schluss wird mit ''queue 1'' der Prozess einmal eingereiht.<br />
<br />
################### <br />
#<br />
# Bose-Hubbard with disorder, test<br />
# <br />
#################### <br />
<br />
Universe = vanilla <br />
Executable = run_bh_disorder_mott_function.sh<br />
<br />
Getenv = True<br />
environment = MCR_CACHE_ROOT=/temp/cheil/bh_diagrams_mott_function/temp;MATLAB_PREFDIR=/temp/cheil/bh_diagrams_mott_function/temp;LD_LIBRARY_PATH=/afs/itp.tugraz.at/opt/matlab/<br />
R2009/runtime/glnx86<br />
<br />
#Requirements = Memory >= 300<br />
#Rank = (Arch =="X86_64")<br />
<br />
transfer_files = always<br />
transfer_input_files = bh_disorder_mott_function,mott_4_2.mat<br />
<br />
Input = bh_disorder_mott_function<br />
Output = out.$(Process)<br />
<br />
<br />
error = /temp/cheil/bh_disorder_mott_function/distrib/error<br />
log = /temp/cheil/bh_disorder_mott_function/distrib/log<br />
<br />
<br />
Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2<br />
queue 1<br />
<br />
<br />
<br />
Weblinks: <br />
<br />
*[http://www.lehigh.edu/computing/hpc/running/condor_matlab.html Lehigh university: High Performance Computing: Condor for Matlab]<br />
*[http://www.liv.ac.uk/csd/escience/condor/matlab/ http://www.liv.ac.uk/csd/escience/condor/matlab/]<br />
*[http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor http://wiki.rcs.manchester.ac.uk/community/MatlabWithCondor]]<br />
<br />
= Alternativen =<br />
<br />
Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.<br />
<br />
Einige mögliche Konkurrenzprodukte zu Condor sind:<br />
<br />
* [http://www.llnl.gov/linux/slurm/ SLURM (Simple Linux Utility for Resource Management)] im Kombination mit dem [http://www.clusterresources.com/pages/products/maui-cluster-scheduler.php Maui Cluster Scheduler] <br />
** eher auf parallele Jobs ausgerichtet, sollte unser Anforderungen aber im wesentlichen erfüllen können<br />
** kein integriertes Checkpointing<br />
* [http://gridengine.sunsource.net/ Sun Grid Engine] - wesentlich komplizierter als andere Lösungen<br />
* [http://www.gnu.org/software/queue/ GNU Queue] - das Projekt ist weitgehend eingeschlafen</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Erkennen_topologisch_identer_Pfade_bei_H%C3%BCpfprozessen_in_einem_regelm%C3%A4%C3%9Figen_Gitter&diff=6835Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter2010-02-28T10:45:43Z<p>Cheil: </p>
<hr />
<div>==Kurzbeschreibung==<br />
Ziel dieses Projektes ist es, ein Programm zu entwickeln, das alle möglichen, topologisch einmaligen Pfade auf einem zwei- bzw. dreidimensionalen, regelmäßigen Gitter generiert, um die Hüpfprozesse von bosonischen Teilchen diagrammatisch darzustellen.<br />
<br />
Es wurden zwei Arten dieses Programmes entwickelt:<br />
*Generieren aller möglichen geschlossenen Pfade<br />
*Generieren aller möglichen offenen Pfade mit einer Teilchenquelle und einer Teilchensenke</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Erkennen_topologisch_identer_Pfade_bei_H%C3%BCpfprozessen_in_einem_regelm%C3%A4%C3%9Figen_Gitter&diff=6834Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter2010-02-28T10:35:44Z<p>Cheil: </p>
<hr />
<div>Ziel dieses Projektes ist es, ein Programm zu entwickeln, das alle möglichen, topologisch einmaligen Pfade auf einem zwei- bzw. dreidimensionalen, regelmäßigen Gitter generiert, um die Hüpfprozesse von bosonischen Teilchen diagrammatisch darzustellen.<br />
<br />
Es wurden zwei Arten dieses Programmes entwickelt:<br />
*Generieren aller möglichen geschlossenen Pfade<br />
*Generieren aller möglichen offenen Pfade mit einer Teilchenquelle und einer Teilchensenke</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Erkennen_topologisch_identer_Pfade_bei_H%C3%BCpfprozessen_in_einem_regelm%C3%A4%C3%9Figen_Gitter&diff=6833Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter2010-02-28T10:33:42Z<p>Cheil: </p>
<hr />
<div>Ziel dieses Projektes ist es, ein Programm zu entwickeln, das alle möglichen, topologisch einmaligen Pfade auf einem zwei- bzw. dreidimensionalen, regelmäßigen Gitter generiert, um die Hüpfprozesse von bosonischen Teilchen diagrammatisch darzustellen.<br />
<br />
Es wurden zwei Arten dieses Programmes entwickelt:\\<br />
Generieren aller möglichen geschlossenen Pfade<br />
Generieren aller möglichen offenen Pfade mit einer Teilchenquelle und einer Teilchensenke</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Erkennen_topologisch_identer_Pfade_bei_H%C3%BCpfprozessen_in_einem_regelm%C3%A4%C3%9Figen_Gitter&diff=6832Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter2010-02-28T10:28:00Z<p>Cheil: New page: Ziel dieses Projektes ist es, ein Programm zu entwickeln, das alle möglichen, topologisch einmaligen Pfade auf einem zwei- bzw. dreidimensionalen, regelmäßigen Gitter generiert, um die ...</p>
<hr />
<div>Ziel dieses Projektes ist es, ein Programm zu entwickeln, das alle möglichen, topologisch einmaligen Pfade auf einem zwei- bzw. dreidimensionalen, regelmäßigen Gitter generiert, um die Hüpfprozesse von bosonischen Teilchen diagrammatisch darzustellen.<br />
<br />
Es wurden zwei Arten dieses Programmes entwickelt:<br />
Generieren aller möglichen geschlossenen Pfade<br />
Generieren aller möglichen offenen Pfade mit einer Teilchenquelle und einer Teilchensenke</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Applikationssoftware_-_Projekte&diff=6831Applikationssoftware - Projekte2010-02-28T10:21:34Z<p>Cheil: /* Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter, Heil Christoph */</p>
<hr />
<div>Hier gibt es Links zu verschiedenen Projekten aus Applikationssoftware und Programmierung und auch aus Applikationssoftware für Fortgeschrittene.<br />
<br />
== Applikationssoftware für Fortgeschrittene - 2010 ==<br />
<br />
Bitte hier Überschrift erstellen und Seitentitel wählen. Nach dem Speichern ist ihr jeweiliger Link rot. Mit diesem Link können sie dann ihre Seite erstellen. Zum Editieren dieser Seite muss man sich anmelden (siehe rechts oben). <br />
<br />
=== simEdit - GUI zur Erstellung von Input-Dateien für das MD software-package ''modelMD'', Bukovnik Gernot ===<br />
<br />
[[Projektseite]]<br />
<br />
=== Face Detection and Face Recognition, Kraus Patrick and Mayrhofer-R. Michael ===<br />
<br />
[[Introduction to Face Detection and Face Recognition]]<br />
<br />
[[Face Detection]]<br />
<br />
[[Face Recognition]]<br />
<br />
=== Einbindung von C - Files in MatLab, Lang Klaus ===<br />
<br />
[[Einbindung von C - Files in MatLab]]<br />
<br />
=== Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter, Heil Christoph ===<br />
<br />
[[Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter]]<br />
<br />
=== Approximationen (empty lattice, nearly free electron) der Elektronendispersionsrelation in beliebigen 3D Kristallgittern, Thaler Philipp ===<br />
<br />
[[Darstellung 3-dimensionaler Gitter]]<br />
<br />
[[Brillouinzone und Wigner-Seitz-Zelle]]<br />
<br />
[[Dispersionsrelation]]<br />
<br />
=== Selbstständig lernender Algorithmus, Kapper Gernot, Volk Alexander ===<br />
[[Selbstständig lernender Algorithmus]]<br />
<br />
=== Projekt, Name Vorname ===<br />
<br />
[[Projektseite]]<br />
<br />
== Verschiedene alte Projekte ==<br />
<br />
[[RLC-Serienschwingkreis]]<br />
<br />
[[Teilchenbahn im Magnetfeld]]<br />
<br />
[[Trassierungsdetektion bei Schienenfahrzeugen]]<br />
<br />
[[Numerische Simulation einer Antenne]]<br />
<br />
[[Vielteilchensimulation mit anziehenden Kräften zwischen den Teilchen]]<br />
<br />
[[Hydraulisches Modul]]<br />
<br />
[[Simulation unseres Sonnensystems]]<br />
<br />
[[Simulation der Flugbahn eines Geschosses]]<br />
<br />
[[Simulation einer Rakete]]<br />
<br />
[[Wellenausbreitung]]<br />
<br />
[[Verschlüsselung]]<br />
<br />
[[Simulation von Teilchenbewegungen SvT, by GSA]]<br />
<br />
[[Matlab Bingo]]<br />
<br />
[[Gravity Simulation]]<br />
<br />
[[FTIR-Spektroskopie (FTIR=FourierTransformationsInfraRot)]]<br />
<br />
[[Lindenmayer-Systeme]]<br />
<br />
[[Partikelschwarmoptimierung in Python]]<br />
<br />
[[Fraktale Landschaften]]<br />
<br />
[[Matlab-steuerung externer Komponenten (zB. Schrittmotoren) mit RS232]]</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Applikationssoftware_-_Projekte&diff=6780Applikationssoftware - Projekte2010-02-25T09:33:25Z<p>Cheil: </p>
<hr />
<div>Hier gibt es Links zu verschiedenen Projekten aus Applikationssoftware und Programmierung und auch aus Applikationssoftware für Fortgeschrittene.<br />
<br />
== Applikationssoftware für Fortgeschrittene - 2010 ==<br />
<br />
Bitte hier Überschrift erstellen und Seitentitel wählen. Nach dem Speichern ist ihr jeweiliger Link rot. Mit diesem Link können sie dann ihre Seite erstellen. Zum Editieren dieser Seite muss man sich anmelden (siehe rechts oben). <br />
<br />
=== simEdit - GUI zur Erstellung von Input-Dateien für das MD software-package ''modelMD'', Bukovnik Gernot ===<br />
<br />
[[Projektseite]]<br />
<br />
=== Face Detection and Face Recognition, Kraus Patrick and Mayrhofer-R. Michael ===<br />
<br />
[[Introduction to Face Detection and Face Recognition]]<br />
<br />
[[Face Detection]]<br />
<br />
[[Face Recognition]]<br />
<br />
=== Einbindung von C - Files in MatLab, Lang Klaus ===<br />
<br />
[[Einbindung von C - Files in MatLab]]<br />
<br />
=== Erkennen topologisch identer Pfade bei Hüpfprozessen in einem regelmäßigen Gitter, Heil Christoph ===<br />
<br />
[[Projektseite]]<br />
<br />
=== Projekt, Name Vorname ===<br />
<br />
[[Projektseite]]<br />
<br />
== Verschiedene alte Projekte ==<br />
<br />
[[RLC-Serienschwingkreis]]<br />
<br />
[[Teilchenbahn im Magnetfeld]]<br />
<br />
[[Trassierungsdetektion bei Schienenfahrzeugen]]<br />
<br />
[[Numerische Simulation einer Antenne]]<br />
<br />
[[Vielteilchensimulation mit anziehenden Kräften zwischen den Teilchen]]<br />
<br />
[[Hydraulisches Modul]]<br />
<br />
[[Simulation unseres Sonnensystems]]<br />
<br />
[[Simulation der Flugbahn eines Geschosses]]<br />
<br />
[[Simulation einer Rakete]]<br />
<br />
[[Wellenausbreitung]]<br />
<br />
[[Verschlüsselung]]<br />
<br />
[[Simulation von Teilchenbewegungen SvT, by GSA]]<br />
<br />
[[Matlab Bingo]]<br />
<br />
[[Gravity Simulation]]<br />
<br />
[[FTIR-Spektroskopie (FTIR=FourierTransformationsInfraRot)]]<br />
<br />
[[Lindenmayer-Systeme]]<br />
<br />
[[Partikelschwarmoptimierung in Python]]<br />
<br />
[[Fraktale Landschaften]]<br />
<br />
[[Matlab-steuerung externer Komponenten (zB. Schrittmotoren) mit RS232]]</div>Cheilhttps://itp.tugraz.at/wiki/index.php?title=Matlab_Sudoku&diff=4623Matlab Sudoku2006-05-28T18:51:11Z<p>Cheil: /* Involvierte Personen */</p>
<hr />
<div>== Inhalt == <br />
Ziel des Projektes ist die Erstellung eines Lösungsprogramms für Sudokus belieber Größe, z.B. 9x9 oder 16x16, und beliebigen Schwierigkeitsgrades. Dazu werden eine Reihe von Hilfsroutinen und ein Lösungsprogramm benötigt.<br />
<br />
Für alle Teile gibt es Vorgaben, Anregungen und Tipps wie ich es gemacht habe. Sie werden heir im Wiki und im MLTutor zur Verfügung stehen. Ich brauche dafür aber noch sicher die nächste Woche.<br />
<br />
Eine Beschreibung, was Sudokus sind, findet man unter [http://de.wikipedia.org/wiki/Sudoku].<br />
<br />
== Schwierigkeit ==<br />
Das Problem ist ideal für Matlab, setzt aber gute Kenntnisse der Sprache voraus. Im Prinzip reicht sicher der Inhalt der ersten sechs Übungen, man muss aber die Syntax und die logischen Zusammenhänge gut beherschen. Die Aufgabe ist also auf keinen Fall leicht und stellt durchaus hohe Anforderungen an die Teilnehmer.<br />
<br />
== Ziel ==<br />
Ziel ist die Lösung des Problems unter vorwiegender Verwendung von Array-Operationen in Matlab. D.h., die Verrwendung von for-Schleifen sollte so weit als möglich vermieden werden. Sie sind aber schonerlaubt, wenn man etwas niicht anders lösen kann oder keine andere Idee hat. Typischerweise werden die Programme langsamer, wenn man zu viele Schleifen verwendet. Die Programmstruktur mit einigen Hilfsprogrammen und einem rekursiven Lösungsprogramm wie ich es geschrieben habe, gibt es weiter unten. Ihr müsst und sollt euch nichtt sklavisch daran halten. Man kann von den Tipps etwas lernen bzw. sehen, wie eine Strategie aussehen kann, es muss aber nicht so gemacht werden. Oft gibt es viele Möglichkeiten und wir können sie ja am Ende bei einer Sudoku-Party vergleichen. <br />
<br />
== Prüfung ==<br />
Die Teilnehmer erledigen mit der Fertigstellung des Projektes einen Großteil der Verpflichtungen für die Prüfung. Es sollte nur mehr eine viel kleinere Ergänzung über Pfingsten geben. Man kann sich also damit die Teilnahme an der Übunsgklausur ersparen.<br />
<br />
Die Lösungen können durchaus zwischen den Teilnehmern besprochen und diskutiert werden, es sollte aber jeder seine Variante abliefern, die er dann auch genau erklären kann. Es gibt also kein Problem mit Zusammenarbeit. Kopierversuche von Personen, die es nicht selbst machen können, sollten aber von den Teilnehmern verhindert werden. Ich persönlich hätte dafür kein Verständnis und würde derartige Angebote für Prüfungen nicht mehr anbieten.<br />
<br />
== Involvierte Personen ==<br />
Hier kann sich jeder Teilnehmer leicht eintragen. Man braucht sich nur im Wiki anmelden (rechts oben) und den File editieren. Die Syntax ist extrem einfach.<br />
<br />
* Leiter:<br />
** [mailto:winfried.kernbichler@tugraz.at| Winfried Kernbichler]<br />
* Teilnehmer:<br />
** [mailto:student@student.tugraz.at| Vorname Nachname]<br />
** [mailto:christian.straka@student.tugraz.at| Christian Straka]<br />
** [mailto:cheil@sbox.tugraz.at| Christoph Heil]<br />
** [mailto:hetzelr@sbox.tugraz.at| Reinhold Hetzel]<br />
** [mailto:sebastian.nau@student.tugraz.at| Sebastian Nau]<br />
** [mailto:joao@sbox.tugraz.at| Rudolf Werber]<br />
** [mailto:a_dorda@sbox.tugraz.at| Antonius Dorda]<br />
** [mailto:krausp@sbox.tugraz.at| Kraus Patrick]<br />
** [mailto:mmr@sbox.tugraz.at| Mayrhofer - R. Michael]<br />
** [mailto:hoerz@sbox.tugraz.at| Hörzinger Michael]<br />
** [mailto:pedross@sbox.tugraz.at| Andreas Pedroß]<br />
** [mailto:oswaldst@sbox.tugraz.at| Stefan Oswald]<br />
** [mailto:davidl86@sbox.tugraz.at| David Love]<br />
** [mailto:krugm@sbox.tugraz.at| Markus Krug]<br />
<br />
== Matlab Programme zur Lösung des Problems ==<br />
Hier gibt es den Hilfetext meiner Routinen und Anmerkungen wieso und warum ich sie gemacht habe. Es gliedert sich in Hilfsroutinen und den eigenlichen Solver.<br />
<br />
=== Grundlagen ===<br />
<br />
In der hier gewählten Darstellung ist ein Sudoku ein <math>(n^2 \times n^2)</math>-Feld mit Zahlen zwischen 1 und <math>n^2</math>. An jenen Stellen, wo Zahlen gesetzt werden müssen steht eine Null. In jeder Zeile (row), in jeder Spalte (column) und in jedem Block (sub-square) darf eine Zahl nur einmal vorkommen.<br />
<br />
=== Hilfsroutinen ===<br />
<br />
==== sudoku_sub ====<br />
Dies ist eine Routine, die für beliebige Positionen in einem Sudoku die entsprechende Nummer des Blockes berechnet.<br />
function loc = sudoku_sub(n,iz,is) <br />
%<br />
% loc = sudoku_sub(n,iz,is)<br />
%<br />
% Computes the number of the local sub-square of the Sudoku from the row <br />
% indices iz and the column indices of the Sudoku.<br />
%<br />
% Input:<br />
% <br />
% n : size of a subsquare of a Sudoku, 3 for (9 x 9) or 4 for (16 x 16)<br />
% iz, is : row and column indices in arrays of same size<br />
%<br />
% Output:<br />
%<br />
% loc : numbers of local sub-squares for positions iz and is<br />
% array with same size as arrays iz and is<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
Die Nummerierung der Blöcke ist wie bei Matlab üblich zuerst entlang der Zeilen und dann entlang der Spalten. In einem (n=3)-Sudoku gibt es neun Blöcke:<br />
1 4 7<br />
2 5 8<br />
3 6 9 <br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/ind2sub.html ind2sub], [http://itp.tugraz.at/matlab/techdoc/ref/sub2ind.html sub2ind] und [http://itp.tugraz.at/matlab/techdoc/ref/ceil.html ceil]<br />
<br />
Typisches Resultat:<br />
loc = sudoku_sub(3,[1,4,4],[2,4,8])<br />
loc = <br />
1 5 8<br />
<br />
==== sudoku_loc ====<br />
Dieses Programm soll eine Matrix SI erzeugen, die in jeder Zeile die einfachen Indices des entsprechenden Blockes enthält.<br />
function SI = sudoku_loc(n)<br />
%<br />
% SI = sudoku_loc(n)<br />
%<br />
% Computes an (n^2 x n^2)-array where each line contains the<br />
% single indices of the local sub-square of the Sudoku.<br />
% <br />
% Input:<br />
%<br />
% n : size of the Sudoko; 3 for (9 x 9), 4 for (16 x 16), ... <br />
%<br />
% Output:<br />
% <br />
% SI : (n^2 x n^2)-array where each row holds the single indices of the<br />
% positions in the pertinent local sub-square<br />
%<br />
% Sub-squares are numbered as follows (here for (n=3)-Sudoku (9 x 9)<br />
%<br />
% 1 4 7<br />
% 2 5 8<br />
% 3 6 9<br />
%<br />
% where each number represents a (n x n)-square. All single indices of<br />
% positions belonging to the first sub-square are in line one of SI, and so <br />
% on. <br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
Ein typisches Resultat lautet<br />
SI = sudoku_loc(3)<br />
SI =<br />
1 2 3 10 11 12 19 20 21<br />
4 5 6 13 14 15 22 23 24<br />
7 8 9 16 17 18 25 26 27<br />
28 29 30 37 38 39 46 47 48<br />
31 32 33 40 41 42 49 50 51<br />
34 35 36 43 44 45 52 53 54<br />
55 56 57 64 65 66 73 74 75<br />
58 59 60 67 68 69 76 77 78<br />
61 62 63 70 71 72 79 80 81<br />
d.h., in der ersten Zeile stehen nun die Indices der neun Positionen des ersten Blocks, usw..<br />
<br />
Dies ist extrem praktisch, da man jedes Sudoku mit S(SI) damit so umsortieren kann, dass die Werte in den einzelnen Blöcken nun in einzelnen Zeilen stehen.<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/colon.html colon], [http://itp.tugraz.at/matlab/techdoc/ref/reshape.html reshape], [http://itp.tugraz.at/matlab/techdoc/ref/repmat.html repmat], [http://itp.tugraz.at/matlab/techdoc/ref/ceil.html ceil], [http://itp.tugraz.at/matlab/techdoc/ref/sub2ind.html sub2ind], [http://itp.tugraz.at/matlab/techdoc/ref/transpose.html transpose].<br />
<br />
Die Strategie von mir war, einen Vektor der Zeilenindices der Blöcke zu erzeugen, hier am Beispiel (n=2):<br />
erster zweiter dritter vierter Block<br />
1 2 1 2 3 4 3 4 1 2 1 2 3 4 3 4<br />
und danach eine Vektor der Spaltenindices der Blöcke<br />
erster zweiter dritter vierter Block<br />
1 1 2 2 1 1 2 2 3 3 4 4 3 3 4 4<br />
und diese dann mit [http://itp.tugraz.at/matlab/techdoc/ref/sub2ind.html sub2ind] umzurechnen und entsprechend darzustellen. <br />
1 2 5 6<br />
3 4 7 8<br />
9 10 13 14<br />
11 12 15 16<br />
<br />
==== sudoku_all_possible ====<br />
Das Ziel hier ist für ein beliebiges Sudoku ein dreidimensionales logisches Feld zu erstellen, das bei jeder Position (Zeile, Spalte) in der dritten Dimension an jenen Stellen einen Einser stehen hat, wo die entspechende Zahl im Sudoku noch gesetzt werden kann.<br />
<br />
Stellen sie sich vor an der Position (5,4) können noch die Zahlen 1,4,5, 8 und 9 gesetzt werden, dann soll der Inhalt der logischen Matrix an dieser Stelle so aussehen:<br />
L(5,4,:) -> 1,0,0,1,1,0,0,1,1<br />
DIes soll für die gesamte Matrix gelten. Wenn die Stelle schon besetzt ist, bzw. wenn man dort nichts setzen kann, sollen alle Werte in der dritten Dimension Null sein.<br />
function L = sudoku_all_possible(S,SI)<br />
%<br />
% L = sudoku_all_possible(S,SI)<br />
% <br />
% computes a logical (n^2 x n^2 x n^2)-array L where n^2 in a (9 x 9)-Sudoku<br />
% is 9. Such a Sudoku is called a (n=3)-Sudoku. <br />
% <br />
% At a positions L(ir,ic,:) those values are 1 where the<br />
% corresponding value could be placed in the Sudoku<br />
%<br />
% e.g.: if the number [2,3,5,7] can be placed at S(3,2) <br />
% in a (n=3)-Sudoku, then<br />
% L(3,2,:) is [0,1,1,0,1,0,1,0,0]<br />
%<br />
% Input:<br />
%<br />
% S : present representation of the Sudoku, (n^2 x n^2)-array<br />
%<br />
% Optional Input:<br />
%<br />
% SI : single indices of the local sub-square of the Sudoku produced by <br />
% sudoku_loc (see sudoku_loc for an explanation).<br />
% if not in the input sudoku_loc should be called to produce SI<br />
%<br />
% Output:<br />
%<br />
% L : logical (n^2 x n^2 x n^2)-array<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/logical.html logical], [http://itp.tugraz.at/matlab/techdoc/ref/zeros.html zeros], [http://itp.tugraz.at/matlab/techdoc/ref/ones.html ones], [http://itp.tugraz.at/matlab/techdoc/ref/find.html find], [http://itp.tugraz.at/matlab/techdoc/ref/sub2ind.html sub2ind], [http://itp.tugraz.at/matlab/techdoc/ref/repmat.html repmat], [http://itp.tugraz.at/matlab/techdoc/ref/reshape.html reshape], [http://itp.tugraz.at/matlab/techdoc/ref/logicaloperatorselementwise.html logische Operatoren], [http://itp.tugraz.at/matlab/techdoc/ref/relationaloperators.html Vergleichsoperatoren].<br />
<br />
Strategie: Die von mir verwendete Strategie war intern vier solche 3D-Felder zu erzeugen, für die Zahlen in den Zeilen, in den Spalten, in den Blöcken und wo man überhaupt noch setzen kann. Diese vier Felder werden dann mit [http://itp.tugraz.at/matlab/techdoc/ref/and.html and] verknüpft. Zur Umwandlung von Zahlenwerten in Feldern in logische Einsen in einem anderen Feld, habe ich ein kleines Beispiel zur Erläuterung geschrieben [http://itp.tugraz.at/LV/kernbich/AppSoft-1/Uebung/Sudoku/test_ex1.m].<br />
<br />
==== sudoku_best_possible ====<br />
Dieses Programm soll nun unter Verwendung der logischen dreidimensionalen Matrix die beste Position und dei möglichen Werte liefern.<br />
function [iz,is,val,status] = sudoku_best_possible(S,L)<br />
%<br />
% [iz,is,val,status] = sudoku_best_possible(S,L)<br />
%<br />
% gives the best possible position (imz,ims) where to place the next <br />
% number (val) in the Sudoku.<br />
%<br />
% Input:<br />
%<br />
% S : Sudoku array with size (n^2 x n^2)<br />
% L : logical array produced by sudoku_all_possible or modified by<br />
% sudoku_set with size (n^2 x n^2 x n^2)<br />
%<br />
% Output:<br />
%<br />
% iz, is : position for best placement chosen because of:<br />
% (1) minimum number possibilities<br />
% (2) first along single dimension in S<br />
% val : possible values to be placed at (iz,is) given in a column vector<br />
% status : logical status variable<br />
% 1 if a location is found where to place a new number out of val<br />
% 0 if no location is found or if at any free position no value can <br />
% be placed<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/logical.html logical], [http://itp.tugraz.at/matlab/techdoc/ref/sum.html sum], [http://itp.tugraz.at/matlab/techdoc/ref/any.html any], [http://itp.tugraz.at/matlab/techdoc/ref/all.html all], [http://itp.tugraz.at/matlab/techdoc/ref/min.html min], [http://itp.tugraz.at/matlab/techdoc/ref/ind2sub.html ind2sub], [http://itp.tugraz.at/matlab/techdoc/ref/find.html find], [http://itp.tugraz.at/matlab/techdoc/ref/nan.html nan], [http://itp.tugraz.at/matlab/techdoc/ref/logicaloperatorselementwise.html logische Operatoren], [http://itp.tugraz.at/matlab/techdoc/ref/relationaloperators.html Vergleichsoperatoren].<br />
<br />
Strategie: Mit der Summation über die dritte Dimension im logischen Feld L sieht man sofort, ob man nicht mehr setzen kann. Mit Hilfe des Befehls [http://itp.tugraz.at/matlab/techdoc/ref/min.html min] findet man auch sofort die Positionen, wo man noch die geringste Anzahl von Möglichkeiten hat. Davon wählt man die erste aus. Bei der Suche nach dem Minimum ist es wichtig, dass man die Nullen ausblendet. Ich habe das mit Hilfe von [http://itp.tugraz.at/matlab/techdoc/ref/nan.html nan] gemacht.<br />
<br />
Die Statusvariable ist extrem wichtig, da mit ihrer Hilfe der Solver erkennen kann, ob er aufhören kann.<br />
<br />
==== sudoku_set ====<br />
Nachdem man nun eine neue Zahl im Sudoku gesetzt hat, muss man die entsprechenden Einträge in der logischen 3D-Matrix wieder durch Nullen ersetzen. <br />
function L = sudoku_set(L,iz,is,val,SI)<br />
%<br />
% L = sudoku_set(L,iz,is,val,SI)<br />
%<br />
% removes entries from L when the value val is set at position (iz,is).<br />
%<br />
% Input: <br />
%<br />
% L : (n2 x n2 x n2)-logical array with possible positions on entry<br />
% corrected on exit<br />
% iz, is : row and column index<br />
% val : value which was placed at (iz,is)<br />
%<br />
% Optional Input:<br />
%<br />
% SI : single indices of the local sub-square of the Sudoku<br />
% produced by sudoku_loc (see sudoku_loc for an explanation).<br />
% if not in the input sudoku_loc should be called to produce SI<br />
%<br />
% Output:<br />
% <br />
% L : logical (n^2 x n^2 x n^2)-array with corrected values<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/colon.html colon], [http://itp.tugraz.at/matlab/techdoc/ref/ind2sub.html ind2sub], [http://itp.tugraz.at/matlab/techdoc/ref/min.html min], [http://itp.tugraz.at/matlab/techdoc/ref/max.html max].<br />
<br />
Strategie: Man braucht nicht unbedingt testen, wo ein Wert Eins war. Man kann die entprechenden Zeilen, Spalten, Blockbereiche und Werte in die 3te Dimension (an der neuen Position) einfach auf Null setzen. Das geht mit Hilfe der Doppelpunkt-Notation und mit Hilfe der Resultate von sudoku_sub und sudoku_loc sehr einfach.<br />
<br />
==== sudoku_valid ====<br />
Diese Funktion soll überprüfen, ob ein Sudoku zumindest von der Angabe her in Ordnung ist. Ob es auch lösbar ist, kann man damit natürlich nicht sagen. Bei ungültigen Sudokus stimmt die Größe nicht, oder sie haben bereits gleiche Zahlen in Zeilen, Spalten oder Blöcken.<br />
function c = sudoku_valid(S)<br />
% <br />
% c = sudoku_valid(S)<br />
%<br />
% computes the logical result c wether the Sudoku S is a valid<br />
% Sudoku.<br />
% <br />
% Input:<br />
%<br />
% S : Sudoku array<br />
% <br />
% Output:<br />
%<br />
% c : logical value<br />
% 0 - not square, size not power of 2, not valid<br />
% 1 - correct<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/colon.html colon], [http://itp.tugraz.at/matlab/techdoc/ref/colon.size size], [http://itp.tugraz.at/matlab/techdoc/ref/logical.html logical], [http://itp.tugraz.at/matlab/techdoc/ref/sqrt.html sqrt], [http://itp.tugraz.at/matlab/techdoc/ref/fix.html fix], [http://itp.tugraz.at/matlab/techdoc/ref/repmat.html repmat], [http://itp.tugraz.at/matlab/techdoc/ref/permute.html permute], [http://itp.tugraz.at/matlab/techdoc/ref/sum.html sum], [http://itp.tugraz.at/matlab/techdoc/ref/all.html all], [http://itp.tugraz.at/matlab/techdoc/ref/logicaloperatorselementwise.html logische Operatoren], [http://itp.tugraz.at/matlab/techdoc/ref/relationaloperators.html Vergleichsoperatoren].<br />
<br />
Strategie: Eine wirklich schöne Strategie ohne Schleife habe ich nicht gefunden, daher die große Anzahl von Befehlen. Ich habe versucht herauszufinden, ob in Zeilen, Spalten, Blöcken Duplikate vorkommen. Daher habe ich das Suudoku in die dritte Dimension repliziert und dann mit einer 3D-Matrix verglichen, die auf der ersten Seite nur Eines, auuf de zweiten nur Zweier, usw., hat. Das ist aber sicher nicht die schönste Lösung.<br />
<br />
==== sudoku_correct ====<br />
Diese Routine soll nun herausfinden, ob ein Sudoku korrekt gelöst ist.<br />
function c = sudoku_correct(S)<br />
% <br />
% c = sudoku_correct(S)<br />
%<br />
% computes the logical result c wether the Sudoku S is a correct<br />
% Sudoku solution.<br />
% <br />
% Input:<br />
%<br />
% S : Sudoku array<br />
% <br />
% Output:<br />
%<br />
% c : logical value<br />
% 0 - not square, size not power of 2, not correct<br />
% 1 - correct<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/colon.html colon], [http://itp.tugraz.at/matlab/techdoc/ref/colon.size size], [http://itp.tugraz.at/matlab/techdoc/ref/logical.html logical], [http://itp.tugraz.at/matlab/techdoc/ref/sqrt.html sqrt], [http://itp.tugraz.at/matlab/techdoc/ref/fix.html fix], [http://itp.tugraz.at/matlab/techdoc/ref/repmat.html repmat], [http://itp.tugraz.at/matlab/techdoc/ref/transpose.html transpose], [http://itp.tugraz.at/matlab/techdoc/ref/sort.html sort], [http://itp.tugraz.at/matlab/techdoc/ref/all.html all], [http://itp.tugraz.at/matlab/techdoc/ref/logicaloperatorselementwise.html logische Operatoren], [http://itp.tugraz.at/matlab/techdoc/ref/relationaloperators.html Vergleichsoperatoren].<br />
<br />
Strategie: Mir ist am einfachsten vorgekommen, die Zeilen, bzw. Spalten oder Blöcke zu sortieren und mit Matrizen zu vergleichen, die so aussehen:<br />
1 2 3 4<br />
1 2 3 4 <br />
1 2 3 4<br />
1 2 3 4<br />
<br />
=== Solver ===<br />
Das hier diskutierte Lösungsprogramm ist ein rekursives Programm, d.h. es ruft sich immer wieder selbst auf. Ein einfaches Beispiel dazu ist ein Programm zur Berechnung der Fakultät einer Zahl [http://itp.tugraz.at/LV/kernbich/AppSoft-1/Uebung/Sudoku/fak.m]. Bei rekursiven Aufrufen, wird immer eine neue Instanz der Routine erzeugt, die bei Fertigstellung ihr Resultat an die vorherige übergibt, bis schlussendlich die nullte Instanz das Resultat an den Benutzer übergibt.<br />
<br />
==== sudoku_solve ====<br />
<br />
function [S,ready] = sudoku_solve(S,ready,L,count)<br />
%<br />
% [S,ready] = sudoku_solve(S) <br />
% <br />
% solves a Sudoku S with recursion. For the recursive call of sudoku_solve<br />
% one needs additional input:<br />
%<br />
% [S,ready] = sudoku_solve(S,ready,L,count)<br />
%<br />
% Input:<br />
% <br />
% S : Sudoku array<br />
% <br />
% Additional input (for the recursive calls):<br />
%<br />
% ready : a logical status variable (default value: 0)<br />
% 0 - Sudoku is not ready<br />
% 1 - Sudoku is ready<br />
%<br />
% L : logical array described in sudoku_all_possible.<br />
% it is not specified when the user calls the routine and it <br />
% should be computed then by sudoku_all_possible.<br />
% for all further recursive calls its modified content is passed on<br />
% to the next recursive call of sudoku_solve.<br />
% the modification to L is done by sudoku_set.<br />
%<br />
% count : a counter for the recursion depth<br />
% should be zero at the beginning and again zero at the end.<br />
%<br />
% Output:<br />
%<br />
% S : Sudoku<br />
%<br />
% ready : status variable<br />
% 0 - not solveable<br />
% 1 - solved <br />
%<br />
% Error:<br />
% <br />
% There is an error message:<br />
% Sudoku can not be solved!<br />
% if the Sudoku is not valid (see sudoku_valid)<br />
%<br />
% Warning:<br />
% <br />
% There is a warning message:<br />
% Sudoku not correct!<br />
% when it was a valid Sudoku which could not be solved.<br />
%<br />
% Winfried Kernbichler 31.03.2006<br />
<br />
Strategie: Der Solver ist jetzt eigentlich ein sehr kurzes Programm. Beim Aufruf durch den Benutzer, der ja nur S übergibt, müssen die Defaultwerte gesetzt werden, bzw. mit sudoku_valid überprüft werden, ob es überhaupt ein gültiges Sudoku ist. Natürlich muss man hier auch die logische Matrix L mit sudoku_all_possible ausrechnen. Es ist das einzige Mal, dass man diese Routine wirklich braucht, da der Rest mit sudoku_best_possible gelöst wird.<br />
<br />
Der Algorithmus bedient sich der Tiefensuche. Ich habe hier zur Erläuterung ein Bild aus [http://de.wikipedia.org/wiki/Backtracking Wikipedia] eingefügt. <br />
<br />
[[Image:Tiefensuche.png|thumb|350px|center|Tiefensuche]]<br />
<br />
Das Problem bei der Tiefensuche ist, dass man nicht weiss, wo sich die gewünschte Lösung verbirgt und man muss oft viele der Wege gehen, bis man die Lösung erreicht. Nehmen wir der Einfachheit halber an, die Lösung ist im Bild bei 10 erreicht. Startet man nun die Suche, steht das Programm bei 1 (Instanz 0). Beim Sudoku würde man nun mit sudoku_best_possible herausfinden, dass es an der besten Position drei Möglichkeiten gibt. Nun wählt man die Möglichkeit 2 (setzt den Wert und modifiziert das logische Feld L) und ruft wiederum den Solver (Instanz 1).<br />
<br />
Diese Instanz findet 2 Möglichkeiten, wählt 3, ruft die nächste Instanz (2). Die findet zwei Möglichkeiten, wählt 4 und ruft die dritte Instanz. Diese erkennt nun, dass nichts mehr geht (status Variable aus sudoku_best_possible) und kehrt "not ready" zur Instanz 2 zurück. Diese probiert nun die zweite Möglichkeit, auch diese kommt mit "not ready" zurück. <br />
<br />
Nun kehrt der Algorthmus zur Instanz 1 zurück, ein weiterer Versuch mit 6 schlägt fehl. Dadurch Rückkehr zur Instanz 0. Diese probiert 7 dann 8. Bei 8 geht es weiter und die erste Instanz probiert 9, die zweite Instanz probiert 10, bekommt von der dritten Instanz die Antwort "ready". Nun kehrt alles mit der Antwort "ready" über die zweite, zur ersten und schließlich zur nullten Instanz zurück. <br />
<br />
Ganz zum Schluss (wenn count wieder bei Null ist) muss man überprüfen, ob das Sudoku nun korrekt gelöst ist. <br />
<br />
Da die Wege lang sein können, ist es wichtig, dass man clevere Entscheidungen trifft. Das heisst, das man dort beginnt, wo es die wenigsten Möglichkeiten gibt, und dass man sofort in einem Zweig aufhört, wenn klar ist, dass man irgendwo sowieso nicht mehr setzen kann, auch wenn diese Position noch gar nicht dran ist.<br />
<br />
Bei meiner Lösung ist das Durchprobieren der Möglichkeiten in einer Instanz, der einzige Fall, wo eine Schleife eingesetzt wird. <br />
Bei dieser Schleife muss man nur aufpassen, dass der nächsten Instanz des Solvers das richtige logische Array übergeben wird. Da in der Schleife nacheinander verschiedene Werte an einer Position gesetzt werden, muss man sudoku_set immer auf jene Instanz von L anwenden, die vor der Schleife vorhanden war.<br />
<br />
Von mir verwendete Befehle: [http://itp.tugraz.at/matlab/techdoc/ref/nargin.html nargin], [http://itp.tugraz.at/matlab/techdoc/ref/colon.error error], [http://itp.tugraz.at/matlab/techdoc/ref/warning.html warning], [http://itp.tugraz.at/matlab/techdoc/ref/if.html if], [http://itp.tugraz.at/matlab/techdoc/ref/else.html else], [http://itp.tugraz.at/matlab/techdoc/ref/for.html for], [http://itp.tugraz.at/matlab/techdoc/ref/return.html return], [http://itp.tugraz.at/matlab/techdoc/ref/relationaloperators.html Vergleichsoperatoren].<br />
<br />
Nochmals, dies ist eine mögliche Lösung unter vielen. Meine Lösung soll daher ein Hinweis sein, wenn ihr Hilfe braucht, aber nicht die exakte Vorgabe, wie sie aussehen muss.<br />
<br />
== Diskussion und Fragen ==<br />
<br />
=== Ablauf ===<br />
<br />
==== Zeitraum ====<br />
Osterferien, wobei aber nicht alles vorbei ist, wenn man danach noch Fragen an mich oder leichte offene Probleme hat. Wir sollten es aber nicht wirklich in das restliche Semester nach Ostern ausfransen lassen. Die Übungen, die dann kommen, brauchen auch ihre Zeit.<br />
<br />
==== Ratschlag ====<br />
Machen sie es nur, wenn sie Zeit haben und nicht dringend etwas für das Studium erledigen müssen. Eine Prüfung aus Experimmentalphysik oder Analysis ist sicher wertvoller.<br />
<br />
=== Soduko ===<br />
<br />
=== Matlab ===</div>Cheil