---

0.93.PNG 0.94.PNG

Hallo Leute,

ich habe ein Problem.
Bei meiner einfachen Testsimulation mit einem konstanten Druckrand links und 2Phasenmodell, bricht die Rechnung nach einer gewissen Zeit ab. Darauf hab ich die bis dorthin gerechneten Ergebnisse betrachtet.
Dabei habe ich festgestellt, dass sich im Zeitschritt des Rechenabruchs eine Artdruckexplosion ausbildet.
(Siehe Bilder)
Ich wollte wissen, ob einer weiß woher diese kommt, bzw. wie ich die Simulation verändern muss.
(Solver ist InterFoam)
[URL=INTERNETADRESSEHIER][http://www6.picfront.org/token/zDme/2015/06/04/2213202.png/URL]

Danke

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

---

Hallo,

wenn ich mir das 1. Bild ansehe, ist der Druck links schon zu Anfang nicht konstant (1. Bild).  Dann kann auch eine konstant Druckrandbedingung nicht funktionieren.

Ulrich

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

---

Hey Ulrich,
Vom linken Rand ausgehend bis zu höchsten Punkt rechts, ist per setFields ein fester Wasserstand vorgegeben. Und da P=rho g h resultiert natürlich in unterschiedlichen Wassertiefen ein verschiedener Druck.

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

---

Dann wird aber auch der Druck p_rgh nicht in dem Rand links konstant sein können: Wenn g die Masse unten beschleunigt, wird sich eine ungleiche Geschwindigkeitsverteilung einstellen, die zu einem Druckprofil am Rand links führen wird. Was man möglicherweise machen kann, ist den Totaldruck am Rand links konstant zu setzen.

Ulrich

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

---

Ich misch mich auch mal wieder ein    

Total Pressure wird dir hier auch nicht helfen, wenn du für p0 EINEN (also nur einen Wert) für alle Faces verwendest. Du solltest also eine <List> verwenden, die den Druck für jedes Face enthält (also um den hydrostatischen Anteil verringert oder erhöht, je nach Referenzpunkt). Möchte man das nicht händisch machen, kann dies ganz schnell mit einer temporären Simulation herausgefunden und via Copy-Paste von diesem Fall auf den anderen übertragen werden. Mit ein bisschen Nachdenken, findest  du das sicher gleich heraus.

Ansonsten verwende den "Banana-Trick". Danach wirst du sehen, dass es auch interessantere RB gibt. Bspw. die prghPressure BC oder andere.

Gleiches Problem kannst hier sehen:
Wassersäule

Apropos... deine Darstellung des Druckes scheint mir eher proportional zum Wasserstand zu sein (ergo keine Druckwelle). Möglicherweise kollabiert deine Kontinuität und du erhältst irgendwo ne rießige Inflow-Welle von Wasser. Wäre also interessant dein Alpha.water zu dem Zeitpunkt zu sehen. Genauso wie die Geschwindigkeit.

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

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

---

Das Komische dort sieht alles normal aus.
Der Fortschritt des Wasser ist normal und die Geschwindigkeit auch.

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

---

Dein 2d case kannst du ja mal hochladen.

Verwendets du den MomentumPredictor?
Pimple oder Piso
Wie is deine Kontinuität, Zeitschritt, Co-Zahl ... sind alles Indikatoren

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

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

---

0.zip system.zip

Leider ist das 3D Modell zu groß (18MB komprimiert), deshalb mal nur "0" Ordner und "system" Ordner.
Darin muss sich der Fehler befinden.
Es bricht einfach nach einer gewissen Zeit ab, obwohl das Wasser bereits ins Haus strömt.
Es soll nur Wasser durch die Tür ins Haus fließen.
Haus kein Wasser zu Beginn, Wasser mittels setFields ums Haus 0,5 m über OkFF (Fußboden).

Danke schon mal

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

---

constant.zip

Mir fiel noch ein wie ich euch doch den constant Ordner geben kann.
Bitte blockMesh und snappyHexMesh dazu nocheinmal durchführen.

Ich bin sehr gespannt auf eure Antworten.

Grüße aquamen

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

---

Hey

hätte einige Anmerkungen aber das erste was mir direkt ins Auge sticht ist:

• maxCo auf 1 im PISO Mode?
  
• bei deinen RB bin ich mir auch sicher das das nich funktioniert
  

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

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

---

Ach ja noch was...

du zerlegst deinen Case von nur 400.000 Zellen auf 100 Kerne ?
Da gibts einiges zu korrigieren in deinem Case.

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

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

---

Die Aufteilung erfolgt erst später bei einem deutlich umfangreichern Modellkörper mit mehr als 5Mio. Zellen.

Dies hier ist nur zur Kalibrierung der Randbedingungen und rechnet nur auf einem Kern.
Der decompose Part ist nur schon drin für später.

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

---

Hallo Aquamen,

dann ist das mit den Kernen klar, gut. Allerdings sind 100 Kerne auf 5.000.000 Zellen auch recht viel. Bitte bedenke das du möglichst wenig processor Faces generierst, sonst wird die Rechnung wesentlich langsamer, da die Kosten in die Kommunikation der Kerne geht. Da ist dann vor allem die Strategie, welche zum Zerlegen der Domain genutzt wird, entscheidend. Möchte dich hierauf nur aufmerksam machen. Zudem kannst du mit einem Tool (renumberMesh) deine Matrizen neu anordnen und somit einen Boost (hier am Lehrstuhl mal getestet) bis zu 20% erreichen.

Deine Geometrie ist soweit in Ordnung allerdings ist das Modell (definiert durch deine Randbedingungen) mathematisch und physikalisch nicht sehr sinnvoll. Unten werde ich eine Auflistung machen und später noch ergänzen nachdem ich deinen Case bereinigt habe (kann aber nich versprechen ob ich dafür Zeit finde).

• nCellsBetweenLayers 1; kann man machen aber ist oft nicht die beste Wahl (in deinem Fall okay)
  
• *.eMesh hast du hoffentlich kontrolliert. Falls nicht - es passt alles
  
• allowFreeStandingFaces true; ich bevorzuge false (Mehr Infos in der Präsentation von Engys -> foamwiki -> snappyHexMesh)
  
• multiRegionSnap true; da du dich nicht im cht bewegst, bitte auf false stellen
  
• deine Region die du in sHM erstellst ist sinnfrei (aber das weißt du wahrscheinlich selber)
  
• deine controlDict ist okay aber Co = 1 bei PISO ist nicht drin; allerdings hast du die Co indirekt limitiert, da du nur alle 0.01s speicherst und somit dT klein bleibt; allerdings solltet du das beachten
  
• fvSolution; hier ist deine Einstellung auf PISO, hab das mal auf einen PIMPLE umgestellt um die Konvergenz zu verbessern --> Infos auf cfd-online.com --> Tobi --> Blogs. Das hab ich damals auch ins openfoam WIKI gesetzt
  

Physikalische und mathematische Betrachtung

• Deine Ränder sind alle zeroGradient außer Top. Das lässt sehr viel Spielraum für deine Simulation (mathematische Lösungen -> instabil)
  
• Auf Grund vom ersten Punkt kannst du davon ausgehen, dass deine Ränder nicht gerade sehr physikalisch sind. Wenn du die Simulation beginnst solltest du dir die Frage stellen, welchen physikalischen Effekt die Wasserhöhe konstant lässt, bzw. was dahinter steckt! Wenn du eine kleine Instabilität bei deinen ganzen ZeroGradienten BC reinbekommst, dann wird die Rechnung einen Gleitkommafehler aufzeigen. Natülich ist es das einfachst alles auf zeroGradient zu stellen aber das zeigt eher eine Unwissenheit in der physikalischen-mathematischen Modellierung auf.
  
• Bezogen auf vorherige Anmerkung: Solltest du aus irgendwelchen numerischen Gründen einen Druckgradienten am Rand bekommen, erhältst du sofort ein Inflow oder Outflow, der instabil wird und alles durcheinander wirft.
  
• Um physikalisch realistisch zu bleiben bedarf es weiterer Patches, die bspw. genau einmal um deine Domain gehen und einen Abstand z=0 bis z=0.7 haben
  
• Deine Ränder (zmin, zmax, xmin, xmax, ymin, ymax) sind keine type wall sondern patches. Das hat allerdings nur Auswirkungen auf deine Turbulenzmodelle.
  
• Die Geschwindigkeit an deinem Haus beträgt (0 0 0)^T und nicht zeroGradient
  
• p_rgh sollte für Wände eine fixedFluxPressure BC aufweisen (Details findest du in der Headerdatei)
  

Ganz essentiell ist die Sache mit der fvSolution und den RB
Bedarf jedoch das Verständnis von den mathematischen Methoden (oder besser es wäre Vorteilhaft).
Gute Literatur findest du auf meiner Homepage, oder allgmein im cfd-online.com, foamwiki etc.

Wie bereits gesagt gibt es (hoffentlich) später deinen Fall.

In dem Sinne hast du jetzt schon einiges an Input.

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

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

---

Vielen vielen Dank dafür erst einmal.

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

---

Hallo Aquamen,

also ich hab die letzten zweit Tage mal einiges getestet und die Physik dahinter analysiert (ist machmal tricky mit dem p_rgh, wobei ichs jetzt endgültig gecheckt hab).

Also du kannst folgendes machen um deinen Wasserstand konstant zu halten...

Variante 1:
Ist die schnellste aber auch sehr instabil.

• setSet
  
• faceSet f0 new
  
• faceSet f0 add boxToFace (x y z) (x y z)
  

Du machst dir damit ein neues Faceset und zwar genau an einen Einströmrändern (xmin, xmax, ymin und ymax) und zwar machst die Box um ein paar Faces niedriger wie dein offizieller Wasserstand ist. Mittels createPatch kannst du dann eine neue Boundary erstellen. D.h. du hast dann anstelle xmin eben ein patchXY und xmin, check?

An diesem patchXY setzt du für

• U: pressureInletOutletVelocity
  
• p_rgh: fixedValue mit einem Wert den du dir berechnen musst (später)
  
• alpha.water: inletOutlet mit inletValue 1
  

Ich empfehle den statischen Druck auf deinen Patch "Atmosphere" auf 0 zu setzen. Das machst du mit der Randbedingung prghPressure.

Zudem solltest du dann xmin xmax ymax ymin als undurchlässige Wand definieren, sonst bekommst du nur Probleme.

Variante 2 und 3

Du erweiterst deine Geometrie auf allen Seiten um ein L -Profil, check?

Code:

---

            < Aktuelles Ende

          |
          | --  --  --  --  --  --  --  -- << Wasserstand
  p1      |
----      |
|    |    |
|    |    |
|      ----
|
|________________________________________________________

---

Auf p1 kannst du dann gemütlich prghPressure oder phaseHydrostaticPressure verwenden. Aber bitte beachte das du bei letzterer BC nicht den hydrostatischen Druck vorgibst, da du diese Randbedingung nicht bei p verwendest sondern bei dem pseudo Druck p_rgh. Den kannst du aber auch ganz simple berechnen. Zudem würd ich dir wieder raten prghPressure für deine Atmosphere zu verwenden, um den statischen Druck p auf diesem Patch auf 0 zu setzen. Also äquivalent zum ersten Vorgehen. Ansonsten musst du immer darauf achten ob da jetzt noch rho*g*h dabei ist oder nicht (Skizze hilft), check?

Damit dürfte das Problem der RB gelöst sein.

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

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

---

Haus.png

Nachtrag

Ich hab mal deine Simulation entsprechend Vorschlag 1 umgebaut.
Ist alles stabil und das Ergebnis nach 0.28s sieht wie im gezeigten Bild aus.

Da ich weiß, dass es nur ein Test ist, würde ich aber das Wasser, welches das Haus umgibt, gar nicht modellieren.
Nur den Teil vor der Türe. Spart dir einiges an Kosten. Zudem ist dein Haus oben "offen"; heißt die Luft kann einfach oben
entweichen aber das weißt du sicher auch (:

In dem Sinne ist das für mich abgeschlossen.

Viel Erfolg.

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

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

---

Danke dafür ich werd es mir am Monatg mal vornehmen und dann eine Resonaz dazu geben.

Schönes Wochenende wünsch ich dir.

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

---

An Shor-ty

So also ich habe deine Variante 1 mal umgesetzt, allerdings kommt dort wie zuvor auch schon, der Abbruch bei ca. 0,4s Simulationszeit. Komisch ist, das im letzten Rechenschritt die Courant Zahl 1 auf über 8800 springt.

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

---

Hallo,

Werde, nachdem mein System wieder steht, deinen Vase über Nacht mal rechnen lassen. Wir sehen ja dann wie es aussieht. Die residuen waren nämlich auch wunderbar. Gibt also keinen Grund wieso das instabil werden sollte.

Morgen mehr.

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

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

---

Wäre es möglich das Log-File zu posten. Danke.

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

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

---

HausFlooded.png

Hallo,

also bei mir läuft es seit heute Mittag und t > 6s. Anbei ein Ausschnitt des Simulationsstatus. Ich lass die Rechnung über Nacht laufen aber numerisch sollte da alles stabil bleiben.

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

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

---

Das sieht erstaunlicherweise sehr gut bei dir aus. Ich stell dir den Log-File und meine Daten ohne Zip morgen früh nochmal rein. 

[Diese Nachricht wurde von aquamen am 17. Jun. 2015 editiert.]

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

---

test.zip

Hallo

hier mal der Log-File und die Fehlermeldung, sie befinden sich in dem Ordner mit samt den Einstellungen und Randbedingungen. Die Netz- und Geometriedaten habe ich rausgenommen.

Vielleicht findest du den Unterschied /e zwischen unseren Simulationen.

Wenn es dir nichts ausmacht, kannst du mir deinen Simulation ja auch zukommen lassen und ich vergleiche mal.

Viele Grüße
Hendrik

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

---

Hey,

ohne Netz ist das immer ne vage Sache.

• Was ist jetzt outlet
  
• Inlet, wie hoch?
  
• Wieso LES?
  

Dein Fall würde ich gerne in meine Tutorial-Sammlung aufnehmen.

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

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

---

Das Netz gibt es morgen und LES ist es doch schon die ganze Zeit.

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

---

• Wieso LES?
  
• RANS wars am Anfang mit kEpsilon
  
• Wieso rechnest du nicht laminar?
  

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

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

---

Moin,

Tatsache, ich hab mir grad den alten constant Ordner noch einmal angeschaut, da ist wirklich eine RAS-Modell drin.

Bei der Ausarbeitung, will ich aber eigentlich ein LES Modell verwenden, da für das eigentliche Haus ein Haus mit Keller geflutet werden soll. Und um dort die Wirbel auch im Bereich der Treppe gut abbilden zu könne, soll es ein LES Modell sein. Sorry dafür.

Das Testhaus kannst du natürlich gern in deine Tutorialreihe aufnehmen, es ist ja frei erfunden.

[Diese Nachricht wurde von aquamen am 18. Jun. 2015 editiert.]

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

---

Hmmm wenn du LES in diesem Modell rechnest, brauchst du aber schon ein sehr feines Netz um die großskaligen Turbulenzwirbel aufzulösen. Was erhoffst du dir denn daraus? Ich meine, die Berechnung mit RANS (ggf. auch laminar) sollte doch genügen. Wie das Wasser nun die Treppe herunterfließt (ob besser aufgelöste Turbulenz oder nicht) spielt doch keine Rolle. Du hast weder Stoff, noch Wärmeübertragung, deswegen bin ich etwas erstaunt, wieso du LES verwendest.

Vllt. kann Thomas hierzu ja noch etwas mehr Details geben, da ich mit LES noch nicht viel simuliert habe.

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

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

---

So um abzurunden:

Video
Kellerflutung Tutorial

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

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