Die Toolbox
In alter UNIX-Tradition bietet OpenFOAM eine Vielzahl kleiner Programme und eine fast unüberschaubare Bibliothek zum Lösen sehr spezifischer Probleme an. Jedes Programm erfüllt dabei eine spezielle Aufgabe möglichst effizient. Erst das Zusammenspiel der einzelnen Komponenten ermöglicht es, komplexe Probleme zu lösen. OpenFOAM 1.4.1 umfasst 187 Standardprogramme, die mit dem integrierten wmake System kompiliert und an die eigenen Bedürfnisse angepasst werden. Eine strenge Unterscheidung in UDFs (User Defined Functions) und Programmcode, wie etwa bei den kommerziellen, eher monolithischen Konkurrenten Ansys-CFX oder Ansys-Fluent, gibt es nicht.
Die Werkzeuge gliedern sich in Pre-Processing, Mesh-Manipulation und Umwandlung, Solver, Post-Processing, Werkzeuge zur Parallelisierung, Tools zur Fehlerabschätzung und eine große physikalische Modellbibliothek. Es gibt zur Zeit kein GUI, welches das Arbeiten mit OpenFOAM erleichtern würde. Die erhältliche Dokumentation ist rudimentär und das Schreiben eigenen Codes erfordert ausgezeichnete C++-Kenntnisse. Von der steilen Lernkurve abgesehen bietet OpenFOAM Features, die in kommerziellen CFD-Programmpaketen noch nicht implementiert sind, ein ausgezeichnetes Speichermanagement, sehr gute Parallelisierbarkeit und im Vergleich zu kommerziellen Produkten deutlich schnellere und effizientere Solver.
Case Struktur
OpenFOAM legt Cases nicht in ein oder zwei Dateien sondern in Verzeichnissen ab. Das soll an einem Beispiel erläutert werden. Das Grundgerüst (entsprechend einem .cas-File in Ansys-Fluent) für den exemplarischen Case „mixer“ sieht von der Shell gesehen so aus:
$ find mixer
mixer
mixer/system
mixer/system/cellSetDict
mixer/system/faceSetDict
mixer/system/fvSchemes
mixer/system/fvSolution
mixer/system/createPatchDict
mixer/system/setFieldsDict
mixer/system/controlDict
mixer/0
mixer/constant
mixer/constant/transportProperties
mixer/constant/environmentalProperties
mixer/constant/turbulenceProperties
mixer/constant/polyMesh
mixer/constant/polyMesh/cellZones
mixer/constant/polyMesh/points
mixer/constant/polyMesh/neighbour
mixer/constant/polyMesh/faces
mixer/constant/polyMesh/faceZones
mixer/constant/polyMesh/pointZones
mixer/constant/polyMesh/boundary
mixer/constant/polyMesh/owner
mixer/constant/cellToRegion
Die Steuerung der Solver und Utilities erfolgt über so genannte „Dictionaries“. Will man ein Programm auf einen Case anwenden, so muss ein Dictionary für das zu verwendende Programm erstellt werden. Zum Beispiel erwartet setFields (verwendet zur Initialisierung des Cases oder Setzen von Feldvariablen) die Datei set FieldsDict bei der Anwendung auf den Case mixer.
Stoffdaten befinden sich in constant/transport Properties , Solver-Einstellungen in system/fvSolution und so weiter. Weiters werden für stationäre und instationäre Simulationen Zeitverzeichnisse angelegt, die entweder die Iterationszahl oder die simulierte Realzeit als Namen tragen und die entsprechenden Daten der Feldvariablen bzw. modifizierte Meshes (bei bewegten oder deformierten Gittern) enthalten. In constant/polyMesh befinden sich die statischen Mesh-Informationen.
Zur Laufzeit der Solver können entsprechende Dictionaries editiert werden und die Einstellungen werden bei der nächsten Iteration vom Solver übernommen, ohne diesen unterbrechen zu müssen.
Workflow
Am Beginn jeder CFD-Simulation steht die Erstellung eines geeigneten Rechengitters. Ein simpler Mesh-Gene-rator für strukturierte Gitter (blockMesh) ist Teil von OpenFOAM. Dieses nicht-interaktive Programm ist für die üblicherweise komplexen Geometrien, die in der numerischen Strömungssimulation technischer Probleme benötigt werden, nicht geeignet. Für den Import eines Gitters gibt es eine Reihe von Mesh-Konvertern für CFX, Gambit/Fluent, Gmsh, I-DEAS, Netgen, Star-CD und andere Gitter-Formate.
Nach dem Import des Gitters, und Überprüfung des Meshes mit checkMesh, in ein Grundgerüst mit den notwendigsten Dictionaries (wie etwa controlDict) werden die Dictionaries für die Solver und Modelle angepasst. Dann werden für alle Feldvariablen (Druck p, Geschwindigkeit U, ...) im Verzeichnis casename/0/ die Randbedingungen definiert, was auch den Initialzustand der Simulation festlegt.
Für die Visualisierung werden die Zeitverzeichnisse ins VTK-Format konvertiert und mit Paraview dargestellt. Dabei können die CPU-Domänen einzeln visualisiert oder auch wieder zur kompletten Geometrie kombiniert werden. Paraview bietet einen parallelen Server für sehr große und verteilte Datenmengen und ein serielles, graphisches Frontend.
Parallelisierung
Die Parallelisierung eines Cases erfolgt durch Domain Decomposition (die Zerlegung des Rechengebietes in Bereiche mit möglichst gleicher Zellzahl und geringer Austauschfläche zwischen den Domänen). Die Steuerung des Decomposers erfolgt über casename/system/ decomposeParDict. Die parallelen Solver kommunizieren über OpenMPI untereinander und werden über mpirun (Teil des OpenFOAM-Paketes) gestartet. Das verwendete Queuing-System auf icp5l ist OpenPBS. In Benchmarks konnte auf dem Cluster ein 8-fach parallelisierter Case in etwa einem Fünftel der Zeit eines einzelnen Prozesses gerechnet werden. Zwischen den Knoten mit je zwei CPU-Kernen wird über GBit Ethernet kommuniziert.
Instationäre Simulation des Aufstieg eines Luftblasenschwarms in einer Versuchsapparatur. Dargestellt sind eine Isofläche des Phasenanteils, ein Schnitt durch die Mittelebene (gefärbt nach Phasenanteil) und Geschwindigkeitsvektoren.
| CPU-Kerne | 1 → 2 | 2 → 4 | 4 → 8 | 1 → 8 |
| Zeitfaktor | 0,57 | 0,54 | 0,64 | 0,20 |
Anwendung
Die technische Anwendbarkeit der Solver und Modelle wurde in zwei Vergleichen mit Fluent und Experimenten beurteilt. Dabei unterschieden sich die Ergebnisse von OpenFOAM und Ansys-Fluent zwar, aber beide ergaben eine von den Messungen für technische Aufgaben vernachlässigbare Abweichung.
Ein Anwendungsbeispiel ist die Simulation der Flüssigkeits- und Gasströmung in einer Laborblasensäule. Ein 0,2x0,2x2 m großer Glasquader, zu 1 m mit Wasser gefüllt, wird über einen Verteiler im Boden begast. Dabei sollen der Blasenaufstieg, die Gasverteilung und Struktur der Strömung und makroskopische Größen wie der Gas-Holdup (das globale Verhältnis von Gas zu Flüssigkeit) vorhergesagt werden. Die Erkenntnisse der Laboranlage sollen dann auf industrielle Apparate zum Gas-Strippen (etwa in der biologischen Ethanolproduktion oder der Wasseraufbereitung) übertragen werden. OpenFOAM liefert mit dem VOF (Volume Of Fluid) Modell in einem Bruchteil (weniger als ein Zehntel) der Rechenzeit von Fluent vergleichbare Aussagen über Holdup und Gasverteilung, die im Experiment bestätigt werden konnten.
Blasenschwarm nach 1,8 Sekunden – kurz vor dem Durchbrechen der Flüssigkeitsoberfläche mit führender Schirmblase.
Links: Bild einer Hochgeschwindigkeitskamera (Modell MotionPro der Fa. Redlake – Danke an das Institut für Softwaretechnik und Interaktive Systeme).
Rechts: Isofläche des Phasenanteils gefärbt nach Absolutgeschwindigkeit in (m/s).
Referenzen
Harasek, M.; Horvath, A.; Jordan, Ch.; Kuttner, Ch.; Lukasser, M.: CFD Simulation einer Blasensäule mit dem VOF Modell – Fluent vs. OpenFOAM vs. Experiment (als Vortrag für Process Net 2008 akzeptiert)
Lukasser, M.: Entwicklung einer Laborblasensäule und eine Parameterstudie am Eulerschen Modell für Blasenströmungen mit gleichmäßiger Begasung Diplomarbeit (2008)
http://www.opencfd.co.uk/openfoam