---

testpipe.zip

Hallo zusammen,

ich habe eine trial version von Cubit ausprobiert und habe dazu ein paar Fragen, die ich nirgends in der Hilfer oder in den Tutorials finden konnte.

Wenn man strukturiert vernetzen möchte, muss man seine komplexe Geometrie so entsprechend zerteilen, dass dann am entsprechenden Volumen ein meshing sheme funktioniert und Cubit ein hex Netz in das Volumen reinlegt. So zumindestens habe ich den Ansatz von Cubit verstanden. Geht in die Richtung von Icem, nur hier legt man direkt an der Geometrie an Hand. Jetzt zu meinem Problem: Wennn ich das so mache erzeuge ich viele kleine Voluminas mit vielen kleinen Flächen im internen Fluidraum. Wenn ich das Netz im Fluent Format rausschreibe, dann sind sämtliche nicht definierten Flächen als Wände definiert. Ich habe mal ein File drangehängt. Es handelt sich hierbei um einen Zylinder. Wie man am boundary File von OpenFoam sieht, hat er zusätzlich zu meinen patches noch wall_1 drangehängt. Es müssten die 4 Flächen im Inneren der Geometrie/Netzes sein.

Meine Frage: Wie geht man in Cubit vor um ein Netz für OpenFOAM zu erstellen? Bzw. wie vermeidet man der Konvertierung nach OpenFOAM zusätzliche Patches, die im Fluidraum sind? Kann man das abschließende Netz irgendwie "zusammen kleben"? Für Anregungen und Hilfe wäre ich dankbar.

Weiß jemand wie lange die Trial Version gültig ist? Ich kann keinen Zeitlimit erkennen?

Danke und viele Grüße
pajofego   

[Diese Nachricht wurde von pajofego am 13. Jul. 2011 editiert.]

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

---

Habe leider keine Erfahrung mit Cubit aber mal eine generelle Anmerkung:

Immer wieder tauchen Fragen auf zur Gittererstellung mit Cubit, Salome oder Konvertiereung von Fluent oder Star Gittern.
Warum wird so selten snappyHexMesh benutzt? Ich vergitter seit 5 Jahren meine Geometrien durchweg mit snappy bzw dem Vorgänger ohne größerer Probleme. Gitter die ok aus snappy kommen haben die Garantie vernünftig mit OF zu laufen, zumindest was die Qualität angeht.

Gruß
Thomas S

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

---

Cubit.jpg

Hallo,

du hast wahrscheinlich noch ein Schritt in CUBIT vergessen:

Imprint/Merge auszuführen.

Danach kannst du einfach das netz als Fluent msh exportieren.

Gruß Thomas

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

---

Hallo,

@TTB: danke, dass hat funktioniert.

@t.schumacher: prinzipiell gebe ich dir recht. Ich hatte noch keine Zeit gefunden mich näher mit snappy zu beschäftigen. Den Einarbeitungsaufwand schätze ich deutlich höher ein als mit cubit. Darüber hinaus konnte ich noch kein Beispiel/Tutorial finden, mit dem ich sicher zum Ziel kommen würde. Ich kann dir gerne meine Geometrie zur Verfügung stellen, vielleicht kannst du mich von der Einfachheit/Überlegenheit von snappy überzeugen. Dann würde ich auch mal sehen wie das für meinen Anwendungsfall gehen würde.

Danke und Gruß
pajofego

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

---

Nachdem t.schumacher nicht auf mein Angebot eingegangen ist ;-) habe ich mich mit Hilfe von discretizer an das Thema snappyhexmesh versucht. Das hat soweit erst einmal geklappt. Das Netzt sah jetzt nicht schön aus, lag wahrscheinlich auch daran, dass ich mich noch nicht mit allen Optionen auskenne. Jetzt aber mal eine dringende Frage: Wie präge ich die Randbedingungen auf meine Geometrie auf? Die Geometrie habe ich in salome erstellt, dort groups definiert und via stl exportiert. Dumm nur, dass diese nicht mit im stl file genommen werden. Wie mache ich das jetzt, s.d. inlet, wall, outlet, etc. auf die richtigen Flächen kommen?

Danke.
Gruß
pajofego 

[Diese Nachricht wurde von pajofego am 21. Jul. 2011 editiert.]

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

---

Am besten ist du exportierst eine extra stl für jede Randbedingung. Also arbeitest mit inlet.stl, outlet.stl, wall.stl  usw.

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

---

Danke. Das hat schon mal funktioniert! Netz erscheint mir soweit in Ordnung. Frage:

An welchen Parametern muss ich schrauben, damit gewisse Geometrieteile feiner vernetzt werden? Bzw. hat ein feineres Blockmesh irgendeinen Einfluss auf das hex mesh beim snappen?

Kanten und Ecken sind nicht immer sauber geschlossen. Gibt's ein tool um im Nachgang die Oberfläche zu glätten?

Danke. Gruß
pajofego

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

---

Snappy nutzt immer das blockMesh als Basis für Verfeinerungen. Wenn also das blockMesh feiner ist dann auch das aus snappy.
Snappy bietet eine Reihe von Möglichkeiten lokale Gitterverfeinerungen zu erzeugen. http://www.openfoam.com/docs/user/snappyHexMesh.php

Was meinst du mit nicht geschlossen? Bild?

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

---

snappyhexmeshdetails.png

Hi,

so jetzt habe ich mein erstes Netz mit snappyhexmesh erstellt und anschlißend mit reactingfoam getestet. Leider habe ich ständig ein boundig Problem was zu einem späteren Zeitpunkt zu einem floating point Problem führt. Meine Erfahrung lehrt, dass das ein Netzproblem wg. einzelner bösen Zellen zurück zu führen ist. Anbei ein Bild vom Netz wo ich mir nicht ganz sicher bin ob das ein Darstellungsproblem ist oder das Netz wirklich so spitze Dreiecke hat?!? Jetzt bräuchte ein paar Tipps wie man die Qualität des Netz erhöhen kann. Ich konnte da nicht die richtige Stellgröße finde.

Hier mein checkMesh output:

Code:

---

Time = 3

Mesh stats
    points:          1174678
    faces:            3008449
    internal faces:  2849768
    cells:            929928
    boundary patches: 10
    point zones:      0
    face zones:      0
    cell zones:      0

Overall number of cells of each type:
    hexahedra:    695666
    prisms:        33990
    wedges:        0
    pyramids:      0
    tet wedges:    1506
    tetrahedra:    1
    polyhedra:    198765

Checking topology...
    Boundary definition OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
    Patch              Faces    Points  Surface topology                 
    maxY                0        0        ok (empty)                       
    minX                0        0        ok (empty)                       
    maxX                0        0        ok (empty)                       
    minY                0        0        ok (empty)                       
    minZ                0        0        ok (empty)                       
    maxZ                0        0        ok (empty)                       
    stlSurface_OUTLET  13033    14267    ok (non-closed singly connected) 
    stlSurface_INLETGAS 728      841      ok (non-closed singly connected) 
    stlSurface_INLETSECONDAIR251      349      ok (non-closed singly connected) 
    stlSurface_SURFACE_CYL144669  169226  ok (non-closed singly connected) 

Checking geometry...
    Overall domain bounding box (-0.000101361 -168.893 -167.068) (450 157.091 200)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (1.45906e-19 1.63032e-18 2.64268e-19) OK.
    Max cell openness = 3.95681e-16 OK.
    Max aspect ratio = 28.9494 OK.
    Minumum face area = 0.0191346. Maximum face area = 185.1.  Face area magnitudes OK.
    Min volume = 0.00600324. Max volume = 1812.1.  Total volume = 1.77669e+07.  Cell volumes OK.
    Mesh non-orthogonality Max: 64.8618 average: 10.9572
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.32497 OK.

Mesh OK.

---

Danke und Gruß
pajofego

P.S.: snapEdge sollte mein o.g. Problem/Frage lösen, leider stürzt das bei mir ab. Evt. muss ich noch ein bischen testen.

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

---

Hallo,

abgeleitet von dein checkMesh scheint dein Netz in Ordnung zu sein. "Aspect Ratio" empfinde ich persönlich als sehr hoch, aber da meckert OF nicht herum. Ist ja auch nur das Maximum.

Die Anzeige ist typisch für ParaView. Nicht abschrecken lassen.

Wenn du die OF Version 2.0.x verwendest bräuchtest du snapEdge nicht mehr.

Wegen deines Bounding-Problems muss es nicht zwangsläufig am Netz liegen. Schon all die anderen Tipps hier im Forum ausprobiert?

Gruß Thomas

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

---

fvSchemes_buoyant.txt fvSchemes_reactingfoam.txt

Hi,

danke für deine Hinweise. Ich hatte schon mehrmals versucht an den skewness Parametern zu schrauben, um die max. skewness auf unter 1 zu drücken. Ist das denn überhaupt notwendig?

Ich verwende noch of 1.7.1. Ich wollte demnächst auf 2.0 updaten.

Zum Bounding Problem hätte ich dann doch eine generelle Frage. Hintergrund des ganzen threads - strukturiertes Vernetzen - war mein gescheiteter Versuch mein Fall zum Laufen zu bringen, da ich ständig ein floating point error auf Grund von zu großen numerischen omega Werten in bestimmten Zellen hatte. Leider passiert das mir nun auch mit dem snappyhexmesh. Ich habe sämtliche Tipps, die ich auf cfd-online finden konnte ausprobiert. D.h. so ziemlich alle Limiter die OF zur Verfügung stellt ausprobiert. Auch alle möglichen Turbulenzmodelle habe ich durch. Bis jetzt hat nichts geholfen. Ich hänge mal meine zwei fvschemes file für die buoyant und reactingfoam solver mit denen ich immer gerechnet habe bei. Wenn du mir noch ein paar wertvolle Tipps geben könntest wie man am besten das Bounding Problem in den Griff bekommt, wäre ich dir sehr dankbar. Ich hatte auch schon hier gesucht, aber so richtig erfolgreich war ich nicht mit den Tipps hier?!?

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

---

Hallo,

welchen Solver verwendest du jetzt?

Probiere mal folgendes aus:

nNonOrthogonalCorrectors auf mind. 1 setzen.

Um Bounding zu verhindern, kann man die Divergenzschemata auf "upwind" setzen ->

div(phi,k)      Gauss upwind;
div(phi,epsilon) Gauss upwind;

Mit PotentialFoam Geschwindigkeiten und Druck vorab abschätzen.

Stimmen denn die RB für k und Omega? Sind die Werte schon vorab falsch?

Das Netz nochmal mit snappy erzeugen aber ohne die dritte Stufe (Layer). Geht dann die Rechnung?

Ein Skew-Faktor von fast 1 zu bekommen ist kaum mit snappy möglich.

Gruß Thomas

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

---

Hi TTB,

nNonOrthogonalCorrectors ist bei mir auf mindestens 1 habe das ganze schon bis faktor 3 ausprobiert.

upwind schemes in den divSchemes habe ich auch schon ausprobiert, deswegen sind diese in meinen Files auskommentiert. Das Initialisieren der Geschwindigkeitsfelder über Potentialfoam habe ich auch schon gemacht...hat nicht zum Erfolg geführt. Dennoch ist mir eine Sache aufgefallen. Wie kann man die Druckfelder aus potentialfoam für einen kompressiblen Solver benutzen? Da hatte sich reactingfoam beschwert.

Ich benutze generell reactingfoam, bevor ich aber diesen starte möchte ich mit dem buoyantBoussinesqSimpleFoam solver schauen, ob ich meinen Fall durchgerechnet bekomme.

Eine Fehlerquelle könnten evt. die Startbedingungen für die k-epsilon/omega Werte sein. Ich rechne diese zwar für Inlet aus, aber was ist mit den Wertne für die Wall Funktionen? Wie ermittelt man diese am besten?

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

---

Hallo,

kannst du mir dein Case zukommen lassen?

Gruß Thomas

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

---

@TTB,

ja das mache ich gerne. Kannst du mir bitte deine e-mail per PM schicken? Ich lass dir dann ein Download Link mit Zugang zukommen.

Danke und Gruß
pajofego

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