---

interFoam_2casees.zip

Hallo zusammen,

ich beschäftige mich jetz eine Woche exzessiv mit dem interFoam. An und für sich auch nicht schwer nur eine Problem hab ich noch.

Folgendes: Zu Beginn wollte ich eine Bierflasche simulieren die auf dem Kopf steht und beim Zeitpunkt t=0 leer läuft. Dazu habe ich
den damBreak langsam modifiziert. Bis letzten Endes alle Seitenwände zu wall und die untere Wand zu patch -> outlet umdefiniert waren und der Case das tat was er sollte nämlich, einfach das Wasser nach unten aus dem Rechengebiet herausströmen lassen.

Klappte alles wunderbar.
Eine Erweiterung von 2D auf 3D konnte ich auch ohne Problem umsetzen.

Nun folgte eine einfach Geometrieersetzung meiner Flasche. Dort lief der Case überhaupt nicht - Abbruchfehler.
Hab dann ziemlich viel versucht

- Netzverfeinerung
- Layer
- Randbedingungen

alles möglich - ging alles nicht.
#######################################################

Nach vielen gescheiterten Versuchen bin ich dann umgeschwänkt und habe den DamBreak so modifiziert das er komplett aus Wänden bestand (eine Box).
Das Wasser sollte dann einfach nach unten auf die Wandprallen und eine schöne Wasseroberfläche bilden. Ging wunderbar.

Nächster Schritt:
Ich habe ein Quader entworfen um das das gleiche durchzuführen.
Bei t=0 soll eine Wassersäule von der oberen Hälfte des Zylinders nach unten fallen.
Case läuft ohne Probleme.

Nächster Schritt:
Geometrieänderung von Quader auf Zylinder.
Hier bekomm ich bei gleichen Einstellungen und gleicher Netzqualität Probleme.

Ich häng euch mal die 2 Cases an... die Frage bleibt offen, wieso er mir bei der runden Geometrie immer davonläuft? :/
Langsam zweifel ich an meinen Kenntnissen. Möglicherweiße kann mir einer einen Tipp geben.

Hab auch schon auf das SST Modell gewechselt - auch ohne Erfolg.
Eine Verfeinerung am Zylinder (komplette Region) hat bei mir auch keine Erfolge erziehlt.

Grüße Tobi

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

---

Hallo zusammen,

ich hab mein Problem nun selber gelöst.

Es lag am Netz. Hab gerade einen Zylinder mit Salome erstellt und vernetzt (o-grid).
Die Simulation läuft perfekt.

Damit die Frage, ist es normal, dass interFoam mit einem sHM-Netz Probleme hat? Oder hab ich irgendwas falsch gemacht (nicht auszuschließen).

Jedenfalls müsste ich meine Bierflaschensimulation nun mittels einem in Salome erstelltem Netz generieren. Ist aber glaub nicht so einfach solch eine Geometrie über Salome zu vernetzen.

Wieso geht also sHM nicht?
checkMesh liefert keine Fehler ?

Grüße Tobi

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

---

Problem gelöst - ich hatte Probleme mit meiner OpenFOAM Version + zu grobes Netz.

Dank dir Thomas für deinen Durchlauf.
Grüße Tobi

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

---

OpenFOAM-2.0.x.zip

Ein Monologthreat 

ich muss mich leider korrigieren. Es war gab kein Problem mit meiner OF - Version. Teste gerade immernoch mit dem sHM - Netz und Salomenetz. Die Erkenntnis ist noch die gleiche. Auf dem Salomenetz geht alles ohne Probleme und auf dem sHM - Netz bekomm ich Probleme nach circa 0.4 Sekunden.

Anbei die checkMesh Info beider (vielleicht kann man hieraus irgendwelche Schlüsse ziehen):

SALOME NETZ

Code:

---

Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           61549
    faces:            179060
    internal faces:   173740
    cells:            58800
    boundary patches: 3
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     58800
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing 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                 
    top                 980      1009     ok (non-closed singly connected) 
    side                3360     3416     ok (non-closed singly connected) 
    outlet              980      1009     ok (non-closed singly connected) 

Checking geometry...
    Overall domain bounding box (-0.05 -0.2 -0.05) (0.05 0 0.05)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-1.231812e-15 -3.980975e-16 -3.680259e-16) OK.
    Max cell openness = 2.469776e-16 OK.
    Max aspect ratio = 3.550125 OK.
    Minumum face area = 3.713194e-06. Maximum face area = 1.869416e-05.  Face area magnitudes OK.
    Min volume = 1.237608e-08. Max volume = 3.918932e-08.  Total volume = 0.001567503.  Cell volumes OK.
    Mesh non-orthogonality Max: 35.30065 average: 7.161802
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1.287938 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

---

sHM NETZ

Code:

---

Create time

Create polyMesh for time = 0.0003

Time = 0.0003

Mesh stats
    points:           678888
    faces:            1972824
    internal faces:   1931371
    cells:            647228
    boundary patches: 6
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     622973
    prisms:        9136
    wedges:        0
    pyramids:      0
    tet wedges:    223
    tetrahedra:    0
    polyhedra:     14896

Checking topology...
    Boundary definition OK.
    Cell to face addressing 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                 
    side                0        0        ok (empty)                       
    top                 0        0        ok (empty)                       
    outlet              0        0        ok (empty)                       
    top_solid           4012     4069     ok (non-closed singly connected) 
    side_solid          21808    22500    ok (non-closed singly connected) 
    outlet_solid        15633    15918    ok (non-closed singly connected) 

Checking geometry...
    Overall domain bounding box (-0.049945 -0.2000005 -0.04998091) (0.05 3.523657e-19 0.04998091)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-6.80134e-17 1.308291e-14 8.991422e-18) OK.
    Max cell openness = 8.320153e-16 OK.
    Max aspect ratio = 38.04929 OK.
    Minumum face area = 1.911366e-08. Maximum face area = 1.392936e-05.  Face area magnitudes OK.
    Min volume = 1.688555e-11. Max volume = 3.824275e-08.  Total volume = 0.001567739.  Cell volumes OK.
    Mesh non-orthogonality Max: 64.6331 average: 5.049516
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.041445 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

---

Im Endeffekt ist das sHM Netz wesentlich feiner und auch an Wandnähe besser aufgelöst?
Der Anhang enthält auch beide Netze... für einen Tip wäre ich sehr dankbar.

       

[Diese Nachricht wurde von Shor-ty am 30. Okt. 2011 editiert.]

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

---

Hallo Tobi, ich bringe mich mal zum Monologthreat ein:
Ich habe bei interFoam folgendes, möglicherweise ähnliches Problem. Sobald die flüssige Phase auf den Boundary Layer trifft, läuft die Co-Number hoch und somit die Zeitschritte runter, was dann zum Abbruch führt. Verwende ich aus SnappyHexMesh das "erste" Netz der drei, so habe ich das Problem nicht. Es muss also an den Oberflächenanpassungen liegen?
Weiterer Hinweis: Angeblich bestand das Problem bei 1.4.1 nicht, da gab es aber auch noch keine Wandfunktionen?
Vielleicht hilft das weiter, falls ja, dann schreib doch mal eine Lösung.
Beste Grüße
Stephan

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

---

Du meinst die Wandfunktionen der Turbulenzmodelle?
schon mal versucht laminar zu rechnen? 

Ich werde deine Hinweise versuchen umzusetzen, wenn ich meinen Case noch habe.
Du hast das Problem nur bei einer lokalen Verfeinerung der Wandschicht?

Ich sollte mal versuchen mit Tetraedern zu vernetzen (mit Salome) und nen Teset machen.
Danke für die Monologunterbrechung 

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

---

Welche Dateien genau möchtest du von mir?

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

---

Zitat:

---

Original erstellt von uhkoetter:
Verwende ich aus SnappyHexMesh das "erste" Netz der drei, so habe ich das Problem nicht. Es muss also an den Oberflächenanpassungen liegen?
Weiterer Hinweis: Angeblich bestand das Problem bei 1.4.1 nicht, da gab es aber auch noch keine Wandfunktionen?
Vielleicht hilft das weiter, falls ja, dann schreib doch mal eine Lösung.
Beste Grüße
Stephan

---

Hey Stephan,

meinst du mit "erstem" Netz das durch castellated erzeugte Netz? Hast du dann auch versucht es mit Netz 2 zu simulieren. Sprich mit der Eigenschaft des Snappens? Wär sehr interessant zu wissen. Ich glaub ich muss mich erneut auf meine Bierflasche stürzen. Leider ist meine SalomeFile nich mehr da und ihc müsste mir ne neue Flasche bauen. Ggf. versuch ich mal mit Salome ein Tetraedernetz. Wenn ich heut Abend nicht zu müde bin, dann werd ich das mal testen.

Das mit den Wandfunktionen // Boundarylayer is ne interessante Tatsache, die man näher betrachten kann. Ist dein Fall komplexer oder wie bist du auf diese Fehleinflüsse gekommen?

Hmm ... ich bin immer noch schwer der Meinung, dass es (wie du bereits erwähnst) die Randzellen von sHM sind, die zu Problemen im interFoam Solver führen.

Grüße Tobi

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

---

Hey zusammen,

ich habs mit m interFoam nun raus.
Die Co-Zahl muss ab und zu bei 0.05 liegen damit der Solver nicht abbricht. Zudem sind die RB wichtig!
Was ich noch feststellen musste ist, dass der interFoam Solver besser und stabiler mit dem kEpsilon Modell läuft.
Das habe ich aber noch nicht so ergiebig getestet da mein 6 Kern Rechner nicht so ideal für solche Strömungen ist (zu wenig Leistung).

für Videos - www.holzmann-cfd.de/videos 

Grüße Tobi

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

---

Hallo!
Sorry dass ich den alten Thread nochmal aus der Versenkung hole, aber ich habe mit ähnlichen Problemen zu kämpfen gehabt und habe deswegen eine Idee für Lösung des ganzen.

Der VOF-Lösung hat Terme zur Schärfung der Fluidoberfläche. Diese zusätzlichen Terme können jedoch starke Oszillationen hervorrufen.
Geringere CO Zahlen und Turbulenzmodelle können helfen, was aber der eigentliche Auslöser ist ist die Aspect Ratio der Zellen.
Das erklärt auch, warum deine erstes Mesh (Aspect ratio Maximal 3) funktioniert, dein zweites (Aspact ratio 38) aber zusammenbricht. Meine persönliches gefühl war, dass die Aspect Ratio von im Mittel unter 2.5 noch funktioniert, während Werte über 7 immer schiefgegangen sind.

Eine einfache Methode, um festzustellen, ob die Schärfung das Problem ist, ist cAlpha in fvSolution auf 0 zu stellen. Wenn dann ein zwar schwammiges, aber stabiles und halbwegs plausibles Strömungsbild rauskommt, sobald man 1 setzt, das ganze zusammenbricht, dann ist es hier ein Aspect Ratio Problem. Z
Zudem kommt, dass der Löser bei schlechter Aspect Ratio nicht mehr in der Lage ist, Wände mit Medien, die eine höhere relative Dichte haben (zB Wasser bei Wasser-Luft) zu benetzen. Das führt zu einem Luftfilm an den Wänden, der z.B. die Kraftübertragung deutlich reduzieren kann.

Nochmal kurz: checkMesh akzeptiert bei Quads jede aspect ratio, für interFoam ist das aber falsch und große Ratios sind fatal!

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

---

Hallo und danke für den sehr interessanten Beitrag.
Meine Simulation lief in OpenFOAM-2.2.x dann ohne Probleme / gleiches Netz nur der Algorithmus von sHM wurde verändert.

Es lag aber definitiv am Netz. Mit welcher Aspect Ratio ich am Ende gerechnet habe, weiß ich nicht mehr aber sicherlich nicht < 5

Zitat:

---

kurz: checkMesh akzeptiert bei Quads jede aspect ratio, für interFoam ist das aber falsch und große Ratios sind fatal!

---

Man kann die allgemeinen Bedingungen umändern.

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

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

---

Zitat:

---

Es lag aber definitiv am Netz. Mit welcher Aspect Ratio ich am Ende gerechnet habe, weiß ich nicht mehr aber sicherlich nicht < 5

---

Wenn die Courant-Zahl klein genug ist, klappen auch zunehmend größere Aspect Ratios. Meine Angaben dazu beziehen sich auf ein maxCo von 0.5

Zitat:

---

Man kann die allgemeinen Bedingungen umändern.

---

Wie genau ist das zu verstehen?

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

---

Hi,

du meintest ja das blockMesh alle ApsectRatio akzeptiert.
Die Angabe ab welchem AR checkMesh einen Fehler ausgibt kann man einstellen.

Um nochmals auf deine Aussage Bezug zu nehmen.
Die Randzellen bei mir waren sicherlich Schuld an dem Versagen des Algorithmus.
Da ich Grenzschichten hatte, kann es gut sein das mein AR in einem Intervall war, das unzulässig ist.

Dein Tipp/Erkenntnis ist jedenfalls sehr hilfreich!

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

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

---

Ich hatte mit dem Problem und seinen Auswirkungen noch weiter zu kämpfen, deswegen habe ich bei meinem Fall mal systematisch verschiedene AspectRatios durchprobiert.
Die Resultate in Abhängigkeit von der AR waren jedoch komplett unerklärlich.

Was bei mir rauskam war, dass es nicht nur auf die AR ankommt, sondern auch darauf ob die maximale Streckung der Zellen normal oder tangential zur Bewegungsrichtung der Oberfläche war.

Die Ergebnisse finden sich hier: http://www.cfd-online.com/Forums/openfoam-solving/126211-interfoam-simulation-yields-inconsistent-results-alpha1-surface.html

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