| | | Leitfaden für die Materialauswahl im Spritzguss, ein Fachartikel
|
Autor
|
Thema: simpleFoam crasht (1220 / mal gelesen)
|
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 03. Feb. 2021 10:57 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, ich bin relativ neu bei OpenFOAM und versuche mich derzeit an folgender Simulation mit dem Solver simpleFoam: ich habe ein koaxiales System bestehend aus einem Innenzylinder (R_i = 12,778 mm) und einem Außenzylinder (R_a = ca. 13,943 mm). Der Innenzylinder ist glatt, der Außenzylinder besitzt axiale Nuten. In dem Spalt zwischen den beiden Zylindern befindet sich ein newtonsches Fluid mit einer Viskosität von ca. 5 Pa*s. Ziel der Simulation ist es, das Moment am Innenzylinder (z-Achse) und das Geschwindigkeitsfeld in radialer Richtung zu erhalten. Nun zum Problem: ich habe verschiedene Geometrien, die ich simulieren möchte (neun Stück). Bei den ersten drei Simulationen hat alles ohne Probleme geklappt, kein Abstürzen oder sonst etwas. Dann ist bei der 4. Geometrie auf einmal das Problem aufgetaucht, dass es nach einigen (im Bereich von 5000-15000) Zeit- bzw. Iterationsschritten (meist ist ein stationärer Zustand bei ca. t = 35 000 erreicht) auf einmal einen richtigen Sprung im Moment um die y-Achse gegeben hat, was vermutlich darauf zurückzuführen ist, dass das Geschwindigkeitsfeld lokal komplett durchgedreht ist (s. Bilder, einmal vorher, einmal nachher). Die Folge war, dass die Simulation dann irgendwann abgestürzt ist und sich der PC neugestartet hat (vermute ich jedenfalls, denn morgens war der PC dann einfach an, ohne dass irgendwelche Ordner offen gewesen sind). Ich dachte zuerst, dass es am Mesh lag, aber das Mesh war eigentlich komplett in Ordnung (zumindest der Funktion checkMesh nach zu urteilen). Trotzdem habe ich verschiedene Zellgrößen ausprobiert und und und, aber nichts hat geklappt, das Problem besteht immer noch. Verschiedene Foren habe ich natürlich auch schon durchstöbert, aber nicht Passendes gefunden. Daher hoffe ich sehr, dass mir jemand von euch helfen kann! Kurz zum Vorgehen bei der Simulation (vllt liegt es ja auch in irgendeiner Weise an meinen Befehlen): - setFields - decomposePar - mpirun -np 12 simpleFoam -parallel - reconstructPar Da ich wirklich nicht weiß, wo der Fehler liegt, habe ich euch mal den ganzen case angehängt. Das ist denke ich einfacher, als wenn ich die einzelnen Codes hier poste. Falls es speziell zu bestimmten files Fragen gibt und ihr nicht den ganzen Anhang runterladen wollt, kann ich den entsprechenden Code aber gerne auch noch posten! Viele Grüße Basti Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hulli1 Mitglied
Beiträge: 61 Registriert: 23.01.2020 --
|
erstellt am: 03. Feb. 2021 11:45 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Hi, ich hoffe, Du konntest Dein Problem lösen... Ich habe mir gerade mal Deine Bilder angesehen und wie Du siehst, geht es voll in die Luft... aber Du meinst, dass an Deinem Mesh alles ok ... außer einem Mesh Problem erinnern mich diese Bilder an Probleme mit den Randbedingungen ... z.B. ich habe viel channel flow cases bearbeitet ... und am Anfang hatte ich solche extremen Sprünge wenn die p/u Randbedingung nicht gepasst haben... zum Beispiel, wenn das Fluid "verdrängt" wurde und eine inlet/outlet Randbedingung gefehlt hat ... daher habe ich mir gerade mal Deine p Randbedingung angesehen... Hier hast Du alles auf zeroGradient gesetzt ... Check mal, ob es etwas bringt, wenn Du die beiden Wände (oben und unten am Kanal) zu inlet/Outlet Randbedingungen machst damit sich im System kein zu hoher Druck aufbauen kann ... GGf hilft es menn Du Dir mal den TJunktion case in den Tutorials ansiehst ... LG H Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 03. Feb. 2021 15:18 <-- editieren / zitieren --> Unities abgeben:
Hallo Hulli, das werde ich gleich mal probieren, berichte euch dann. Nur, damit ich das richtig verstanden habe - ich habe jetzt sideX und sideY auf: type fixedValue; value uniform 100000; gesetzt. Das meintest du, oder? Viele Grüße Basti
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hulli1 Mitglied
Beiträge: 61 Registriert: 23.01.2020 --
|
erstellt am: 04. Feb. 2021 11:26 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 04. Feb. 2021 13:06 <-- editieren / zitieren --> Unities abgeben:
Leider hat das nichts gebracht Bei der Simulation gab es die gleichen Probleme. Habe dann versucht, die Seiten top und bottom statt auf noSlip auf zeroGradient zu setzen, aber das hat auch nichts gebracht. Und wenn ich top und bottom auf empty setze, hört simpleFoam nach 1 Iteration auf, weil Konvergenz erreicht wurde top und bottom sind übrigens auch nur "virtuelle" Wände, weil das Koaxialsystem in der Theorie eigentlich unendlich weit ausgedehnt wäre. Habe die daher erst mit "wall" typisiert und dann auf "slip" gesetzt, was ja eigentlich die ganze Zeit super funktioniert hat! Habt ihr vielleicht sonst noch welche Tipps? Hier einmal vielleicht die wichtigsten Codes: p
Code: dimensions [0 2 -2 0 0 0 0]; internalField uniform 0;
boundaryField { top { type zeroGradient; } bottom { type zeroGradient; } innerWall { type zeroGradient; } outerWall { type zeroGradient; } sideX { type fixedValue; value uniform 0; } sideY { type fixedValue; value uniform 0; } }
U
Code: dimensions [0 1 -1 0 0 0 0];internalField uniform (0 0 0); boundaryField { bottom { type zeroGradient; } top { type zeroGradient; } sideX { type zeroGradient; } sideY { type zeroGradient; } innerWall { type rotatingWallVelocity; origin (0 0 0); axis (0 0 1); omega constant 0.213926751; } outerWall { type noSlip; } }
fvSolution
Code: solvers { p { solver GAMG; tolerance 1e68; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration true; nCellsInCoarsestLevel 10; agglomerator faceAreaPair; mergeLevels 1; } U { solver smoothSolver; smoother GaussSeidel; nSweeps 2; tolerance 1e-20; relTol 0.1; } } SIMPLE { nNonOrthogonalCorrectors 0; pRefCell 0; pRefValue 0; residualControl { p 1e-2; U 1e-3; } } relaxationFactors { fields { p 0.2; } equations { U 0.4; } }
fvSchemes
Code: ddtSchemes { default steadyState; }gradSchemes { default Gauss linear; } divSchemes { default Gauss linear; div(phi,U) Gauss limitedLinearV 1; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; p ; }
boundary File aus dem polyMesh
Code: 6 ( top { type patch; inGroups 1(patch); nFaces 51240; startFace 6313646; } bottom { type patch; inGroups 1(patch); nFaces 50956; startFace 6364886; } innerWall { type rotatingWallVelocity; inGroups 1(wall); nFaces 42000; startFace 6415842; } outerWall { type wall; inGroups 1(wall); nFaces 62872; startFace 6457842; } sideX { type patch; inGroups 1(patch); nFaces 2520; startFace 6520714; } sideY { type patch; inGroups 1(patch); nFaces 2520; startFace 6523234; } )
Würde mich echt freuen, wenn euch irgendetwas auffällt oder ihr Tipps habt. Sitze da schon seit gut 2 Wochen dran und versuche alles mögliche, aber irgendwie... Weiß nur nicht, ob es nicht vielleicht doch am Mesh liegt, weil die Simulationen davor ja alle geklappt haben, nur eben nicht, als ich eine andere Geometrie implementiert habe. Aber checkMesh ergibt, dass das Mesh OK ist, ohne einen einzigen Error. [Diese Nachricht wurde von bastipa93 am 04. Feb. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hulli1 Mitglied
Beiträge: 61 Registriert: 23.01.2020 --
|
erstellt am: 04. Feb. 2021 14:46 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
... was mir auf die schnelle einfällt wäre ein vereinfachen case zu bauen ... sprich ähnlich dem cavity case ... und dann Deine Settings testen ... dann könntest Du herausfinden ob die BC passen oder ob doch das Mesh schuld ist ... was hast Du denn zu den funktionierende cases verändert ??? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 04. Feb. 2021 14:56 <-- editieren / zitieren --> Unities abgeben:
Ja, ich habe auch bemerkt, dass ich mein mesh gar nicht so "hoch" bauen muss, weil mich die Geschwindigkeit sowieso nur in x-y-Richtung interessiert. Daher werde ich das schonmal vereinfachen. Den cavity case schaue ich mir auch mal an, den kenne ich noch nicht. Das EINZIGE was ich wirklich verändert habe, war das mesh. Habe einfach über SHM ein neues Mesh generiert und entsprechend im polyMesh-Ordner bei constant eingefügt. Den Rest habe ich so gelassen, wie vorher. Ich gehe mal davon aus, dass die Simulation vorher auch nicht bei noch höheren Laufzeiten abgestürzt wäre, denn die Iteration lief bis >60.000 Schritte und ich hatte schon ein konstantes Drehmoment bei ca. 35.000 Schritten. Habe die Simulationen dann immer nur bis 40.000 laufen lassen und alles war gut, die simulierten Drehmomente haben auch gut mit den praktischen Ergebnissen übereingestimmt. Und dann kamen die anderen Meshs (die haben ein anderes Nut/Steg-Verhältnis, doppelt so groß wie vorher) und dann hat nichts mehr geklappt... Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 04. Feb. 2021 17:25 <-- editieren / zitieren --> Unities abgeben:
Ich habe jetzt mal analog zum cavity Fall die Seite sideX und sideY (also die, die du richtig in deinem Gemälde markiert hast ) auf empty gesetzt und den Rest entsprechend auch angepasst. Die Codes sehen so aus: Druck p
Code: dimensions [0 2 -2 0 0 0 0]; internalField uniform 0;
boundaryField { top { type zeroGradient; } bottom { type zeroGradient; } innerWall { type zeroGradient; } outerWall { type zeroGradient; } sideX { type empty; } sideY { type empty; } }
Geschwindigkeit U
Code: dimensions [0 1 -1 0 0 0 0];internalField uniform (0 0 0); boundaryField { bottom { type slip; } top { type slip; } sideX { type empty; } sideY { type empty; } innerWall { type rotatingWallVelocity; origin (0 0 0); axis (0 0 1); omega constant 0.213926751; //halbe Winkelgeschwindigkeit bei gamma = 5,17 1/s } outerWall { type noSlip; } }
Allerdings spuckt der mir jetzt einen anderen Fehler aus, mit dem ich nichts wirklich anfangen kann. Du/ihr vielleicht? Code: [1] [1] [1] --> FOAM FATAL ERROR: [1] Continuity error cannot be removed by adjusting the outflow. Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow. Total flux : 1e-300 Specified mass inflow : 4.22235e-25 Specified mass outflow : 4.28928e-25 Adjustable mass outflow : 0 [1] [1] [1] From function bool Foam::adjustPhi(Foam::surfaceScalarField&, const volVectorField&, Foam::volScalarField&) [1] in file cfdTools/general/adjustPhi/adjustPhi.C at line 110. [1] FOAM parallel run exiting [1]
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Friendly Mitglied
Beiträge: 69 Registriert: 05.06.2017
|
erstellt am: 05. Feb. 2021 15:20 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Interessant, den Fehler hatte ich bislang noch nicht. Scheint als wäre bei dir die Konti-Gleichung nicht erfüllt, was wohl durch falsche Randbedingungen hervorgerufen wird. Ich weiß nicht genau, wie deine Zuordnung der Randbedingungen ist, aber so wie ich es verstanden habe sind sideX und sideY deine Einlass bzw Auslass links und rechts? Wieso hast du die denn auf empty gesetzt? Wenn du quasi 2D rechnen willst, müsstest du glaube ich die obere und untere Seite auf empty setzen. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 08. Feb. 2021 11:24 <-- editieren / zitieren --> Unities abgeben:
Habe die Analogie zu meinem Fall wohl nicht ganz richtig verstanden und dann die falschen Seiten auf empty gesetzt. Habe jetzt aber mal top und bottom auf empty gesetzt und nach ca. 16000 Iterationen folgenden Fehler erhalten: Code: [10] #0 Foam::error: rintStack(Foam::Ostream&)sh: 1: addr2line: not found addr2line failed [10] #1 Foam::sigSegv::sigHandler(int)sh: 1: addr2line: not found addr2line failed [10] #2 ?sh: 1: addr2line: not found addr2line failed [10] #3 Foam::fv::gaussGrad<Foam::Vector<double> >::gradf(Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::word const&)sh: 1: addr2line: not found addr2line failed [10] #4 Foam::fv::gaussGrad<Foam::Vector<double> >::calcGrad(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) constsh: 1: addr2line: not found addr2line failed [10] #5 Foam::fv::gradScheme<Foam::Vector<double> >::grad(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) constsh: 1: addr2line: not found addr2line failed [10] #6 Foam::tmp<Foam::GeometricField<Foam: uterProduct<Foam::Vector<double>, Foam::Vector<double> >::type, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::grad<Foam::Vector<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&)sh: 1: addr2line: not found addr2line failed [10] #7 Foam::linearViscousStress<Foam::laminarModel<Foam::IncompressibleTurbulenceModel<Foam::transportModel> > >::DevRhoReff() constsh: 1: addr2line: not found addr2line failed [10] #8 Foam::IncompressibleTurbulenceModel<Foam::transportModel>::DevReff() constsh: 1: addr2line: not found addr2line failed [10] #9 Foam::functionObjects::forces::DevRhoReff() constsh: 1: addr2line: not found addr2line failed [10] #10 Foam::functionObjects::forces::calcForcesMoment()sh: 1: addr2line: not found addr2line failed [10] #11 Foam::functionObjects::forces::execute()sh: 1: addr2line: not found addr2line failed [10] #12 Foam::functionObjects::timeControl::execute()sh: 1: addr2line: not found addr2line failed [10] #13 Foam::functionObjectList::execute()sh: 1: addr2line: not found addr2line failed [10] #14 Foam::Time::run() constsh: 1: addr2line: not found addr2line failed [10] #15 Foam::Time::loop()sh: 1: addr2line: not found addr2line failed [10] #16 Foam::simpleControl::loop()sh: 1: addr2line: not found addr2line failed [10] #17 ?sh: 1: addr2line: not found addr2line failed [10] #18 __libc_start_mainsh: 1: addr2line: not found addr2line failed [10] #19 ?sh: 1: addr2line: not found addr2line failed [DESKTOP-3IFQ04O:00538] *** Process received signal *** [DESKTOP-3IFQ04O:00538] Signal: Segmentation fault (11) [DESKTOP-3IFQ04O:00538] Signal code: (-6) [DESKTOP-3IFQ04O:00538] Failing at address: 0x3e80000021a [DESKTOP-3IFQ04O:00538] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x46210)[0x7fc91d356210] [DESKTOP-3IFQ04O:00538] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fc91d35618b] [DESKTOP-3IFQ04O:00538] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x46210)[0x7fc91d356210] [DESKTOP-3IFQ04O:00538] [ 3] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam2fv9gaussGradINS_6VectorIdEEE5gradfERKNS_14GeometricFieldIS3_NS_13fvsPatchFieldENS_11surfaceMeshEEERKNS_4wordE+0x33b)[0x7fc921fd694b] [DESKTOP-3IFQ04O:00538] [ 4] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZNK4Foam2fv9gaussGradINS_6VectorIdEEE8calcGradERKNS_14GeometricFieldIS3_NS_12fvPatchFieldENS_7volMeshEEERKNS_4wordE+0x4f)[0x7fc921fd6e4f] [DESKTOP-3IFQ04O:00538] [ 5] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZNK4Foam2fv10gradSchemeINS_6VectorIdEEE4gradERKNS_14GeometricFieldIS3_NS_12fvPatchFieldENS_7volMeshEEERKNS_4wordE+0x1a5)[0x7fc921cc5a25] [DESKTOP-3IFQ04O:00538] [ 6] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam3fvc4gradINS_6VectorIdEEEENS_3tmpINS_14GeometricFieldINS_12outerProductIS3_T_E4typeENS_12fvPatchFieldENS_7volMeshEEEEERKNS5_IS7_SA_SB_EE+0xa7)[0x7fc921cee837] [DESKTOP-3IFQ04O:00538] [ 7] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libincompressibleTurbulenceModels.so(_ZNK4Foam19linearViscousStressINS_12laminarModelINS_29IncompressibleTurbulenceModelINS_14transportModelEEEEEE10devRhoReffEv+0x141)[0x7fc91f094691] [DESKTOP-3IFQ04O:00538] [ 8] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libincompressibleTurbulenceModels.so(_ZNK4Foam29IncompressibleTurbulenceModelINS_14transportModelEE7devReffEv+0xd)[0x7fc91efdc07d] [DESKTOP-3IFQ04O:00538] [ 9] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZNK4Foam15functionObjects6forces10devRhoReffEv+0xcc)[0x7fc900e668fc] [DESKTOP-3IFQ04O:00538] [10] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZN4Foam15functionObjects6forces16calcForcesMomentEv+0x1972)[0x7fc900e68b62] [DESKTOP-3IFQ04O:00538] [11] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZN4Foam15functionObjects6forces7executeEv+0x11)[0x7fc900e64861] [DESKTOP-3IFQ04O:00538] [12] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x52)[0x7fc91e14ccc2] [DESKTOP-3IFQ04O:00538] [13] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x13c)[0x7fc91e13d86c] [DESKTOP-3IFQ04O:00538] [14] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0xaf)[0x7fc91e15864f] [DESKTOP-3IFQ04O:00538] [15] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam4Time4loopEv+0x12)[0x7fc91e158912] [DESKTOP-3IFQ04O:00538] [16] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam13simpleControl4loopEv+0x75)[0x7fc9220bfc85] [DESKTOP-3IFQ04O:00538] [17] simpleFoam[0x42181c] [DESKTOP-3IFQ04O:00538] [18] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fc91d3370b3] [DESKTOP-3IFQ04O:00538] [19] simpleFoam[0x425ca1] [DESKTOP-3IFQ04O:00538] *** End of error message ***
Könnte es bei diesem Fehler etwas bringen, in fvSchemes das gradScheme zu ändern? Habe da derzeit Gauss linear drin, bzw. folgendes: Code: ddtSchemes { default steadyState; }gradSchemes { default Gauss linear; } divSchemes { default Gauss linear; div(phi,U) Gauss limitedLinearV 1; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; p ; }
Es tauchen einfach immer wieder Fehlermeldungen auf und ich hab keine Ahnung, weshalb Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010 ESI-OpenCFD OpenFOAM v2312
|
erstellt am: 08. Feb. 2021 18:27 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Zitat: Original erstellt von Friendly: Interessant, den Fehler hatte ich bislang noch nicht.Scheint als wäre bei dir die Konti-Gleichung nicht erfüllt, was wohl durch falsche Randbedingungen hervorgerufen wird. Ich weiß nicht genau, wie deine Zuordnung der Randbedingungen ist, aber so wie ich es verstanden habe sind sideX und sideY deine Einlass bzw Auslass links und rechts? Wieso hast du die denn auf empty gesetzt? Wenn du quasi 2D rechnen willst, müsstest du glaube ich die obere und untere Seite auf empty setzen.
Das ist kein Fehler sondern das System wurde mit Randbedingungen belegt, die keine Lösung ergeben können (Können also unendlich viele sein).
Solltet Ihr nicht weiterkommen, könnt Ihr mich gerne dazuholen. Ich löse dann für euch auf ------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hulli1 Mitglied
Beiträge: 61 Registriert: 23.01.2020 --
|
erstellt am: 09. Feb. 2021 11:15 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Hi, also ich hatte den Fehler eigentlich, nur wenn die Randbedingungen nicht richtig gesetzt waren und mehr Fluid ins System hereinkam als wieder raus ... Soweit ich mich erinnere, waren meistens die Settings im p Feld das Böse ... Nun gut um das ganze zu debuggen würde ich vorschlagen Du nimmst den Motorbike case zur Hilfe. Dazu würde ich so vorgehen: - Motorbike case von Tutorials in Dein Arbeitsverzeichnis kopieren - Case anpassen damit der ohne allrun Skript lauft bzw. das stl für das motorbike in constant/trisurface kopieren - nu auf 1e-6 setzen, falls Du Wasser simulieren willst in den transportproperties - Rechen lassen blockMesh | surfaceFeatureextract | snappyHexmesh | simpleFoam oder pimpleFoam - hoffen, dass alles geklappt hat Deinen Case an den Motorbike case anpassen - snappyHexmesh des Motorbike cases anpassen bzw. copypaste Deines snappyHexmeshDict files anstelle dessen aus dem Motorbike case - Randbedingungen auf die Bezeichnungen Deiner patches im 0 folder anpassen also U p und nut. Ich meine alles ergänzen, was Dir an Randbedingungen noch fehlt, die Du zusätzlich benötigst um Deune komplexe Geometrie mit Randbedingungen zu definieren snappyHexmeshes ... sonst würde ich da gar nichts mehr ändern... und dann rechnen lassen. - ggf musst Du den solver anpassen und nach simpleFoam umstellen Die idee dahinter ist einfach Deine Geometire mit den settings eines existierenden tutorial cases zuverheiraten ... Damit setellst Du sicher dass die scemes Randbedingungen etc. halbwegs vernünftig eingestellt sind und das Ding nicht gleich explodiert ... Falls Dir der Motorbike case zu blöde ist kannst Du Dir auch den case channel396 in den Tutorials ansehen und die zyklischen Randbedingungen mit inlet outlet Randbedingungen ersetzen wie im Motorbike case. Ich weiß, es nervt ohne Ende aber Du schaffst das ... LG H
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 10. Feb. 2021 13:59 <-- editieren / zitieren --> Unities abgeben:
Kleines Update: mein Mesh wurde jetzt mit kommerzieller Software einmal generiert statt mit snappyHex und siehe da, alles konvergiert wunderbar. Jetzt stellt sich mir jedoch die Frage, warum OpenFOAM dann bei checkMesh anzeigt, dass alles in Ordnung ist... aber gut. Ich habe noch einen anderen Ansatz, bei dem ich in fvSchemes ein paar Einstellungen geändert habe (im Wesentlichen das fvSchemes aus dem cavity-Fall übernommen nur bei divSchemes "Gauss linear" anstelle von "none" eingetragen, weil der gemeckert hatte) und gleichzeitig die Höhe in z-Richtung von 0,5 mm auf 0,05 mm reduziert habe. Und da siehts momentan eigentlich auch ganz ok aus. @hulli1: den motorBike Fall habe ich mir mal kurz angeschaut. Dort wird aber mit einem Turbulenzmodell gerechnet, was bei mir ja nicht der Fall ist. Daher war ich da erstmal zu faul, alles einzustellen und zu gucken, ob das überhaupt etwas wird Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 15. Feb. 2021 10:22 <-- editieren / zitieren --> Unities abgeben:
Okay, mit einer Geometrie hat es mit dem neuen Mesh geklappt, mit der anderen jetzt wieder nicht. Gleicher Fehler, irgendwann entstehen punktuell extrem hohe Geschwindigkeiten. Jetzt weiß ich nun wirklich nicht mehr weiter, denn mit den Randbedingungen etc. habe ich schon rumgespielt... @Shor-ty: könntest du da eventuell weiterhelfen? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010 ESI-OpenCFD OpenFOAM v2312
|
erstellt am: 01. Mrz. 2021 08:10 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 04. Mrz. 2021 08:25 <-- editieren / zitieren --> Unities abgeben:
Ob das ein Problem bedingt durch das snappyHexMesh war oder durch die Simulation weiß ich leider nicht. Habe es jetzt so hinbekommen, dass ich die entsprechenden timesteps, bei denen es einen Geschwindigkeitssprung gab (habe festgestellt, dass die residuals einen Sprung nach oben um ca. 2 Dekaden gemacht haben) gelöscht und die Simulation dort angefangen, wo der Fehler noch nicht aufgetreten ist. Hat dann im Großen und Ganzen eigentlich gut funktioniert und die Ergebnisse sind auch sehr plausibel! Im Anhang kannst Du aber dennoch das snappyHexMesh (bzw. die Dateien dafür, das war zu groß, um es hier hochzuladen) vorfinden. checkMesh sagt, dass alles in Ordnung ist und das mesh sieht meiner Meinung nach auch OK aus. Vielleicht findest Du ja trotzdem irgendeine Schwachstelle, die ich übersehen habe Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010 ESI-OpenCFD OpenFOAM v2312
|
erstellt am: 04. Mrz. 2021 09:02 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93 Mitglied
Beiträge: 37 Registriert: 03.02.2021
|
erstellt am: 04. Mrz. 2021 11:40 <-- editieren / zitieren --> Unities abgeben:
|
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|