---

Skizze.jpg

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

/*--------------------------------*- 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      controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

application    icoFoam;

startFrom      latestTime;

startTime      0;

stopAt          endTime;

endTime        250;

deltaT          1.0;

writeControl    timeStep;

writeInterval  1;

purgeWrite      0;

writeFormat    ascii;

writePrecision  6;

writeCompression off;

timeFormat      general;

timePrecision  6;

runTimeModifiable true;


// ************************************************************************* //

Code: transport Properties

/*--------------------------------*- 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    "constant";
    object      transportProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

nu              0.01;


// ************************************************************************* //

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

---

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

---

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

---

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

---

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

---

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

---

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

---

Hi,

um dem Thema hier nicht ganz fremd zu werden, kurze Antwort.

- Englisch weil wenn ichs auf Deutsch schreiben würde, sich dafür wahrscheinlich nur 10 - 20 Leute interessieren würden. Auf Englisch --> Weltweit. Ist auch mit Abstand meine Beste Veröffentlichung mit 12 Zitierungen.

------------------
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

---

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

---

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

---

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

---

Ich kann mit dem Begriff 'verrechnen' nicht viel anfangen? Was meinst Du hier? Wenn man zwei Netze vereinigt, dann muss am interface die konservatiität auch gegeben sein. Heißt, du kannst keine zwei faces aufeinander liegen haben etc.

Ach ja, die Frage wäre in einem neuen Thread besser aufgehoben.

------------------
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

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

---

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

---

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

---

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

---

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

---

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

---

Eine Korrektur hilft im Allgemeinen, da hierdurch die expliziten Terme korrigiert werden.

------------------
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP