Fluent als Batch-Job betreiben

Bei umfangreichen wissenschaftlichen Rechnungen ist es oft sinnvoll, seine Fluent-Rechnungen nicht als interaktiven Job laufen zu lassen, sondern sie „rein“ an den Solver von Fluent zu übermitteln. Das nennt man Batchjob, da er ohne GUI zurecht kommt. Der Vorteil liegt darin, dass die reine Berechnung auf leistungsstarken Servern stattfindet, auf die man im interaktiven Modus keinen Zugriff hat.

Wie man das Schritt für Schritt macht, möchte ich in diesem Artikel Stichpunktartig erläutern. Mich selbst betrifft das Problem an der Technischen Universität Ilmenau, wo ich mir im Uni-Rechenzentrum Hilfe zu der Aufgabenstellung geben lassen habe.

Es gibt im Rechencluster eine relativ hohe Anzahl an Servern, die die Fluent-Rechnungen durchführen können. Die Vergabe der Jobs auf die interaktiven Rechenknoten des Universitätsrechenzentrum der TU Ilmenau erfolgt über eine Software. Zitat aus der Beschreibung von der Internetseite der TU Ilmenau:

Der Zugang zu den Computeservern erfolgt über das TUILAN. Die Programme bzw. die Software werden auf dem Computeserver gestartet und die grafische Ausgabe (bei interaktiven Jobs) erfolgt auf dem Clienten – also auf dem PC oder auf einer Workstation auf dem Arbeitsplatz des Nutzers. Die Zuteilung der CS- Ressourcen wie CPU, Memory erfolgt durch Jobverwaltungssoftware LSF.

Das Jobverwaltungssytem LSF (Load Sharing Facility) ermöglicht den Zugriff auf die Computerserver. Eine direkte ssh-basierende Verbindung zu einem einzelnen Knoten des CS- Clusters ist nicht möglich. Beim Arbeiten mit den Maschinen wird zwischen Batchjobs und interaktiven Jobs unterschieden. Jeder Job wird beim Starten durch eine von LSF zugeteilte Jobnummer (JobID) eindeutig gekennzeichnet.
Bevor ein Job gestartet wird, muß der Job hinsichtlich seiner Ressourcen (CPU Zeit, RAM) klassifiziert werden. Im Ergebnis dessen wird der Job vom Nutzer durch LSF einer passenden Queue zugeordnet.

Überblick

Die Vorgehensweise kann sich von meinem Vorschlag unterscheiden. Das ist lediglich der Weg, den ich selbst benutze.
  1. Alles einstellen, z.B. in Ansys Workbench, Designmodeler, Mesh und Fluent
    In der Workbench erstellt man seine Geometrie und das Netz der Simulation wie gewohnt.
  2. Als *.cas exportieren
    Wenn die Geometrie und das Netz eingestellt ist, kann man (z.B. aus der Workbench heraus) Fluent starten und die Randbedingungen sowie die restlichen Parameter einstellen. Ist man fertig, exportiert man alles als *.cas Datei (File → Write → Case)
  3. fluent.lsf → zunächst Angabe für den Rechenserver: Welche Ressourcen brauche ich ungefähr?
    danach Befehl, um Fluent zu starten und die Befehle aus fluent.jou abzuarbeiten
  4. fluent.jou → Was soll in Fluent gemacht werden? Zusammenstellen der Datei mit Hilfe der Ausgabe aus der Fluent-Konsole möglich
  5. Den Batchjob starten
  6. Den laufenden Job hinsichtlich Speicher und Funktionalität überprüfen
  7. Ausgabe von Fluent betrachten um die Ergebnisse laufend zu überprüfen
  8. Für das Postprocessing kann man die Ergebnisse in Fluent importieren
    File → Import → Case & Data
  9. Alternativ kann man die Ergebnisse natürlich auch in CFD-Post auswerten.
Das Postprocessing findet genau so statt wie bei interaktiven Jobs. Im Beispiel ist ein Konvektionsexperiment in CFD-Post zu sehen.

Das Postprocessing findet genau so statt wie bei interaktiven Jobs. Im Beispiel ist ein Konvektionsexperiment in CFD-Post zu sehen.

fluent.lsf

Zeile 2: Vorgabe über die maximale Dauer des Batch-Jobs
Zeile 3: Gewünschte Ressourcen (10 GB RAM, maximale CPU)
Zeile 4: Logfile (-o für anhängen an vorhandenes Log, -oo für Ersetzen des Bestehenden)
Zeile 5: Errorfile
Zeile 6: Jobname
Zeile 7: Anzahl der CPU-Kerne
Zeile 10: Fluent-Job starten, Anweisungen aus fluent.jou, Logfile in fluent.log

fluent.jou

Stationär

Zeile 1: *.cas (und *.dat) Datei einlesen
Zeile 2: Initialisierung starten
Zeile 3: 5000 Iterationen zulassen
Zeile 4: Ergebnisse in *.dat Datei schreiben
Zeilen 5-6: Job beenden

Instationär

Auch instationär kann man hier berechnen.

Zeile 3: solve/dual-time-iterate [number-of-timesteps] [max-number-of-iterations-per-time-step]

[Update 13.03.2014] instationäre Berechnung ergänzt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *