| | | Wie Sie mit 3D-Druck glattere Oberflächen erhalten, eine Pressemitteilung
|
Autor
|
Thema: Strömung hat störung (2352 / mal gelesen)
|
TobsR Mitglied Bauingenieur
Beiträge: 2 Registriert: 30.12.2019
|
erstellt am: 30. Dez. 2019 20:28 <-- editieren / zitieren --> Unities abgeben:
Hallo liebe User, ich versuche in Anlehnung an das Tutorial zum incompressible/icoFoam/elbow ein eigenes System zu machen, jedoch tritt ein Fehler für die Strömung auf. Als Folge wird nach wenigen Schritte keine Änderung mehr berechnet wodurch die Berechnung anschließend abgebrochen wird. Das Abbrechen der Rechnung ist nicht das Hauptproblem, das Problem liegt dran, dass die Strömung nicht fließt, wie ich es erhofft hätte. Bei der Suche nach dem Fehler warum die Konvergenz so früh erreicht wird habe ich an den Größen der Zellen, der Fließgeschwindigkeiten, Toleranzen der Solver die Schrauben verstellt. Bei einer Einstellung hat die ansicht in Paraview gezeigt, dass die Strömung gefangen ist in den Blöcken an denen die Inlet patches sich befinden. Es bildeten sich Wirbel an den anschließenden Wänden. Der Wirbel in Block 5 hat sich fast über den ganzen Block ausgebreitet, die Wirbel in Block 1 und 2 hingegen nur direkt an der Wand. Folgender Aufbau: Ich möchte eine 2D Berechnung für ein Gewässer (1Inlet+1Outlet) machen in welches ein Kraftwerk erhitztes Kühlwasser (1Inlet) einleitet. In dem Gewässer soll zusätzlich eine Buhne sein, welche die Strömung vom Kraftwerkauslass in die Gewässermitte ableiten soll.
Im ersten Schritt wollte ich zunächst eine schlichte icoFoam über das System laufen lassen, um dann im zweiten Schritt scalarTransportFoam mit dem letzten Stand von U die Temperatur im Gewässer ermitteln möchte. Falls sie Frage hier im Forum schon mal aufgetaucht sei, bitte ich um Verzeihung. Falls der Thread schnell aufzufinden sei, bitte ich auch gerne um Verlinkung. Ich freue mich Sehr über Rückmeldung zur Fehlerkorrektur. Vorschläge zur anderen Umsetzung mit anderen Solvern, oder, oder, sind ebenfalls sehr willkommen. Freundliche Grüße Newbie Tobs Eine einfache Skizze zu meinem System Aufbau siehe Datei-Anhänge. Des Weiteren die Datein aus meinem Projekt. (Kann man die Code anders/besonders einbinden?) Code: U
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1906 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volVectorField; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { Wall_right { type noSlip; } Wall_left { type noSlip; } inletOne { type fixedValue; value uniform (6 0 0); } inletTwo { type fixedValue; value uniform (0 -10 0); } outlet { type zeroGradient; } frontAndBackPlanes { type empty; } } // ************************************************************************* // Code: p
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1906 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volScalarField; object p; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dimensions [0 2 -2 0 0 0 0]; internalField uniform 0; boundaryField { Wall_right { type zeroGradient; } Wall_left { type zeroGradient; } inletOne { type zeroGradient; } inletTwo { type zeroGradient; } outlet { type fixedValue; value uniform 0; } frontAndBackPlanes { type empty; } } // ************************************************************************* // Code:blockMeshDic
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1906 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object blockMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //scale 1.0; // convertToMeters: 1m * scale = [Einheit] vertices ( (0 0 0) //0 - unten, rechtes Ufer, Startpunkt (20 0 0) //1 - unten, rechtes Ufer, gegenüber ende Auslasswand1 (7) (35 0 0) //2 - unten, rechtes Ufer, gegenüber ende Auslasswand2 (8) (50 0 0) //3 - unten, rechtes Ufer, gegenüber Buhnenkopf1 (14) (60 0 0) //4 - unten, rechtes Ufer, gegenüber Buhnenkopf2 (15) (200 0 0) //5 - unten, rechtes Ufer, Endpunkt (0 180 0) //6 - unten, linkes Ufer, Startpunkt (20 180 0) //7 - unten, linkes Ufer, ende Auslasswand1 (35 180 0) //8 - unten, linkes Ufer, ende Auslasswand2 (50 180 0) //9 - unten, linkes Ufer, Buhnenwurzel1 (60 180 0) //10 - unten, linkes Ufer, Buhnenwurzel2 (200 180 0) //11 - unten, linkes Ufer, Endpunkt (20 200 0) //12 - unten, anfang Auslasswand1 (35 200 0) //13 - unten, anfang Auslasswand2 (50 120 0) //14 - unten, Buhnenkopf1 (60 120 0) //15 - unten, Buhnenkopf2 (0 0 1) //16 - oben, rechtes Ufer, Startpunkt (20 0 1) //17 - oben, rechtes Ufer, gegenüber ende Auslasswand1 (23) (35 0 1) //18 - oben, rechtes Ufer, gegenüber ende Auslasswand2 (24) (50 0 1) //19 - oben, rechtes Ufer, gegenüber Buhnenkopf1 (30) (60 0 1) //20 - oben, rechtes Ufer, gegenüber Buhnenkopf2 (31) (200 0 1) //21 - oben, rechtes Ufer, Endpunkt (0 180 1) //22 - oben, linkes Ufer, Startpunkt (20 180 1) //23 - oben, linkes Ufer, ende Auslasswand1 (35 180 1) //24 - oben, linkes Ufer, ende Auslasswand2 (50 180 1) //25 - oben, linkes Ufer, Buhnenwurzel1 (60 180 1) //26 - oben, linkes Ufer, Buhnenwurzel2 (200 180 1) //27 - oben, linkes Ufer, Endpunkt (20 200 1) //28 - oben, anfang Auslasswand1 (35 200 1) //29 - oben, anfang Auslasswand2 (50 120 1) //30 - oben, Buhnenkopf1 (60 120 1) //31 - oben, Buhnenkopf2 (35 120 0) //32 - unten, Buhne links (35 120 1) //33 - oben, Buhne links (200 120 0) //34 - unten, Buhne rechts (200 120 1) //35 - oben, Buhne rechts (20 120 0) //36 - unten, Flussmitte (20 120 1) //37 - oben, Flussmitte (0 120 0) //38 - unten, mitte Einlass (0 120 1) //39 - oben, mitte Einlass ); blocks ( hex (0 1 36 38 16 17 37 39) (20 120 1) simpleGrading (1 1 1) // 1 Haupt hex (38 36 7 6 39 37 23 22) (20 60 1) simpleGrading (1 1 1) // 2 Haupt hex (1 2 32 36 17 18 33 37) (15 120 1) simpleGrading (1 1 1) // 3 Haupt hex (36 32 8 7 37 33 24 23) (15 60 1) simpleGrading (1 1 1) // 4 Haupt hex (7 8 13 12 23 24 29 28) (15 20 1) simpleGrading (1 1 1) // 5 Auslass hex (2 3 14 32 18 19 30 33) (15 120 1) simpleGrading (1 1 1) // 6 Haupt hex (32 14 9 8 33 30 25 24) (15 60 1) simpleGrading (1 1 1) // 7 Haupt hex (3 4 15 14 19 20 31 30) (10 120 1) simpleGrading (1 1 1) // 8 Haupt // hex (14 15 10 9 30 31 26 25) (10 60 1) simpleGrading (1 1 1) // 9 Buhne hex (4 5 34 15 20 21 35 31) (140 120 1) simpleGrading (1 1 1) // 10 Haupt hex (15 34 11 10 31 35 27 26) (140 60 1) simpleGrading (1 1 1)// 11 Haupt ); edges ( ); boundary ( Wall_right { type wall; faces ( (0 1 17 16) // rechtes Ufer, 1 Haupt (1 2 18 17) // rechtes Ufer, 2 Haupt (2 3 19 18) // rechtes Ufer, 3 Haupt (3 4 20 19) // rechtes Ufer, 4 Haupt (4 5 21 20) // rechtes Ufer, 5 Haupt ); } Wall_left { type wall; faces ( (7 6 22 23) // linkes Ufer, 1 Haupt (12 7 23 28) // Auslasswand1 (8 13 29 24) // Auslasswand2 (9 8 24 25) // linkes Ufer, 3 Haupt (14 9 25 30) // Buhnenwand1 (15 14 30 31) // Buhnenkopf (10 15 31 26) // Buhnenwand2 (11 10 26 27) // linkes Ufer, 5 Haupt ); }
inletOne { type patch; faces ( (13 12 28 29) // Kraftwerk Auslass ); } inletTwo { type patch; faces ( (6 38 39 22) // Fluss, Block 1 (38 0 16 39) // Fluss, Block 2 ); } outlet { type patch; faces ( (5 34 35 21) // Fluss, Block 10 (34 11 27 35) // Fluss, Block 11 ); }
frontAndBackPlanes { type empty; faces ( (16 17 37 39) // 1 Block, oben (39 37 23 22) // 2 Block, oben (17 18 33 37) // 3 Block, oben (37 33 24 23) // 4 Block, oben (23 24 29 28) // 5 Block, oben (18 19 30 33) // 6 Block, oben (33 30 25 24) // 7 Block, oben (19 20 31 30) // 8 Block, oben //(30 31 26 25) // 9 Block, oben (20 21 35 31) // 10 Block, oben (31 35 27 26) // 11 Block, oben
(1 0 38 36) // 1 Block, unten (36 38 6 7) // 2 Block, unten (2 1 36 32) // 3 Block, unten (32 36 7 8) // 4 Block, unten (8 7 12 13) // 5 Block, unten (3 2 32 14) // 6 Block, unten (14 32 8 9) // 7 Block, unten (4 3 14 15) // 8 Block, unten //(15 14 9 10) // 9 Block, unten (5 4 15 34) // 10 Block, unten (34 15 10 11) // 11 Block, unten ); } ); mergePatchPairs ( ); // ************************************************************************* // Code:controlDic
Code: transport Properties
Code: fvSchemes
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1906 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSchemes; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //ddtSchemes { default Euler; } gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,U) Gauss limitedLinearV 1; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } // ************************************************************************* //
Code: fvSolution
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1906 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSolution; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //solvers { p { solver PCG; preconditioner DIC; tolerance 1e-06; relTol 0.05; } pFinal { $p; relTol 0; } U { solver smoothSolver; smoother symGaussSeidel; tolerance 1e-05; relTol 0; } } PISO { nCorrectors 3; nNonOrthogonalCorrectors 3; } // ************************************************************************* //
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Tempolini Mitglied
Beiträge: 16 Registriert: 05.09.2019 Salome Meca 9.3.0 OpenFOAM 7
|
erstellt am: 09. Jan. 2020 09:22 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hallo Tobs, ich schaffe es gerade nicht mit in der Tiefe mit deinem Case zu beschäftigen. Drei Dinge fallen mit spontan beim Überfliegen auf: Wozu nonOrthogonalCorrectors??? Hast du checkMesh mal gefragt? Ich kann mir nicht vorstellen, dass deine Non-orthogonality-Werte so schlecht sind. Erwartest du keine Turbulenzen? Wenn doch, würde ich simpleFoam bevorzugen. Eventuell sind Rückströmungen am Auslass zu erwarten bei deinem Fall. Ich weiß es nicht. Habe wie geschrieben den Beitrag nur überflogen und mir fiehl spontan ein, dass du dir inletOutlet mal anschauen könntest als Auslassrandbedingung. Schau mal hier: https://www.cfdsupport.com/OpenFOAM-Training-by-CFD-Support/node114.html
------------------ Gruß an alle Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 09. Jan. 2020 21:29 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Zitat: Original erstellt von Tempolini: Wozu nonOrthogonalCorrectors??? Hast du checkMesh mal gefragt? Ich kann mir nicht vorstellen, dass deine Non-orthogonality-Werte so schlecht sind.
Da unser Tobs es mit blockMesh gemacht hat gehe ich von einer non-Orthogonalität von 0 aus. Also überflüssig, genau so wie die numerischen Schemen. Die könnte man hierzu auch anpassen.
Zitat: Original erstellt von Tempolini: Erwartest du keine Turbulenzen? Wenn doch, würde ich simpleFoam bevorzugen.
Diese Aussage verstehe ich nicht. Was hat Turbulenz mit den Solvern zu tun? Schön übrigens mal eine Antwort von jemand anderem zu erhalten ------------------ Viele Grüße, Tobi
OpenFOAM® Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Tempolini Mitglied
Beiträge: 16 Registriert: 05.09.2019 Salome Meca 9.3.0 OpenFOAM 7
|
erstellt am: 10. Jan. 2020 08:59 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Zitat: Original erstellt von Shor-ty:
Da unser Tobs es mit blockMesh gemacht hat gehe ich von einer non-Orthogonalität von 0 aus. Also überflüssig, genau so wie die numerischen Schemen. Die könnte man hierzu auch anpassen.
Daran dachte ich auch. Da ich aber den Tread nur überflogen habe, wollte ich gedanklich nicht ausschließen, dass da nicht doch noch anders vernetzt wurde. PS: Ich bin da aber auch etwas "Kontrollfreak" dazu was Netze angeht. Ich fühle mich z.B. mit simpleFoam bei turbulenten Strömungen wohler und hatte auch gelernt, dass icoFoam eher für laminare Strömungen geeignet sei. Ich habe mich jedoch relativ wenig mit icoFoam auseinandergesetzt, da ich in der regel immer mit sehr turbulenten Themen zu tun habe. Von daher: Berichtige mich gerne, wenn ich das falsch gelernt habe und icoFoam zu Unrecht ignoriere für meine Themen. Ich nutze meistens simpleFoam oder rhoSimpleFoam oder schon mal pimpleFoam. Mit diesen Solvern war ich auch stets sehr nah an Messergebnissen. Du darfst echt megagern berichtigen. Von dir kann man nur dazulernen. Ich verfolge deine Seite seit Jahren immer mal wieder. ------------------ Gruß an alle
[Diese Nachricht wurde von Tempolini am 10. Jan. 2020 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Tempolini Mitglied
Beiträge: 16 Registriert: 05.09.2019 Salome Meca 9.3.0 OpenFOAM 7
|
erstellt am: 10. Jan. 2020 09:03 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Zitat: Original erstellt von Shor-ty:
Diese Aussage verstehe ich nicht. Was hat Turbulenz mit den Solvern zu tun? Schön übrigens mal eine Antwort von jemand anderem zu erhalten
Eins noch: Da ich neuerdings sehr viel mit OF arbeite, besuche ich das Forum wieder und finde es sehr schade, dass es so ruhig geworden ist. Daher dachte ich, ich würde mich gerne etwas einbringen in der Hoffnung es kehr wieder mehr Leben hier ein. Ich war zwischenzeitlich mal weg. Mir kam es früher irgendwie belebter vor. Schade irgendwie. ------------------ Gruß an alle Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 10. Jan. 2020 10:16 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Grüß Dich Tempolini, erstmal Danke für Dein Feedback und das Lob das ich bekommen habe. Derzeit bin ich wieder etwas aktiver bezüglich Neuentwicklungen, Erweiterungen, Tests, Code-Analyse, Bucherweiterung, etc. Kurz zu Deinen Fragen und bezugnehmend auf das Thema hier:
- pisoFoam / simpleFoam / pimpleFoam / icoFoam sind alle für inkompressible Strömungen
- icoFoam ist jedoch nur für Laminare, da fehlt nämlich die Erweiterung divDevREff als Laplacian. Hier wird eben nur mit der molekularen Viskosität gerechnet (und nicht durch die Erhöhte aufgrund der Turbulenz)
- pisoFoam / simpleFoam / pimpleFoam sind für inkompressible / laminare / turbulente Strömungen
- simpleFoam ist hier jedoch besonders, da er nur für stationäre Probleme gilt
- pimpleFoam ist der Solver den man im PIMPLE / PISO / SEMI-SteadyState laufen lassen kann
Da unser Themenersteller den icoFoam verwendet, gehe ich davon aus das er transient Rechnen möchte und da scheidet dann simpleFoam aus. PS: Ja hier ist es sehr ruhig geworden. Hätte eigenltich im Oktober erwartet, dass wieder mehr los ist, da es im Forum eigentlich oft nur wie folgt aussieht:
- Studenten fangen ihre Abschlussarbeit mit OpenFOAM an
- Stellen anschließend einige Fragen hier ins Forum
- Nach Abgabe ist das Thema wieder vom Tisch
Die Fluktuation hier im Forum war schon immer sehr extrem. Es gibt nur 3 - 5 Leute die hier immer mal wieder etwas posten. Da ich Moderator bin, bekomm ich natürlich immer eine Email, wenn hier was passiert Der Grund wieso das hier stark abnimmt kann natürlich auch daher rühren, weil es viel mehr Möglichkeiten gibt, OpenFOAM zu lernen. Es gibt mehr Quellen, besser sortierte Quellen, mehr Informationen etc. Aber das ist nur eine Spekulation. ------------------ Viele Grüße, Tobi OpenFOAM® Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Tempolini Mitglied
Beiträge: 16 Registriert: 05.09.2019 Salome Meca 9.3.0 OpenFOAM 7
|
erstellt am: 10. Jan. 2020 11:37 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hallo Shor-Ty, erstmal danke für deine Antwort. ...dann lag ich ja gar nicht sooo falsch ich hatte nur den icoFoam nicht nur laminar sondern auch stationär in Erinnerung. Bei den anderen war mit das klar. Die nutze ich ja. Dennoch lieben Dank für deine Antworten. Schön, dass du an deinem Buch weiterschreibst. Darf man fragen wieso auf Englisch? ------------------ Gruß an alle Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 10. Jan. 2020 12:27 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
|
TobsR Mitglied Bauingenieur
Beiträge: 2 Registriert: 30.12.2019
|
erstellt am: 25. Jan. 2020 09:25 <-- editieren / zitieren --> Unities abgeben:
Hallo Tempolini und Shor-ty, entschuldigt meine späte Antwort. Um ehrlich gesagt hatte ich das Forum als mehr oder weniger inaktiv betrachtet und hatte nicht mehr mit einer Antwort gerechnet. Zu den Inlets, da gab es tatsächlich einen Fehler. Ich hatte für Inlet1 und Inlet2 jeweils die X und Y werte vertauscht. Damit war mein Problem jedoch immer noch nicht beseitigt. Letzten endes weiss ich aber auch nicht was genau die Lösung von dem Problem war. Eig hatte ich das Problem Projekt nur Kopiert und das blockMeshDict neu abgespeichert. Anschließend ging die Berechnung problemlos. Ich kann mir eig nur iein Bug erklären, da ich keine andern Änderungen vorgenommen habe.
Mit non-Orthogonalität, nonOrthogonalCorrectors habe ich mich nicht beschäftigt, ich weiss auch nicht so recht, wann man diese überhaupt brauchen würde, bzw. wann probleme mit der Orthogonalität entstehen würde.
Zu dem solver icoFoam, das Projekt sollte ein breiter Fluss sein, mit eigentlich kleinen Strömungsgeschwindigkeiten, daher nahm ich laminar als ausreichend an. Im geposteten script zu U waren die Geschwindigkeiten so hoch, da ich diese beim Testen des Problems hochgeschraubt hatte. Für einen genauren Solver hatte ich mich noch nicht beschäfitgt, da ich bei diesem Projekt noch nicht die anforderung dazu war, bzw. mein Englisch auch echt schlecht ist, weshalb ich mich sehr schwer mit den Guids und Tutorials gebe. Für ein anderes Projekt, bzw mehrere Projekte mit dem gleichem Thema werde ich mich jedoch wohl noch stark beschäftigen. Ich werde dafür einen Solver brauchen, bzw eine Modellierung die ein Gerinne also Fluss sehr realistisch wiederspiegelt. Mit Rauheit des Gerinnes, Strömungen entsprechend des Wasserstandes, Gefälle und der Erdanziehungskraft, Atmosphärischen druck an Wasserspiegeloberkante, freiem Wellengang (direkt erzeugt an einem Inlet), Temperatur des Wassers, Salsgehalt, Dichte, etc. und alles am aller liebsten in einem Solver.
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: 25. Jan. 2020 22:22 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Zitat: Ich kann mir eig nur iein Bug erklären, da ich keine andern Änderungen vorgenommen habe.
Leider wird das nicht so sein. Irgendwas war anders. Als Einsteiger denkt man das oft aber letztlich hat man irgendwo noch eine Kleinigkeit gemacht, oder war irgendwie noch was vom Alten übrig und schwups gehts nicht. Bug kann ich bei Deinem Problem ausschließen. Non-Orthogonalität brauchst Du nicht, weil Du mit BlockMesh arbeitest und deine Blöcke alle ausgerichtet sind. Zitat:
Für einen genauren Solver hatte ich mich noch nicht beschäfitgt, da ich bei diesem Projekt noch nicht die anforderung dazu war, bzw. mein Englisch auch echt schlecht ist, weshalb ich mich sehr schwer mit den Guids und Tutorials gebe.
Die Auswahl des Lösers ist eigentlich die erste Aufgabe, da in FOAM jeder Löser eigentlich für bestimmte Probleme gedacht ist. Zitat:
Für ein anderes Projekt, bzw mehrere Projekte mit dem gleichem Thema werde ich mich jedoch wohl noch stark beschäftigen. Ich werde dafür einen Solver brauchen, bzw eine Modellierung die ein Gerinne also Fluss sehr realistisch wiederspiegelt.
Wenn Du Dich bezüglich non-Orthogonalität nicht auskennst, dann solltest Du Dir wirklich erstmal ein paar Wochen nehmen und die Mathematik verstehen lernen. Gerinne vorab -> driftFluxFoam Zitat:
Mit Rauheit des Gerinnes, Strömungen entsprechend des Wasserstandes, Gefälle und der Erdanziehungskraft, Atmosphärischen druck an Wasserspiegeloberkante, freiem Wellengang (direkt erzeugt an einem Inlet), Temperatur des Wassers, Salsgehalt, Dichte, etc. und alles am aller liebsten in einem Solver.
Teilweise machbar aber die Kombination aus allem definitiv nicht mit den Standard Lösern. Mit Deinem derzeitigen Wissenstand dürfte Dich das schon einige Zeit in Anspruch nehmen. Aber sehr interessant - Du wirst viel lernen. Übrigens, ja das Forum ist Tot. Dennoch bekomm ich als Moderator stets eine Email Die Frage ist immer nur, ob ich gleich antworte :P ------------------ Viele Grüße, Tobi OpenFOAM® Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Chris-1989 Mitglied Student
Beiträge: 9 Registriert: 11.09.2021
|
erstellt am: 11. Sep. 2021 09:47 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hallo liebe Community Gemeinde, Ich habe eine Frage zu stitch mesh.Beim stitchen zweier Patches werden die beiden patches bzgl ihrer Faces nicht auf null gesetzt.Verrechnet werden sie , also sie haben jeweils eine andere Anzahl an Faces bekommen aber wie gesagt nicht Null. Was kann die Ursache hierfür sein? Besten Dank Chris 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: 11. Sep. 2021 11:25 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
|
Ermon Mitglied
Beiträge: 10 Registriert: 11.09.2021
|
erstellt am: 11. Sep. 2021 14:10 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hallo, Chris und ich bearbeiten momentan denselben Case und stehen an dem oben beschriebenen Problem. Wir haben die gesamt Geometrie in mehrere Bereiche geteilt und über mergeMeshes die Netze miteinander verbunden. Nun versuchen wir über stitchMeshes die patches „verschwinden“ zu lassen, wir sind uns nicht sicher, ob das der richtige Ansatz ist oder ob es reicht boundaryConditions an den patches zu formulieren, damit die Strömung durch die gesamte Geometrie fließen kann. PS Die anderen Bereiche der Geometrie wurden über AMI-Schnittstellen miteinander verbunden, da dort zwischen den patches eine Relativbewegung vorliegt. Und eine AMI-Schnittstelle an einer „statischen“ Schnittstelle möchten wir vermeiden. Liebe Grüße, Ermon Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Chris-1989 Mitglied Student
Beiträge: 9 Registriert: 11.09.2021
|
erstellt am: 11. Sep. 2021 14:16 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Danke für die schnelle Antwort. Im Rahmen meiner Masterarbeit muss ich ein Radialverdichter simulieren. Hierzu muss ich das Gehäuse mit einem Diffusor Zusammenfügen.Dies hab ich bereits gemacht über mergeMeshes. Jetzt liegen meine stl dateien (diffusor-Auslass und Gehäuse-Einlass)genau aufeinander welche letztendlich auch meine Schittstelle bilden.Diffusor-auslAss und Gehäuse-Einlass sind jeweils patches.Da die Strömung ja aber von dem Diffusor in das Gehäuse übergehen soll möchte ich die zwei patches entfernen.Dies dachte ich geht über stitch mesh, was dazu führt dass die faces der beiden Patches auf null gesetzt werden.werden sie aber nicht, sondern bekommen jeweils nur eine andere Anzahl an faces. Ich bin noch relativ neu in der Openfoam Welt. Was mach ich hier falsch bzw wie kann man das Problem vll eventuell besser lösen. Vielen Dank Tobi Gruß Chris 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. Okt. 2021 14:26 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Ach hier war ja auch noch ein Thema offen. Also man kann mit stitchMesh versuchen die Patches zu verbinden wird aber nicht so zum Ziel führen, wie Ihr Euch das vorstellt. Wenn man das Netz tatsächlich in mehrere einzelne Bereiche teilt und dann versucht zu mergen kommt man mei komplexen Sachen nicht zum Ziel.
- Entweder man vernetzt alles auf einmal
- Man muss interfaces wie AMI oder ähnliches definieren
Für static-regionen natürlich ziemlich doof. Alternativ fällt mir hier nichts weiter ein. ------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ermon Mitglied
Beiträge: 10 Registriert: 11.09.2021
|
erstellt am: 14. Okt. 2021 18:51 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Schönen guten Abend ich bin relativ neu hier und in der OpenFoam-Welt, daher weiß ich nicht genau in welchen Bereich ich eine Frage stellen kann. Ich probiere das einfach mal hier. Ich bin gerade dabei einen Radialverdichter zu simulieren. Ich gehe hierbei mit der Frozen-Rotor-Methode vor und möchte die rhoSimpleFoam-Lösung auf einen rhoPimpleFoam-Case mappen, um damit die instationäre Lösung für mein Strömungsproblem ermitteln. Hierbei enstehen folgende zwei Probleme: 1. Laut Residuen-Verlauf ist die Lösung konvergiert. Die Geschwindigkeit steigt trotzdem immer weiter an. 2. Wenn ich die "konvergierte Lösung" auf den rhoPimpleFoam-Case mappe divergiert meine Lösung nach einigen Zeitschritten.
Die Fragen, die sich mir hierbei ergeben sind:
Ist die Vorgehensweise richtig? Wieso steigt die Geschwindigkeit an, wenn die Lösung scheinbar konvergiert ist? Liebe Grüße,
Ermon 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: 15. Okt. 2021 07:48 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hallo Ermon und willkommen im Forum, Eine Frage wie Du sie hast ist am Besten in einem neuen Beitrag aufgehoben, da es mit der Fragestellung hier nichts zu tun hat. Zum Thema:
- Ja die Vorgehensweise ist richtig
- Residuen sagen nicht immer was über die Konvergenz aus - wir haben hier eine (wenn ich mich richtig erinnere - L2 Norm der Residuen, je mehr Zellen, desto schlechter wirds lokale Veränderungen noch mitzubekommen
- An was hältst Du fest, dass die Lösung konvergiert ist?
- Abbrüche sind durch Aussagen wie Deine nicht einzugrenzen. Möglichkeiten sind:
[list]
- Netzqualität
- Falsche Numerik
- Falsche Randbedingungen
- Falsche Physik
- Falsche Algorithmen
- ...
Wenn die Geschwindigkeit noch ansteigt, dann zeigt das ja davon, dass die Lösung nicht konvergiert ist [/list]------------------ Glück Auf, Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ermon Mitglied
Beiträge: 10 Registriert: 11.09.2021
|
erstellt am: 15. Okt. 2021 08:07 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
Hi Tobias, vielen Dank für die schnelle Antwort ich werde einen neuen Beitrag machen. Trotzdem würde ich zu deiner Antwort noch etwas fragen. Ich lasse die Simulation (rhoSimpleFoam) mit einer Druckkorrektur laufen, da ich im Bereich des Rotors Strömungsablösungen habe. Kann es sein, dass diese Druckkorrektur das Konvergenzverhalten meiner Simulation erschwert? Vielen Dank! 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: 16. Okt. 2021 13:17 <-- editieren / zitieren --> Unities abgeben: Nur für TobsR
|
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|