Autor
|
Thema: Geschwindigkeitsproblem nahe Outlet BC (1426 mal gelesen)
|
ch.lucas Mitglied
Beiträge: 13 Registriert: 17.02.2010
|
erstellt am: 15. Mrz. 2010 15:49 <-- editieren / zitieren --> Unities abgeben:
Hallo alle zusammen, ich habe immer mal wieder folgendes Problem gehabe und bin mir leider nicht sicher, wie man dieses am effektivsten beseitigen kann. Das Problem ist, dass sich die Geschwindigkeit nahe dem Austritt sehr unphysikalisch verhält. Ich habe dort hohe Geschwindigkeiten in Richtung des Austritts und direkt daneben hohe negative Geschwindigkeiten. Die Konvergenz des Bauteils ist nicht wirklich schlecht (Residuen ungefähr bei 1e-5) und der Rest der Strömung entspricht auch dem, was ich erwartet habe. Diese Störungen nehmen mit der Zeit ab und werden wahrscheinlich gegen Ende ganz verschwunden sein. Allerdings dauert dies sehr lange. Simulation: Gitter: strukturiertes 2d Gitter, recht fein, keine Probleme bei checkMesh. Auch die Überprüfung beim Gittergenerator ergab keine Probleme. Das Gitter sollte also eigentlich nicht das Problem sein. Solver: SimpleFoam BC: Inlet: U -> FixedValue; p -> zeroGradient Outlet: U -> Zero Gradient p -> Fixed Value Ich habe bereits versucht, den Fehler durch verändern der Relaxationsfaktoren den Fehler zu beheben. Auch das Verwenden anderer linearer Solver hat nicht geholfen. Meine nächste Idee wäre eine Überprüfung der Grad-, Laplace- und divSchemes. Hat jemand eine Idee, was ich am besten machen könnte, um dieses Problem zu beseitigen. Gruß Christian
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ocelot Mitglied Dipl-Ing. (BA) Maschinenbau
Beiträge: 171 Registriert: 29.04.2006 OpenSUSE Leap 42.2 x64 OpenFOAM-plus OpenFOAM-4.x
|
erstellt am: 15. Mrz. 2010 19:23 <-- editieren / zitieren --> Unities abgeben: Nur für ch.lucas
Hallo Christian, mir fallen spontan zwei Dinge ein: 1.) Auch wenn ich sehr stark davon ausgehe, trotzdem die Rückfrage: Verwendest du die korrekte Randbedingung ("empty") für die 2D-Schnittflächen? 2.) Verwendest du eine Initialisierung? Wenn ja, ist diese korrekt? Falls einheitliche Start-Felder nicht sinnvoll sind, einfach den Potentialfluss-Solver potentialFoam verwenden. Noch etwas: Welchen OpenFOAM-Solver nutzt du für deine Rechnung? Viele Grüße Johannes Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
ch.lucas Mitglied
Beiträge: 13 Registriert: 17.02.2010
|
erstellt am: 18. Mrz. 2010 11:02 <-- editieren / zitieren --> Unities abgeben:
Hallo Johannes, danke für die Antwort. Die Simulation sollte keine Problem bezüglich der "Empty" Randbedingung haben. Leider kann ich die Rechnung nicht mit PotentialFoam initialisieren, da ich bei PotentialFoam eine unbrauchbare Lösung erhalte. Aus diesem Grund habe ich mit einem gleichmäßigen Geschwindigkeitsfeld angefangen. Das dies zu Probleme führen kann ist mir bewusst. Die Lösung sollte dennoch konvergieren (was sie ja auch tut, halt nur extrem langsam), auch wenn dies etwas langer dauert. Bei anderen Rechnungen mit derselben Geometrie (Gitter) ist dieses Problem zwar auch aufgetreten, war allerdings nach einigen Iterationen wieder weg. Der einzige Unterschied zwischen den Rechnungen die liefen zu der, bei der der oben beschriebene Fehler auftritt, ist die Eintrittsgeschwindigkeit, die bei den gut funktionierenden Rechnungen 20mal höher war. Ich habe auch schon probiert, das Geschwindigkeitsfeld einer meiner Rechnungen, die gut konvergiert ist zu verwenden. Leider treten aufgrund der höheren Geschwindigkeiten noch mehr Fehler auf als bei einer gleichmäßigen Initialisierung des Geschwindigkeitsfeldes. Ich vermute mittlerweile, dass die Lösung des Problems in den Interpolationsmethoden liegt. Ich habe es gerade mal für die Divergenz auf ein Schema höherer Ordnung (QUICK) umgestellt und der Fehler ist relative stark zurückgegangen. Mal sehen ob dies an der Umstellung oder der neuen Interpolationsmehtode liegt. Falls dennoch jemand einige Anregungen hat, wären diese sehr willkommen. Gruß Christian Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ocelot Mitglied Dipl-Ing. (BA) Maschinenbau
Beiträge: 171 Registriert: 29.04.2006 OpenSUSE Leap 42.2 x64 OpenFOAM-plus OpenFOAM-4.x
|
erstellt am: 22. Mrz. 2010 21:16 <-- editieren / zitieren --> Unities abgeben: Nur für ch.lucas
Hallo Christian, sorry für meine späte Antwort, habe den Thread etwas aus den Augen verloren... Ich hätte noch einmal drei Vorschläge: - Zur potentialFoam-Initialisierung: Ich hatte ebenfalls schon ähnliche Probleme (stark überhöhte Geschwindigkeitsfelder) mit potentialFoam. Was bei mir geholfen hat, war einerseits die deutliche Erhöhung der Iterationen und/oder die Initialisierung mit einem Bruchteil der geplanten Eingangswerte. - Wenn es mit potentialFoam immer noch nicht klappt: Hast du schon probiert, den Solverlauf ohne Initialisierung mit sehr geringen Werten für U zu starten? Sobald sich ein (annährend) stationärer Zustand gebildet hat, könntest du diese Lösung als Startlösung verwenden. - Ich hatte übersehen, dass du simpleFoam bentutzt. In meinen eigenen Rechnungen mit diesem Solver hatte ich bisher keine derartigen Probleme. Oft habe ich sogar ohne Initialisierung gearbeitet. Was du noch testen könntest, wäre die Reduzierung oder sogar Deaktivierung (= 0) der relativen Solvertoleranzen (relTol) insbesondere bei p und U. Viel Erfolg! Grüße Johannes Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
ch.lucas Mitglied
Beiträge: 13 Registriert: 17.02.2010
|
erstellt am: 23. Mrz. 2010 16:35 <-- editieren / zitieren --> Unities abgeben:
Hallo Johannes, vielen Dank für deine Antwort. Wie ich bereits vermutet habe, ist der Fehler in meiner Rechnung mit der Zeit verschwunden. Hat aber dennoch recht lange gebraucht. Bezüglich PotentialFoam hast du mir einen sehr guten Tipp gegeben. Wenn ich den nNonOrthogonalCorrectors Faktor auf 30 oder höher setzte, worauf ich nie gekommen wäre, bekomme ich ein akzeptables Geschwindigkeitsfeld. Gruß Christian Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|