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

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

   bsub<fluent.lsf

6. Den laufenden Job hinsichtlich Speicher und Funktionalität überprüfen

   bjobs -l

7. Ausgabe von Fluent betrachten um die Ergebnisse laufend zu überprüfen

   tail -f fluent.log

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.

fluent.lsf

#!/bin/csh
#BSUB -q BatchXL
#BSUB -R "mem > 10000 span[hosts=1] order[cpuf]"
#BSUB -oo lsf_fluent.log
#BSUB -e lsf_fluent.err
#BSUB -J Fluent_Job_parallel
#BSUB -n 4
date
pwd
fluent 3ddp -t$LSB_DJOB_NUMPROC -ssh -g < fluent.jou > fluent.log
date

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

file/read-case-data test1.cas
solve/initialize initialize
solve/iterate 5000
file/write-data test1.dat
exit
yes

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.

file/read-case-data test2.cas
/solve/iterate 1
/solve/dual-time-iterate 10000 20
exit
yes

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.