| | | Xometry ermöglicht JTW Astronomy die Herstellung hochwertiger Trident Teleskophalterungen, ein Anwenderbericht
|
Autor
|
Thema: unglaublich große Courant-Zahl (6783 mal gelesen)
|
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 11:44 <-- editieren / zitieren --> Unities abgeben:
Hallo an alle! Ich habe folgendes Problem: Ich möchte mit OpenFoam die Strömung durch ein Kolbenventil simulieren und habe mit ANSA ein Volumennetz generiert. checkMesh sagt mir, dass das Netz okay ist und da ich erst vor einer Woche mit OF angefangen habe, wollte ich zunächst eine laminare Rechnung mit icoFoam durchführen, um dann später, wenn das funktioniert hat, immer etwas genauer zu werden. Dafür habe ich die fvSchemes, fvSolution und transportProperties vom "icoFoam->cavity-Tutorial" genommen. Leider bricht meine Rechnung aber mit dem icoFoam solver nach ca. 10 Schritten ab, da die Courant-Zahl auf einen Wert über 1e+100 angestiegen ist... Ich habe gelesen, dass sie unter 1 bleiben sollte für stabile Rechnungen und das ist ja leider nicht der Fall. Also habe ich zunächst die Schrittweite auf 3.5e-6 gesenkt, doch die Co-Zahl stieg weiter bis zum Abbruch! Danach habe writeControl auf "adjustableRunTime" geändert und die Co-Zahl mit "maxCo 1" eingeschränkt, damit die Schrittweite selbst angepasst wird, aber in der runlog sah ich, dass delta t weiterhin konstant blieb. Funktioniert adjustableRunTime also nicht für icoFoam, sondern nur für komplexere solver? Jedenfalls weiß ich nicht so recht weiter, was ich machen kann, damit meine Rechnung zumindestens für den laminaren Fall durchläuft... Habt ihr eine Idee? Viele Grüße! PS: meine Startwerte für U und p
Code:
dimensions [0 1 -1 0 0 0 0]; internalField uniform ( 0.000000 0.000000 -1.000000 ); boundaryField { symmetry { type symmetryPlane; } inlet { type fixedValue; value uniform ( 0.000000 0.000000 -1.000000 ); } outlet { type zeroGradient; }} dimensions [0 2 -2 0 0 0 0]; internalField uniform 0.000000; boundaryField { symmetry { type symmetryPlane; } inlet { type fixedValue; value uniform 452.38; } outlet { type fixedValue; value uniform 0.000000; }
controlDict
Code:
application icoFoam; startFrom startTime; startTime 0; stopAt endTime; endTime 1e-3; deltaT 3.5e-6; writeControl adjustableRunTime; writeInterval 10; purgeWrite 0; writeFormat ascii; writePrecision 6; writeCompression uncompressed; timeFormat general; timePrecision 6; runTimeModifiable yes; adjustTimeStep yes; maxCo 1.0;
fvSchemes
Code:
ddtSchemes { default Euler; } gradSchemes { default Gauss linear; grad(p) Gauss linear; } divSchemes { default none; div(phi,U) Gauss linear; } laplacianSchemes { default none; laplacian(nu,U) Gauss linear corrected; laplacian((1|A(U)),p) Gauss linear corrected; } interpolationSchemes { default linear; interpolate(HbyA) linear; } snGradSchemes { default corrected; } fluxRequired { default no; p; }
fvSolution
Code:
olvers { p PCG { preconditioner DIC; tolerance 1e-06; relTol 0; }; U PBiCG { preconditioner DILU; tolerance 1e-05; relTol 0; }; } PISO { nCorrectors 2; nNonOrthogonalCorrectors 0; pRefCell 0; pRefValue 0; }
EDIT: okay ich hab bei divSchemes Gausslinear auf GaussUpwind gesetzt und jetzt steigt die maximal Co-Nr bis zum 20. Zeitschritt nicht über 7! Aber danach gehts wieder hoch und bricht dann irgendwann ab, wenn die Zahl zu groß wird...
Reicht es denn, wenn die gemittelte Co-Nr <1 ist oder sollte auch die maximale unter 1 sein? ------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik" [Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] [Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StudentMax Mitglied Student Maschinenbau
Beiträge: 73 Registriert: 03.12.2009 SuseLinux 11.2 OpenFoam 1.6 Salome 5.1.3
|
erstellt am: 21. Apr. 2010 13:30 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hi bephi, ich bin mir nicht hundertprozentig sicher, da ich selbst noch Anfänger bin, aber ich glaube dein Problem liegt bei den Randbedingungen für p: Versuche mal den outlet auf "type zeroGradient;" anstatt auf "fixedValue" zu setzen. Ich denke icoFoam hat ein Problem, weil du zweimal fixedValue verwendet hast. Achtung: der Druck wird bei inkompressiblen Solvern wie icoFoam als sog. "density normalized pressure" angegeben, also Druck/Dichte. Der Druck ist damit relativ. Es werden keine Absolutwerte in Pascal angegeben (siehe die Einheiten bei "Dimensions": m^2/s^2). Schaue dir mal die p-Datei in verschiedenen inkompressiblen tutorials an. Es wird eigentlich immer nur eine Randbedingung für den Druck auf "fixedValue" gesetzt, der Rest ist "zeroGradient". Die festen Werte sind eigentlich immer mit Null angegeben, weil sie eben relativ sind. Also denke ich der Wert von 452 beim Inlet sollte auf 0 gesetzt werden. Ich hoffe dass das jetzt richtig war und ich dir keinen Schmarrn erzählt habe, evtl kann ein Profi wie Thomas oder Ulrich mehr dazu sagen, Grüße Max [Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 13:41 <-- editieren / zitieren --> Unities abgeben:
Hallo Max, hab vielen Dank für deine nette Antwort! Also ich werd es gleich mal mit zeroGradient am outlet versuchen... Danke auch für den Tipp mit dem spezifischen Druck! Das ist allerdings schon berücksichtigt. Ich habe am Einlass 3,8 bar also ca. 380000 Pa und bezogen auf eine Dichte von 840 kg/m³ ergeben sich dann 452,4 m²/s². Viele Grüße! Phil EDIT: Ich hab jetzt den type fixvalue gegen zeroGradient am outlet getauscht und leider ist das Resultat, dass die Co-Zahl wieder etwas schneller anwächst als vorher, bis die Rechnung dann abbricht. ------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"
[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] [Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StudentMax Mitglied Student Maschinenbau
Beiträge: 73 Registriert: 03.12.2009 SuseLinux 11.2 OpenFoam 1.6 Salome 5.1.3
|
erstellt am: 21. Apr. 2010 13:58 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hi bephi, ich habe was übersehen: du hast am inlet sowohl die geschwindigkeit als auch den druck auf fixedValue gesetzt. Probier mal, den Druck am outlet auf fixedValue und am inlet auf zeroGradient. Wenn an einer Fläche Druck und Geschwindigkeit auf fixedValue stehen, mag das der Solver auch nicht. Also inlet-->U=fixedValue und p=zeroGradient outlet -->U=zeroGradient und p=fixedValue Könnte auch was bringen, einfach mal probieren, Grüße Max Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 14:08 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von StudentMax: Hi bephi, ich habe was übersehen: du hast am inlet sowohl die geschwindigkeit als auch den druck auf fixedValue gesetzt. Probier mal, den Druck am outlet auf fixedValue und am inlet auf zeroGradient. Wenn an einer Fläche Druck und Geschwindigkeit auf fixedValue stehen, mag das der Solver auch nicht. Also inlet-->U=fixedValue und p=zeroGradient outlet -->U=zeroGradient und p=fixedValue Könnte auch was bringen, einfach mal probieren, Grüße Max
Hey, aber ich möchte doch die Anfangsbedingung geben, dass der Druck am inlet einen bestimmten Wert besitzt. Warum sollte ich ihn dann auf zeroGradient stellen? Dann würde er ja mit falschen Eingangswerten rechnen?! Gruß! ------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik" [Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StudentMax Mitglied Student Maschinenbau
Beiträge: 73 Registriert: 03.12.2009 SuseLinux 11.2 OpenFoam 1.6 Salome 5.1.3
|
erstellt am: 21. Apr. 2010 14:20 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hi phil, das gleiche Problem habe ich auch gerade. Der Solver verträgt es nicht, wenn Druck und Geschw. an der gleichen Fläche fixed sind. Jedoch habe ich bei mir beide Werte für den Outlet gegeben, ich müsste also am outlet u und p auf fixed setzen. Das führt jedoch immer zu einem Solverabsturz. Ich habe von Thomas Hilfe bekommen, und nun habe ich am Inlet einen Volumenstrom angegeben, den ich mir aus der Outlet-Geschwindigkeit und der outlet-Fläche berechnet habe. Evtl. kannst du in ähnlicher Weise die Randbedingungen auf Inlet und outlet aufteilen. (Evtl. am outlet die Geschwindigkeit definieren?) Ansonsten würde ich dir empfehlen, auch wenns erstmal falsch ist, die Bedingungen zu verändern, damit der Solver erstmal läuft--> Einschränken des Problems. So habe ich bei mir manchmal die Solver-Absturz Probleme eingrenzen können. Hoffe geholfen zu haben, Grüße, Max [Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 14:48 <-- editieren / zitieren --> Unities abgeben:
hey max, also die idee ist auf jeden fall nicht verkehrt, dass man immer ein paar vereinfachungen macht und es zum laufen kriegt und dann stück für stück korrekter wird. leider ist auch bei der maßnahme der anstieg der Co-Zahl nicht verhindert und sie steigt relativ schnell, sodass die rechnung nach ein paar minuten abbricht... ------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik" Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StudentMax Mitglied Student Maschinenbau
Beiträge: 73 Registriert: 03.12.2009 SuseLinux 11.2 OpenFoam 1.6 Salome 5.1.3
|
erstellt am: 21. Apr. 2010 15:02 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hi Phil, was gibt denn checkMesh aus wie viele nicht-orthogonale Zellen du im Netz hast? Weil du in deiner fvSolution keine nNonOrthogonalCorrectors hast. Keine Ahnung, ob dein Fehler daran liegen kann, aber prinzipiell gilt je mehr nicht-orthogonale Zellen im Netz, desto mehr nNonOrthogonalCorrectors sind nötig. Kannst ja mal probieren diese auf 2 oder 5 oder so zu setzen, evtl hilfts was. Ich habe z.B. laut checkMesh 13 von ca. 250.000 Zellen, die nicht-orthogonal sind und habe 2 nNonOrthogonalCorrectors. Im cavity tutorial sind keine nNonOrthogonalCorrectors nötig, da dort ja ein simples 2D-Hexa Mesh verwendet wird. Grüße, Max Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ulrich Heck Mitglied OpenFOAM Tool Entwicklung
Beiträge: 291 Registriert: 08.09.2003 CastNet (DHCAE Tools) OpenFOAM CalculiX
|
erstellt am: 21. Apr. 2010 15:11 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hallo Bephi, Druckwert am Ein- und Austritt und Geschwindigkeit macht definitiv keinen Sinn, da dann der Strömung die Lösung bereits aufgezwungen wird. Das kann nicht funktionieren. Das Druck- bzw. Geschwindigsfeld ergeben sich gegenseitig aus den Randbedingungen, d.h. man darf nur eins von vorschreiben, entweder ein treibendes Druckgefälle oder einen Fluss, der ein Druckgefälle (Druckverlust) verursacht. Weiterhin ist folgendes zu beachten: Bei Problemen sollte man am besten die stabilsten Schemes verwenden, d.h. div(phi,U) Gauss upwind. Bei Piso sollte der nonorthogonal Corrector größer als "0" sein (z.B. 2), wenn das Gitter nicht wirklich orthogonal ist (also z.B. tet-Gitter). Dann ist es am besten auch den Zeitschritt entsprechend des Tutorials "icoFOAM" im OF user guide abzuschätzen. Kleinere Zeitschritte bringen mehr Stabilität (Piso). Viele Grüße Ulli
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 15:25 <-- editieren / zitieren --> Unities abgeben:
Also Ulli und Max, habt auf jeden Fall vielen Dank, dass ihr mir helft! Ohne euch wüsst ich nicht wo vorn und hinten ist Also das mit den nonorthogonal Correctors klingt gut und werd ich gleich mal ausprobieren. Ich weiß, dass mein Netz noch nicht so gut ist, aber ich dachte mir, weil checkMesh das OK gegeben hat, setz ich wenigstens mal meine erste Rechnung auf, um zu schauen, wie so ein ganzer Prozess abläuft. Die Schrittweite habe ich bereits mit Co=1 und delta x abgeschätzt. Anbei das Ergebnis von checkMesh. Habe ich 67.4637 nichtorthogonale Elemente und Max nur 13? Oder welcher Wert ist das? Zu den Randbedingungen: Reicht es denn, wenn ich den Druck am Ausgang nur auf zeroGradient stelle? Oder muss der Druck am Inlet wirklich weg? Code:
Mesh stats points: 224517 faces: 1780738 internal faces: 1704400 cells: 821567 boundary patches: 12 point zones: 0 face zones: 0 cell zones: 2Number of cells of each type: hexahedra: 0 prisms: 198870 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 622697 polyhedra: 0 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 symmetry 13976 8782 ok (non-closed singly connected) inlet 36 28 ok (non-closed singly connected) outlet 39 30 ok (non-closed singly connected) drosselbohrungen 11632 5973 ok (non-closed singly connected) steuerkanten_unten 15622 7988 ok (non-closed singly connected) kolbenstange 9945 5563 ok (non-closed singly connected) schliessscheibe 11254 6000 ok (non-closed singly connected) steuerkanten_oben 8919 4617 ok (non-closed singly connected) zylinderrohr 741 439 ok (non-closed singly connected) fenster 3373 1766 ok (non-closed singly connected) auslauf_oben 228 137 ok (non-closed singly connected) auslauf_unten 573 366 ok (non-closed singly connected) Checking geometry... Overall domain bounding box (-0.0275 -0.0238157 -0.2) (-7.62939e-10 6.62893e-10 0.175) Mesh (non-empty) directions (1 1 1) Mesh (non-empty, non-wedge) dimensions 3 Boundary openness (-9.11091e-17 1.52805e-15 -1.40072e-16) OK. Max cell openness = 6.37195e-16 OK. Max aspect ratio = 40.8671 OK. Minumum face area = 9.05593e-11. Maximum face area = 2.08965e-05. Face area magnitudes OK. Min volume = 3.33263e-16. Max volume = 2.92178e-08. Total volume = 9.0315e-05. Cell volumes OK. Mesh non-orthogonality Max: 67.4637 average: 16.3796 Non-orthogonality check OK. Face pyramids OK. Max skewness = 2.45156 OK. Mesh OK.
------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik" [Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StudentMax Mitglied Student Maschinenbau
Beiträge: 73 Registriert: 03.12.2009 SuseLinux 11.2 OpenFoam 1.6 Salome 5.1.3
|
erstellt am: 21. Apr. 2010 15:44 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hi Phil, hmm das sieht eigentlich gut aus. Wenn schlechte Zellen drinn sind, ist nach Mesh non-orthogonality Max:......... eine weitere Zeile mit z.B.: *Number of severly non-orthogonal faces: 13 Also denke ich dass dein Netz gut ist. Evtl. kannst du ja mal in paraView die Netzqualität (paraFoam -->Filter:MeshQuality) anschauen, aber ich glaube nicht dass bei dir das Netz das Problem ist. Wenn du am Inlet die Geschw. auf fixedValue hast, muss der Druck am Inlet weg, soweit ich weiss, sonst crasht der Solver. Dann muss am Inlet der Druck auf zeroGradient sein. Dafür kannst du am outlet den Druck auf fixedValue setzen. Grüße, Max [Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ulrich Heck Mitglied OpenFOAM Tool Entwicklung
Beiträge: 291 Registriert: 08.09.2003 CastNet (DHCAE Tools) OpenFOAM CalculiX
|
erstellt am: 21. Apr. 2010 15:51 <-- editieren / zitieren --> Unities abgeben: Nur für bephi
Hallo Phil, Schließe mich Max an, der ist irgendwie schneller: Dein Gitter ist absolut okay. Der maximale Winkel ist 67.4 Grad. Da sollte es keine Probleme geben. Meines Wissens passt icoFOAM aber nicht den Zeitschritt an die CFL-Zahl an, es sei denn, dies wurde in einer der letzten Versionen geändert. D.h. maxCo wird dort nicht benutzt. Würde ich mal kontrollieren. Meines Wissens muss man vür IcoFoam den Zeitschritt von Hand ausrechnen. Gruß Ulli Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bephi Mitglied Student
Beiträge: 56 Registriert: 21.04.2010 OpenFoam 1.70
|
erstellt am: 21. Apr. 2010 15:51 <-- editieren / zitieren --> Unities abgeben:
ah alles klar! ich hab nämlich garnicht gefunden, wo die anzahl der nicht-orthogonalen elemente angegeben wird. also ich hab den faktor aber trotzdem mal auf 2 gesetzt und bisher läuft die rechnung ganz gut durch und die Co-zahl bleibt weit unter 1! mal sehen, obs durchgehalten wird... ich werd die rechnung laufen lassen, muss mich jetzt aber auf den weg machen und schau dann morgen früh, was drauß geworden ist ich wünsche euch noch einen schönen feierabend und habt nochmal vielen herzlichen dank!!! ------------------ Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik" Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|