mergeMeshes (FEM / Genormte Berechnungen/OpenFOAM) - Lösung vorhanden!

Hallo liebe OpenFOAM Gemeinde,

Ich habe mich dazu entschlossen einen Beitrag hier zu posten, da ich schon sämtliche Einträge in Foren durchgelesen, aber nirgends eine passende Antwort auf meine Frage gefunden habe .

Im Rahmen meiner Bachelorarbeit arbeite ich mit OpenFOAM und bin gerade dabei meine Geometrie zu vernetzen und anschließend die beiden Meshes zu mergen.
Es handelt sich dabei um 2 STL- Geometrien, die ich zuvor beide separat mit snappyHexMesh erfolgreich vernetzt habe.
Hinweis: meine Geometrien bewegen sich nicht.

Die beiden Geometrien kann man zwar ineinander legen, aber da ich später in der Simulation die Strömung durch Beide (eine Geometrie soll ein poröses Medium sein) betrachten möchte, wollte ich sie über mergeMeshes zusammenfügen.
Wenn ich den mergeMeshes Befehl ausführe und das Ergebnis in ParaView ansehe sind die Grenzen der beiden Netze nicht sichtbar.

Nun meine Frage:
Reicht der mergeMeshes Befehl also nicht aus, um die beiden gemeshten Gebiete ineinander zu führen und die beiden Netzzonen klar getrennt aufzuzeigen?
Wie kann man denn die Grenzflächen von nicht bewegten Geometrien definieren?

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

bezüglich deiner Frage zu mergeMesh kann ich dir nicht viel dazu sagen. Aber soweit ich weiß fügst du beide Netze zusammen ohne das du Zonen erstellst. Die Zonen definierst du mit setSet oder topoSet oder direkt in snappyHexMesh. Du brauchst ja die cellZone später für die Definition deiner porösen Zone. An deiner Stelle würde ich, wie du schon sagtest, beide STL's zusammenfügen und ein Netz erstellen. Danach definierst du dir deine cellZone und faceZone (falls benötigt) mit setSet oder topoSet. Das einfachste wäre es aber wenn du die Zone gleich in sHM definierst. Damit sparst du dir einen Schritt. Wie du das letzten Endes machen möchtest obliegt natürlich an dir (:

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo zusammen,

hatte selbst vor kurzem die Geschichte mit mergeMesh und wie Tobi bereits sagte, verbindet mergeMesh zwar die einzelnen Gitter, erstellt hierbei aber keine separaten Zonen mit denen weitergearbeitet werden kann.

Ich hatte zu Beginn den Weg über mergeMesh, topoSet (um Zonen zu erzeugen,createBaffles (für Rotationsflächen) durchgeführt, das stellt sich aber äußerst mühsam dar.

Du kannst die Zonendefinition innerhalb eines sHMDicts direkt durchführen und dir somit den Schritt über mergeMeshes sparen.

Funktioniert problemlos und bildet mMn auch deutlich schönere Gitter an den Grenzflächen.

Gruß Tobi

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Vielen Dank für die schnellen Antworten!

Tobi, verstehe ich das richtig, dass ich die beiden Geometrien am Besten zusammen in ein snappyHexMeshDict laden soll (also nur einen Case aufbaue) und mir so den Schritt über mergeMeshes spare?

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Zitat:
Original erstellt von namali92:
Vielen Dank für die schnellen Antworten!
Tobi, verstehe ich das richtig, dass ich die beiden Geometrien am Besten zusammen in ein snappyHexMeshDict laden soll (also nur einen Case aufbaue) und mir so den Schritt über mergeMeshes spare?

Welchen Tobi du auch immer meinst, richtig (:
Du kannst auch das Tutorial hier verwenden: Zonen mit sHM

Hoff das hilft dir weiter.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

So Vielen Dank für die Rückmeldungen!
Meine Rechnung ist erfolgreich durchgelaufen aber die Datei ist jetzt um die 10 GB groß und in paraView geht gar nichts :/
Kann man die Datei denn komprimieren bzw muss ich bei der Rechnung schon angeben, dass im Output folder weniger Time Steps angegeben werden?

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

ich würde generell (falls du das noch nicht eingestellt hast)die writeCompression auf on stellen (im controldict) und dann dementsprechend die rausgeschriebenen Zeitschritte begrenzen.

Sprichst du bei "Rechnung durchgelaufen" von snappy oder vom Solver?

Solveroutput lässt sich einstellen über das writeInterval im controldict.
Zwischensteps von shm über snappHexMesh -overwrite

Was gibt denn dein checkMesh an Zellen aus?
Grüße
Tobi

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Entschuldigung, ich meinte SnappyHexMesh!

Also ich habe um die 20 Mio. Zellen nach der Vernetzung...
SnappyHexMesh -overwrite hatte ich bereits verwendet.

Das mit dem Solveroutput werden ich dann später beachten, danke!

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

20 mio Zellen ist schon recht ordentlich.
Lässt du dann hoffentlich über ein cluster rechnen?
Also auch die eigentliche Rechenarbeit des Solvers später?

Hast du die Gittererzeugung parallel gerechnet?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,

Darf man Fragen was du simuliert? 20.000.000 Cells ist alles andere als klein. Ich kenn zwar ein paar die solch riesige Simulationen aufsetzen aber die sind auch größenwahnsinnig

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,

Darf man Fragen was du simuliert? 20.000.000 Cells ist alles andere als klein. Ich kenn zwar ein paar die solch riesige Simulationen aufsetzen aber die sind auch größenwahnsinnig

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ja ich rechne natürlich auf Clustern

Also ich simuliere die Strömung eins Fluids durch ein Gewebe aus Fasern mit umliegender Kavität. Der Aufbau des Fasergewebes besteht aus sehr vielen Zellen. Ich denke, dass die Datei deshalb so riesig wird, wenn ich die umliegende Form (einfache Geometrie) und die Fasern für den Vernetzungsprozess im sHMDict zusammenführe.

Bisher habe ich noch keinen Solver angewandt..
Daher mein Problem: Ich glaube, dass bei mir der -overwrite- Befehl für sHM nicht ausreicht, um die Datei für paraView zu komprimieren, ohne dass es abstürzt...:/

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

was für einen Rechner hast du denn? Reicht der Arbeitsspeicher für das größere Modell?

Ich habe erst diese Woche einen Case mit 60 mio. Zellen angeschaut, der hat ca. 50 Gb Ram benötigt. Auch bin ich der Meinung das ein Student von mir mal einen Case in deiner Größenordnung auf unserem Cluster mit SHM erstellt hat. Er hatte keine Probleme.

------------------
Viele Grüße
Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Noch ein Hinweis.

Verwende doch einfach Paraview direkt von der offiziellen Seite. Mach das auch immer so. Paraview starte ich selten aus den Third-Partys.

Zwecks deinem Case. Ist es zwingend erforderlich das du das Medium so detailliert nachstellst oder wäre ggf. eine poröse Zone auch geeignet? Vllt nur ein Teil betrachten? Es wäre nämlich sehr blöd wenn du dein Case 2 Wochen auf deinem Cluster rechnen lässt und danach feststellst das deine Settings falsch waren.

Gutes gelingen.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Das mit dem Arbeitsspeicher passt schon bei meinem Rechner, danke!

Also das detaillierte Medium soll im zweiten Schritt dann als poröse Zone dargestellt werden, so weit bin ich aber noch nicht Ich wollte erst einmal schauen, ob ich mit mergeMeshes oder definierten cellZones für die STL- Regionen weiterarbeite.

Eine andere Frage: Ein weiteres Problem ist bei mir, dass das backgroundMesh der umliegenden Kavität nach Anwendung von snappyHexMesh -overwrite trotzdem nicht verschwindet (Hinweis: meine Geometrie ist geschlossen).

Im boundaryDict (polyMesh) werden die Flächen vom BlockMesh auch noch aufgeführt (scheinen also von snappy auch nicht überschrieben worden zu sein...

Kennt jemand das Problem?

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

das mit den Patches ist ganz normal. Die können bleiben allerdings werden dann die nFaces bei Null stehen. Das mit dem Hintergrundnetz kann sein, wenn du bspw. im Ordner 0 noch ein polyMesh hast, dass dieses Hintergrundnetz enthält. Vllt machst du auch nur Fehlre bei der Darstellung in PV. Kann ich leider so nicht beurteilen. Ist deine Geometrie wirklich wasserdicht? surfaceCheck schon mal laufen lassen? Kann auch sein das deine STL nicht Wasserdicht ist und du daher Probleme hast oder die Triangulation einfach alles andere als optimal ist.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Vielen Dank für den Tipp!

Habe surfaceCheck laufen lassen und das Problem ist deutlich: "surface is not closed" und die Oberflächennormale zeigt nicht nur in eine Richtung...

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ich glaub ich weiß jetzt auch, warum meine Datei nach Anwendung von splitMeshRegions so langsam in paraView war:

Anscheinend wurden nach der Ausführung von splitMeshRegions -cellZones ziemlich viele "domain*"- Folder erstellt. Ist das normal?
(Weil ich habe gelesen, dass normalerweise nur ein 0- Folder für den Leerraum zwischen Hintergrundnetz und den STl's erstellt wird).
Zusätzlich fehlt dann der Ordner für meine eine STL komplett (Für die andere STL wurde der Ordner erstellt).

Ich habe beide jedoch unter refinementSurfaces aufgeführt und ihnen separate cellZones zugewiesen.

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hi,

wenn du während splitMeshRegions -cellZonesOnly sehr viele Ordner bekommst mit dem Namen "domainXY" dann kann das ein Indiz dafür sein das irgendwas nicht passt. Angenommen du hast 3 Regionen dann solltest du normalerweise auch 3 bekommen, sofern deine STL's komplett mit dem Hintergrundnetz korrelieren. Wenn du dein Hintergrundnetz noch größer machst oder es irgendwelche Regionen gibt, die nicht von den STLs eingeschlossen werden, dann bekommst du natürlich diese "domainXY"'s.

Sollten diverse Regionen, welche von deinen STL's NICHT eingeschlossen werden, separiert sein, heißt also nicht zusammenhängen, kannst du natürlich auch mehrere "domainXY" bekommen. Ist also auch kein Fehler. Allerdings ist das nicht die Regel. Damals hatte ich einen Fall bei dem ich 40 Domains bekommen hatte. Grund dafür war, dass viele einzelne Zellen von Regionen abgespaltet wurden und somit diverse einzelne Zellen eine eigene ID bekommen haben (ich meine also ne eigene CellZone ID). Ergo, 40 Domains nach dem Splitten. Lag aber einzig und allein an meiner Triangulation der STL.

Die Triangulation ist wichtig aber muss nicht unbedingt zu einem Fehler führen.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Okay alles klar danke!
Ich habe dann jetzt über den Befehl "rm -r constant/domain* sys*/domain*" die überflüssigen Domains gleich entfernen lassen und mein Case ist nicht mehr so groß.

Eigentlich wollte ich mit der Simulation herausfinden, ob ich meine zwei unterschiedlichen cellZones getrennt (mit unterschiedlichen Geschwindigkeiten) ansteuern kann. Ich habe bereits die MultiRegionFoam tutorials durchgeschaut aber mir stellt sich die Frage: Die Ordner für die einzelnen Regionen dort (bottomAir, heater usw. ), die bereits bestehen, sind das die, die ich durch splitMeshRegions auch in constant/System erhalten habe?

Und kann ich in einem MultiRegion Case nur mit den Solvern ChtMultiRegion (und nicht simpleFoam) arbeiten?

Anmerkung: die Temperatur der Flide ist für mich nicht relevant, weshalb ich das Tutorial wie ich glaube wohl nicht ganz verstehe...

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

du kannst in FOAM alles mögliche machen. Du kannst allen Zellen diverse Werte zuweisen wenn du lustig bist. Heißt, du kannst eine Zelle porös machen, die andere als Metall betrachten und die nächste als Flüssigkeit. Du kannst auch diversen CellZones verschiedene Geschwindigkeiten zuordnen. Alles ist in FOAM möglich. Die Frage ist nur ob du das mit den bestehenden Solvern, Libs und Tools (swak4Foam) erreichen kannst oder ob du wirklich eigene Sachen entwickeln müsstest. Letzteres ist aber auch nicht so schwer wenn man sich mit C++ etwas auskennt. Die meiste Arbeit besteht meistens diverse Funktionen zu finden, die genau das machen was du brauchst. Dafür ist dann Doxygen ganz gut.

CHT steht für conjugated heat transfer. Also wenn du mehrere Domains hast. Ansonsten betrachten wir ja immer ein Fluid das in einer Domain ist. Ausnahme sind da natürlich die Multiphase Solver / Lagrange.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Vielen Dank für die schnelle Antwort Tobias =)

Also ich betrachte bei der Durchströmung meines Gebiets nur ein Fluid. In meinem einen Gebiet habe ich ein anderes integriert (porös), das ich aber im ersten Schritt erst einmal nur umströmen möchte. Ich denke, dass das, wie du schon gesagt hast, ohne Erweiterungen möglich ist.
Jedoch hab ich das Problem, dass ich meine STL in im sHMDict in regions unterteilt habe (inlet, outlet etc.), welche nach SplitMeshRegions -cellZones jedoch nicht als boundary patches für den Solvingprozess aufgeführt werden.
Es werden lediglich Ordner meinerŽbeiden STL's erstellt.

Ich habe bereits unzählige Beiträge (auch von dir Tobis) in Foren gelesen, aber habe den Eindruck bekommen, dass für dieses Problem noch keine richtige Antwort existiert, die auf mein Problem übertragbar ist.

------------------
Viele Grüße,
Lisa

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Lisa,

du verwechselst da was. Eine Region-STL hat nichts mit splitMeshRegions zu tun (:

Eine Region-STL ist eine geschlossene STL mit verschiedenen PatchNamen. In Paraview erkennt man das deutlich an den gefärbten Flächen. Nachdem sHM fertig ist, solltest du mal in deine Datei » constant/polyMesh/boundary schauen. Da sollten dann die Namen der Oberflächen da sein. Falls nicht, machst du was falsch in sHM. Dann empfehl ich dir einfach die Tutorials von sHM anzuschauen oder auf der WIKI von FOAM mit dem Stichwort sHM oder direkt auf meiner Homepage. Ich arbeite ausschließlich mit Region-STL's.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP