---

rippencase.zip surface.png

Hi,
die letzten Wochen habe ich einen Testfall komplett mit OpenFoam nachgebaut.
Ich habe eine Referenzgeometrie aus einer Fluent Berechnung und baue das ganze jetzt mit OpenFoam nach.

Das Gitter habe ich als stl mit snappyHexMesh erzeugt. Als Löser benutze ich simpleFoam mit mapped boundary conditions.
Meine Randbedingungen für den Einlauf die mir mein Betreuer geben konnte sind folgende:
Massenstrom 0,078885511
Temperatur 338,98
Viskosität 2,04E-05
Dichte 1,0420791
Fläche 0,005618
hydr. Durchmesser 0,06642

Geschwindigkeit 13,4745671339
Reynoldszahl 45713,2013267046

Nusseltzahl 98,1128252793

Was ich jetzt noch nicht genau weiß ist, wie ich die mapped condition definiere und aus dem Source Code werde ich nicht ganz schlau.

Wie kann ich in snappy meine mapped Bedingungen einbinden? Bisher mache ich das nach dem snappen über "changeDictionary" aber als paralleler Fall schreibt er das nicht in die boundary files der processor* Ordner.

Als Anhang lade ich mal meinen kompletten Fall hoch und ein Bild der Geometry.

Gruß,
Phil

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

---

Hallo Philipp,

kannst du zu deinem Case allgemein noch etwas sagen?
Mir ist nicht klar was du simulieren möchtest oder was in deiner Geometrie abgebildet ist (Funktionalität, was wird untersucht). Zudem stell ich mir die Frage was du mit der mapped BC möchtest?

------------------
Grüße Tobias Holzmann

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

---

schraeg.png seite.png

Hey,
also im Prinzip soll es eine Bachelorarbeit über snappyHexMesh werden. Dazu baue ich halt einen schon vorhandenen Fall nach und schaue dann inwieweit snappy verwendbar ist bzw. was für Funktionen Möglichkeiten etc. snappy bietet.

Zum Fall: Der Fall liegt schon komplett fertig als Fluent vor. Einerseits der komplette Kanal und zusätzlich noch ein Kanalsegment.
Nun ist für die Berechnung und Gittererzeugung der gesamte Kanal zu groß deshalb benutze ich auch nur ein Kanalsegment für die Berechnung.

Ein Kommilitone der auch einen (rechteckigen Kanal) in OpenFoam mit blockMesh machte meinte, dass die mapped BC dafür geeignet ist.

Die Bilder zeigen den gesamten Kanal und das Kanalsegment welches berechnet werden soll. Die Position ist eigentlich weiter hinten aber ok. Die Geometrie ist wahrscheinlich wegen den Rippen so schief.

Ich hoffe jetzt ist es klarer. Grundsätzlich will ich noch anmerken, dass das meine erste Arbeit mit OpenFoam ist also habe ich noch nicht wirklich viel Ahnung davon.
Gruß,
Philipp

[Diese Nachricht wurde von Wurstfred am 27. Nov. 2013 editiert.]

[Diese Nachricht wurde von Wurstfred am 27. Nov. 2013 editiert.]

[Diese Nachricht wurde von Wurstfred am 27. Nov. 2013 editiert.]

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

---

Hallo,

nicht wirklich.
Wo strömt was ein und wo strömt was heraus 

Eine Erklärung der Physik wäre gut. Außer du willst nur vernetzen, dann ist das ja wurst 

------------------
Grüße Tobias Holzmann

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

---

schraegstreaming.png

Hey,
hier ist nochmal ein neues Bild mit Eintritt und Austritt
Was für Infos fehlen dir denn noch, dann frage ich mal nach.

Aber vielleicht kannst du dir dann schonmal das Gitter ansehen, es ist mit snappy erstellt. Ist aber wegen der scharfen Kanten nicht gerade sehr gut.

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

---

Hi,

jetzt ist mir einiges klar geworden.
Du möchtest also nur ein "Rippenpaar" simulieren.
Wieso nicht gleich das ganze ?

Hab soeben mal deine STL geöffnet (hier im Windows Salome Programm).
Ich weiß nicht ob es ein Fehler vom Programm ist oder obs wirklich an deiner STL liegt aber Problemlos scheint mir die Datei nicht zu sein.

Ich schau heute Abend mal nochmals an meinem Rechner nach - wenn ich Zeit  finde.

------------------
Grüße Tobias Holzmann

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

---

original.stl

Hey,
cool danke schonmal   
___
Als Ausgangsgeometrie hatte ich eine .igs die ich mit ICEM in eine .stl umgewandelt habe. Diese war dann aber laut checkMesh nicht geschlossen und mit Meshlab habe ich es nicht geschafft alle Fehler zu beseitigen. Nach langem Probieren habe ich die Geometrie selbst - im CAD - nachgebaut und damit geschlossen bekommen. Das Dreiecksnetz der .stl das mir Unigraphics (CAD Siemens) erzeugt hat ist aber nicht gerade sehr gut geworden. Ich habe dir mal die original .stl Datei von ICEM angehängt.
___
Der Rechenaufwand für den gesamten Kanal wäre wahrscheinlich zu groß. Der ganze Kanal kommt dann erst noch als Zusatzpunkt in der Bachelorarbeit falls ich zeitlich schon weit genug bin.

Wie gesagt ich verwende ja die mapped Randbedingung aber bisher hänge ich da noch beim definieren des "offset" Wert. Das Problem ist, dass im Gegensatz zu anderen Geometrieen meine inlet und outlet patches nicht parallel zu den Koordinatenebenen sind. Keine Ahnung wie ich das dann mache oder ob das überhaupt ein Problem darstellt.

Gruß,
phil

[Diese Nachricht wurde von Wurstfred am 02. Dez. 2013 editiert.]

[Diese Nachricht wurde von Wurstfred am 03. Dez. 2013 editiert.]

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

---

Hallo,

das mit deiner Mapped Randbedingung scheint mir langsam einzuleuchten aber macht meines Erachtens keinen Sinn.

Wenn du durch den Kanal strömst, dann hast du pro Rippe andere Strömungseigenschaften, da du entweder Wärme ab- oder zuführst. Entsprechend ändert sich dein Fluid bezogen auf die thermodynamischen Größen wie beispielsweise Dichte, Viskosität, Leitfähigkeit, Wärmekapazität etc. Das beeinflusst dann auch entsprechend deine Geschwindigkeiten, turbulente Größen und so weiter.

Mapped Bedingung ist daher falsch. Immerhin würdest du den Outlet ans Inlet hängen und so weiter. Das du, wenn du Wärmeabführst, irgendwann gegen den Nullpunkt strebst sollte dir klar sein (insofern es ein Wärmeström ist den du abführst). Andernfalls dürfte sich dein Fluid entsprechend "unendlich" erwärmen. Das ist auch der Grund wieso ich zu Beginn nicht verstanden habe, wieso du ein Rippenpaar simulieren willst und nicht die komplette Geometrie.

Zur Geometrie selber. IGS Format ist doch super für SALOME.

IGS -> Salome -> STL

Apropos checkMesh, du meinst wahrscheinlich surfaceCheck.

------------------
Grüße Tobias Holzmann

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

---

Hab mir g erade dein Case angeschaut.
Bezüglich snappyHexMesh siehts ja schon ganz brauchbar aus. Ich würde an deiner Stelle das Hintergrundnetz noch drehen bzw. so ausrichten das du optimale Zellen bekommst.

STL File sieht hier auch besser aus (ist also nicht offen oder fehlerhaft).

------------------
Grüße Tobias Holzmann

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

---

Hey,
das mit dem gedrehten Netz habe ich auch schonmal ausprobiert.
Vom edge snapping ist es einen tick besser, Nachteile die ich dadurch erkenne sind: Dellen an noch mehr Stellen sowie kein gutes Layer adding. Die Ecken beim Layer adding gefallen mir nicht aber über den sHM Eintrag "featureAngle" verändert sich nichts.

Gruß

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

---

Deine Layergenerierung beträgt ca. 70% - 75%.

Die Dellen sollten eigentlich schon vermeidbar sein. Ich habe bei meinen Geometrie'n so etwas noch nie feststellen können.

------------------
Grüße Tobias Holzmann

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

---

Was willst du mir mit der Layergenerierung sagen?

Hast du noch eine Idee wie ich das Gitter verbessern kann?

Zwecks der BC habe ich einen Komilitonen gefragt der benutzt das auch für einen vereinfachten rechteckige Kanalströmung und meinte das es bei cyclic zu Probleme kommt da die Bedingung eine Druckdifferenz oder irgendwie in die Richtung braucht (die genaue Erklärung weiß ich jetzt nicht mehr genau). Nur leider kennt sich er auch nicht gut mit der mapped Bedingung aus und wie sie für solch schräge Patches zu verwenden ist.

Gruß

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

---

rippencase_mapped5e.zip fluent.png delle.png

Also ich habe jetzt mein Gitter nochmal ein bisschen überarbeitet und mit den "snap" Parametern gespielt. Kleine Verbesserungen habe ich hinbekommen aber nicht viel.

Ein gedrehtes Gitter wie du vorgeschlagen hast habe ich schon auch probiert (rotierter block um y Achse), aber leider auch ohne wirklich große Verbesserungen. Liegt wahrscheinlich daran, dass meine Geometrie so schief ist.

Ich habe jetzt den Case mal laufen lassen mit den mapped BC soweit ich sie konfigurieren konnte. Leider sehen meine Ergebnisse nicht wie gewünscht aus. Wenn ich die Residuen und die Werte ansehe macht mir vor allem die turbulente kinetische Energy k zu schaffen da diese einfach immer weiter ansteigt.

Aus dem Fluent Case habe ich mal eine Geschwindigkeitsverteilung angehängt. Vielleicht wirds ja doch noch was mit den mapped Bedingungen ansonsten muss ich wirklich andere verwenden, cyclicAMI würdest du auch vorschlagen oder?

Meinen Case hänge ich auch mal an vielleicht gibt es ja sonst irgendwas das nicht stimmmt.

Gruß
Phil

[Diese Nachricht wurde von Wurstfred am 11. Dez. 2013 editiert.]

[Diese Nachricht wurde von Wurstfred am 11. Dez. 2013 editiert.]

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