Autor
|
Thema: positive/negative Geschwindigkeit inlet/outlet (1127 mal gelesen)
|
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 03. Dez. 2020 11:25 <-- editieren / zitieren --> Unities abgeben:
Hallo liebe Community, ich möchte einen Luftstrom in einem Raum simulieren, der drei Öffnungen haben soll: 1. inlet: definierte Einströmgeschwindigkeit (Luft wird hineingepumpt) 2. outlet: definierte Ausströmgeschwindigkeit (Luft wird abgesaugt)--> die Volumenströme (1) und (2) sind nicht zwangsläufig gleich 3. eine Öffnung, die Leckage abbilden soll und die Überbestimmung des Systems verhindert. Die Luft kann als inkompressibel angenommen werden. Mein Ansatz ist, mit dem simpleFoam solver folgende Randbedingungen vorzugeben: 1. inlet: U -> fixed value (Vektorrichtung in den Raum); p -> zeroGradient 2. outlet: U -> fixed value (Vektorrichtung aus dem Raum hinaus); p -> zeroGradient 3. leckage: U -> pressureInletOutletVelocity; p -> fixedValue das funktioniert auch, allerdings bricht die Berechnung immer nach einiger Zeit ab und die Ergebnisse sind auch nur in den ersten paar Berechnungsschritten plausibel. Die Abbruchsfehlermeldung lautet: wrong token type - expected Scalar, found on line 0 the word 'nan' Hat jemand hier vielleicht eine Idee, was ich ändern kann, um die Berechnung zur Konvergenz zu bekommen? Bzw gibt es für meine Problemstellung eine bessere Herangehensweise als die von mir beschriebene? Ich bin noch in meinen OpenFoam-Anfängen und leider noch nicht so fit in der Fehleranalyse. Grüße und danke Moritz Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Friendly Mitglied
Beiträge: 69 Registriert: 05.06.2017
|
erstellt am: 03. Dez. 2020 17:17 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Hi, ich kenne mich nicht wirklich mit inkompressiblen Simulationen und den entsprechenden sovlern aus. Allerdings meine ich, dass die gängige Variante an Randbedingungen wie folgt aussieht: Inlet: u- zeroGradient und p fixed value Outlet: u - fixedValue und p zeroGradient Ich glaube, dass deine Randbedingungen keinen Sinn ergeben hinsichtlich der Energieerhaltung. Wie groß ist denn dein Totaldruck? Der könnte etwas zwischen 0 und unendlich sein, ist aber undefiniert. Wahrscheinlich bricht deswegen deine Simulation ab, weil irgendwann unplausible Zustände entstehen, die sich selbst wiedersprechen.
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 04. Dez. 2020 07:21 <-- editieren / zitieren --> Unities abgeben:
Hi Friendly, danke für deine Antwort. Zitat: Allerdings meine ich, dass die gängige Variante an Randbedingungen wie folgt aussieht:Inlet: u- zeroGradient und p fixed value Outlet: u - fixedValue und p zeroGradient
Ja, das ist auch nach meinem Kenntnisstand die gängige Variante. Allerdings sieht mein Fall in Wirklichkeit leider wie beschrieben anders aus und ich dachte ich könnte die Energieerhaltung durch die dritte Randbedingung (Leckage) gewährleisten. Der Druck lässt allerdings vermuten, dass du Recht hast, denn der eskaliert recht schnell ins Enorme. Gibt es dann überhaupt eine Möglichkeit, meine Problemstellung mit definiertem Volumenstrom an inlet und outlet (unter Zuhilfenahme einer dritten Randbedingung) zu simulieren? Wenn ich den Fall als kompressibel annehme, dürfte ich ja trotzdem das gleiche Problem mit dem unendlich hohen Druck (und dann auch noch Dichte) bekommen, oder sehe ich das falsch? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Friendly Mitglied
Beiträge: 69 Registriert: 05.06.2017
|
erstellt am: 08. Dez. 2020 09:18 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Auch wenn du dein Problem kompressible annimmst, bleibt das Problem. Deine Leckage kann das Problem auch nicht auflösen. Ich weiß nicht, was genau du simulieren willst, bzw. welche Randbedingungen du in welcher Form kennst, aber selbstverständlich kannst du den Fall mit den richtigen Randbedingungen simulieren. Ich denke die totalPressure Randbedingung sollte dir helfen können. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 08. Dez. 2020 14:37 <-- editieren / zitieren --> Unities abgeben:
Ich habe inzwischen ein paar Fortschritte gemacht und konnte den Fall auch abbilden, allerdings nicht mit dem simpleFoam solver. Ich kenne als Randbedingungen die Einströmgeschwindigkeit und die Absauggeschindigkeit. Wenn ich die Bedingungen wie folgt definiere: 1. inlet: U -> fixed value (Vektorrichtung in den Raum); p -> zeroGradient 2. outlet: U -> fixed value (Vektorrichtung aus dem Raum hinaus); p -> zeroGradient 3. leckage: U -> pressureInletOutletVelocity; p -> totalPressure läuft der Fall als icoFoam und als rhoSimpleFoam (mit einigen weiteren Standard-Randbedingungen) durch. Es irritiert mich aber, dass nach wie vor beim simpleFoam-solver die Fehlermeldung
Zitat: wrong token type - expected Scalar, found on line 0 the word 'nan'
nach einer gewissen Anzahl an Iterationsschleifen kommt. Ich denke für meine Bedürfnisse komme ich auch mit icoFoam klar, da es vermutlich laminar bleibt, aber trotzdem die prinzipielle Frage: Hat jemand eine Erklärung, dass die Simulation mit den oben beschriebenen Randbedingungen im simpleFoam solver abbricht und bei rhoSimpleFoam und icoFoam durchläuft? Das würde mir vielleicht für mein Verständnis helfen. Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Friendly Mitglied
Beiträge: 69 Registriert: 05.06.2017
|
erstellt am: 08. Dez. 2020 16:10 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Konvergiert deine Lösung denn aus? Ich nutze nie die simple-solver. Ich denke was sie tun ist eine statische Lösung zu erzwingen, da sie ja keine transieten Terme besitzen. Ich habe da immer ein komisches Bauchgefühl, da ja trotzem mehrere Interationen benötigt werden, um eine statische Lösung beim simple-foam zu erhalten. Aber was diese Zwischenschritte physikalisch repräsentieren ist mir unklar. Ich schätze sie sind lediglich ein mathematisches Konstrukt. Wie sehen deine schemes aus? Hast du bei simpleFoam die bounded schemes benutzt? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 11. Dez. 2020 15:31 <-- editieren / zitieren --> Unities abgeben:
Hi Friendly, danke für deine Antwort. Wenn du die simple-solver nicht magst, welchen solver würdest du denn für einen stationären, turbulenten Fall verwenden? Den pisoFoam-solver? Zu deinen Fragen: Meine icoFoam und rhoSimpleFoam-Lösungen konvergieren, allerdings muss ich zugeben, dass ich beim rhoSimpleFoam noch recht viele Kennwerte aus Tutorials übernommen habe, da ich noch keine Zeit hatte, mich eingehend damit zu beschäftigen. Beim simpleFoam habe ich die bounded Schemes verwendet. Das hier ist meine fvSchemes-Datei: Code: ddtSchemes { default steadyState; }gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,U) bounded Gauss linearUpwind grad(U); div(phi,nuTilda) bounded Gauss linearUpwind grad(nuTilda); div((nuEff*dev2(T(grad(U))))) Gauss linear; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; }
Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Dez. 2020 09:38 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Also ich habe nicht alles gelesen aber inkompessibel und Energiegleichung kann schon mal gar nicht sein. SimpleFoam, pimpleFoam, pisoFoam, icoFoam sind alles Druck-basierte Löser ohne Energiegleichung. RhoSimpleFoam ist auch ein Druck-Basierter Löser aber eben mit Energiegleichung. Wenn Du ein stationäres Problem zu lösen hast -> SIMPLE Algorithmus, icoFoam verwendet heute kaum jemand mehr, es sei denn man kennt die Vorzüge des PIMPLE Algorithmus nicht oder wendet im Allgemeinen alle Algorithmen weitläufig falsch an. Sind zeitliche Abläufe von Interesse, dann musst du einen transienten Löser verwenden wie bpsw. icoFoam, pisoFoam, pimpleFoam. Deine snGrad und Dein Laplacian würde ich entsprechend Deiner non-orthogonalität anpassen. Ob die explizite Korrektur "corrected" ausreicht kann ich Dir nicht sagen.
Übrigens, ob U am Inlet oder Outlet fixiert wird spielt keine Rolle. Das numerische Lösungssystem sollte aber korrekt abgebildet werden. Heißt bei kleinen Mach-Zahlen wird p und U an verschiedenen Rändern fixiert, dass mit den Charakteriistiken zu tun hat. Bei Super-Sonischen Strömungen sieht das anders aus. ------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Dez. 2020 09:47 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Zitat: Original erstellt von Friendly: Ich denke was sie tun ist eine statische Lösung zu erzwingen, da sie ja keine transieten Terme besitzen. Ich habe da immer ein komisches Bauchgefühl, da ja trotzem mehrere Interationen benötigt werden, um eine statische Lösung beim simple-foam zu erhalten.
Das ist so nicht richtig. Die Fachtermina sind hier auch komplett unpassend von Dir. Das was ein stationärer Algorithmus nicht hat ist die Zeitableitung, die nichts anderes als ein Limiter darstellt, der angibt wie weit sich die Lösung pro Zeitschritt ändern darf. Stationäre Algorithmen haben das nicht, daher ist die Limitierung hier durch Relaxation zwingend erforderlich. Man kann mit einem transienten Löser noch mehr Dummheiten machen, vor allem dann, wenn die expliziten Terme in dem Gleichungssystem nicht konvergiert werden. Die Leute wundern sich dann immer das überall andere Ergebnisse rauskommen, und das obwohl keine Grundverständnisse der Algorithmen, der numerischen Diskretisierungsschemen etc. vorhanden sind. Wenn ich bpsw. sehe, dass die Leute sich über den Laplace und snGrad keine Gedanken machen, aber beim Divergenzterm alles mögliche rumstellen, dann zeugt das einfach von Unwissenheit: Ganz nach dem Motto: Probier mer mal dann seh mer schon. Das "bounded" in den Div-Termen ist übrigens nicht zwingend notwendig. Es führt lediglich ein zusätzlichen Term ein, der im stationären Fall gleich Null ist.
Es heißt übrigens, stationär und nicht statische Lösung
------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Dez. 2020 09:52 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
|
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 17. Dez. 2020 10:17 <-- editieren / zitieren --> Unities abgeben:
Hi Tobi, danke für deine Antwort. Ich werde wohl nicht drumherum kommen, mich tiefer in die Materie einzuarbeiten, wenn ich belastbare Modelle erstellen will. Wer hätte das gedacht... Vielleicht habe ich über die Lockdown-Tage Zeit, mich mit dem Thema besser zu beschäftigen und dann Fragen zu stellen, die von weniger Unwissenheit zeugen Grüße Moritz Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Dez. 2020 10:47 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
|
MoritzB Mitglied
Beiträge: 9 Registriert: 21.04.2020
|
erstellt am: 17. Dez. 2020 11:03 <-- editieren / zitieren --> Unities abgeben:
ja, auf dein Buch bin ich auch schon gestoßen und habe es gespeichert! Es ist wirklich toll, dass du so engagiert bist und dein Wissen öffentlich zugänglich machst! Jetzt in der Vorweihnachtszeit bin ich allerdings noch sehr viel mit anderem beschäftigt, aber danach werde ich mich hoffentlich damit beschäftigen können und wie du schon sagst in einer Mischung aus try and error und Literatur-Know-How versuchen, OpenFoam weiter auf den Grund zu gehen. Danke und Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Dez. 2020 12:01 <-- editieren / zitieren --> Unities abgeben: Nur für MoritzB
Die Numerik hinter der CFD zu verstehen ist aus meiner Sicht essentiell. Hinzukommt, dass man die Mathematik und die Terme versteht. Damit kann man dann richtig arbeiten. Leider bin ich nicht so smart genug, dass ich mir das mit Lesen aneignen konnte, sondern musste alles selber Herleiten. Dadurch ist dann auch das Buch entstanden. Erst nachdem ich das alles gemacht hab, ist mir vieles klarer geworden. Auch Turbulenzmodellierung, etc. ------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|