Simulationen mit OpenFOAM auf einem Banana Pi M64
OpenFOAM auf einem Banana Pi M64?
OpenFOAM ist eine offene Ansammlung von Bibliotheken, mit denen Strömungsmechanische Simulationen durchgeführt werden können. Das ist eines der größten Anwendungsgebiete, aber noch lange nicht das einzige:
Open Field Operation And Manipulation steht dafür, dass der Entwickler eine Differentialgleichung aufstellen kann und diese durch OpenFOAM lösen lässt. Das klingt nach einem Universaltool, aber ganz so einfach ist es dann doch nicht. OpenFOAM benutzt ein eigenes C++, mit dem einige sogenannte „Solver“ geschrieben wurden. In diesen „Solvern“ ist das Differentialgleichungssystem mit einem speziellen C++-Dialekt geschrieben, der von den OpenFOAM-Bibliotheken erkannt wird. Im Code als auch in der gebauten Executable sind einige bekannte Methoden und Parameter einzustellen, damit letztlich die Rechnung ordnungsgemäß abläuft. OpenFOAM bringt einige Solver und zahlreiche Tutorials im Paketumfang mit, welche ohne großen Aufwand eingesetzt werden können.
Banana Pi M64 ist ein kleiner Computer wie das Raspberry Pi, allerdings mit wesentlich mehr Arbeitsspeicher, 64-Bit Architektur, eMMC (Auf der Platine integrierter Speicher) und einem höher getakteten Prozessor:
http://www.banana-pi.org/m64.html
Der große daran Vorteil ist: es ist klein, leise und verbraucht wenig Strom. Vergangene Versuche mit OpenFOAM auf dem RaspberryPi hat es schon in der Vergangenheit gegeben:
Jetzt starte ich einen neuen Versuch und schaue wie gut die Performance ausfällt. Da man mit OpenFOAM mehrere Rechner zusammenschalten kann um parallele Rechnungen durchzuführen, kann man damit wunderbar seine Infrastruktur skalieren. Hier ist meine Hardware:
Einmal zusammengebaut sieht es dann so aus:
Und im Betrieb:
Ein weitere Rechner (Desktop-System) nutzt folgende Spezifikationen:
Ich werde die Rechenzeiten des BPi gegen diesen Desktop-Rechner vergleichen. Natürlich ist dieser schneller, aber der Faktor interessiert mich. Grund ist, dass man sich die Frage stellen kann, ob mehrere BananaPi Geräte vielleicht doch einen i5 dieser Klasse ersetzen kann. Wie viele das wären und welcher Platz (Serverraum Volumen) benötigt wird um diese Rechenleistung ernsthaft einzusetzen, habe ich abgeschätzt. Allerdings wurde dafür ein einfacher Fall genommen und dieser rechnet jeweils auf beiden Systemen mit einem einzigen Kern.
Betriebssystem für BananaPi
Zur der Zeit dieses Artikels gibt es ein Ubuntu 16.04 Image für das Gerät. Ich habe mir die Zeit genommen und es auf das eMMC aufgespielt:
http://www.banana-pi.org/m64-download.html
Leider gab noch kein Image mit Ubuntu 18.04, also habe ich 16.04 genommen und ein Upgrade gefahren
sudo apt update && sudo apt dist-upgrade && sudo apt autoremove sudo apt-get install update-manager-core sudo do-release-upgrade -d
Das lief auch wunderbar durch:
cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"
Grund dafür ist, dass die Aktualität einer Ubuntu LTS (Long-Term-Release) in der Regel dafür sorgt, dass man in weniger Fehler hinein-tritt. Das gilt allerdings nur für LTS. Der Grund dafür ist, dass die Entwickler solcher Tools größtenteils auf den Ubuntu LTS Versionen testen und davon immer aktuellste (Meine persönliche Erfahrung).
OpenFOAM aus den Repos installieren
Ursprünglich wollte ich es aus dem Quellcode kompilieren, doch leider gab es zu viele Fehler und ich habe dann die Repo-Version genommen:
apt install libopenfoam openfoam-examples
Auf dem i5 habe ich OpenFOAM 4.1 dann selber gebaut.
Einfacher Versuch – PitzDaily
PitzDaily ist so ziemlich das erste Beispiel, was man unter OpenFOAM simulieren kann. Der Fall ist sehr schnell gerechnet.
Das Ergebnis von beiden mit sehr kleinen Abweichungen sieht als Auswertung dann wie folgt aus:
Bild: Hier ist ein kleiner Kanal zu erkennen, in dem Luft oben links mit einer Geschwindigkeit von 10 m/s durchgeblasen wird. Am unteren Teil des Kanals sieht man durch die Vektoren (schwarze Pfeile), dass ein induzierter Wirbel entsteht. An den Farben erkennt man das Geschwindigkeitsprofil.
Rechenzeiten
Urteil der Rechenzeiten folgt. Am Ende der Logs kann man die Simulationszeit für die Iterationen ablesen.
Auf dem BPI-M64:
...
smoothSolver: Solving for Ux, Initial residual = 0.00013831, Final residual = 9.28001e-06, No Iterations 6
smoothSolver: Solving for Uy, Initial residual = 0.000977894, Final residual = 6.73868e-05, No Iterations 6
GAMG: Solving for p, Initial residual = 0.000761591, Final residual = 6.02052e-05, No Iterations 5
time step continuity errors : sum local = 0.00284907, global = -0.000320399, cumulative = 1.21783
smoothSolver: Solving for epsilon, Initial residual = 0.000117283, Final residual = 7.16786e-06, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.000211639, Final residual = 1.2388e-05, No Iterations 4
ExecutionTime = 126.81 s ClockTime = 129 s
SIMPLE solution converged in 298 iterations
streamLine streamlines write:
seeded 10 particles
Tracks:10
Total samples:10809
Writing data to "/home/gerstrong/pitzDaily/postProcessing/sets/streamlines/298"
End
Auf dem i5:
smoothSolver: Solving for Ux, Initial residual = 0.000117166, Final residual = 1.15333e-05, No Iterations 5
smoothSolver: Solving for Uy, Initial residual = 0.000974057, Final residual = 6.71236e-05, No Iterations 6
GAMG: Solving for p, Initial residual = 0.000753183, Final residual = 6.40228e-05, No Iterations 5
time step continuity errors : sum local = 0.00305484, global = -0.000240797, cumulative = 1.02849
smoothSolver: Solving for epsilon, Initial residual = 0.000118496, Final residual = 6.83101e-06, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.00021769, Final residual = 1.35326e-05, No Iterations 4
ExecutionTime = 7.31 s ClockTime = 8 s
SIMPLE solution converged in 283 iterations
streamLine streamlines write:
seeded 10 particles
Tracks:10
Total samples:10885
Writing data to "/mnt/common/Simulations/Software/OpenFOAM-v1806/tutorials/incompressible/simpleFoam/pitzDaily/postProcessing/sets/streamlines/283"
End
Komischerweise konvergierten die Rechnungen unterschiedlich (283 zu 298). Unterschiedlich, und zwar sehr, sind auch die Rechenzeiten der Geräte. Der i5 war nach 7,31 Sekunden fertig, während der BananaPi ganze 126,81 Sekunden brauchte! Damit sind wir bei einem Faktor von 17,35!
Also kann man sagen mit 18 BananaPi-Geräten und etwas Interprozess-Parallelisierung oder mehreren Rechenfälle z.B. für Parameterstudien, könnte sich eine Anschaffung dieser Art doch lohnen.
Raumausfüllung
Mein i5 mit Gehäuse hat folgende Dimensionen in cm:
42x35x17 ergibt 24.990 cm³
7,5×10,5×3,0 ergibt 236,25 cm³
Ich kann also mit ca. 100 BananaPi-Geräten den Platz des i5 Rechners ausfüllen. Aus dieser Sicht ist der Faktor 17,35 doch nicht so schlecht, bedenkt man die Größe BPi.
Fazit
Klein aber Oho! Wie erwartet, ist das BananaPi zwar schwächer als ein i5, berechnet man es aber auf die Raumausfüllung des Geräts, sieht das ganze gar nicht mehr so schlecht aus. Für stark parallelisierbare Rechenfälle ist die Anschaffung eines kleinen Pi-Clusters für wissenschaftliche oder industrielle Anwendungen vielleicht doch keine schlechte Idee.
Neueste Kommentare