Hot News:

Unser Angebot:

  Foren auf CAD.de (alle Foren)
  OpenFOAM
  Fehlende Konvergenz Innenströmung k-Epsilon

Antwort erstellen  Neues Thema erstellen
CAD.de Login | Logout | Profil | Profil bearbeiten | Registrieren | Voreinstellungen | Hilfe | Suchen

Anzeige:

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen nächster neuer Beitrag | nächster älterer Beitrag
Autor Thema:  Fehlende Konvergenz Innenströmung k-Epsilon (873 mal gelesen)
FeFoe
Mitglied
Student


Sehen Sie sich das Profil von FeFoe an!   Senden Sie eine Private Message an FeFoe  Schreiben Sie einen Gästebucheintrag für FeFoe

Beiträge: 12
Registriert: 02.04.2020

erstellt am: 29. Mai. 2020 18:22    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Liebe CAD.de-Community,

mein Ziel ist es gerade mit einer Strömungssimulation die Strömungsverhältisse in einem Membranventil mit simpleFoam und dem Standard-k-epsilon-Modell (Vorgabe) bei der Durchströmung mit Wasser zu ermitteln. Die Geometrie liegt als STL-Datei vor, mit blockMesh und snappyHexMesh habe ich das Gitter erstellt. Anschließend im Pre-Processing am Einlass 7,6 m/s als Geschwindigkeit und am Auslass 2 bar (200 m^2*s^-2) eingestellt.

Nun konvergiert die Simulation nicht. Die Residueen liegen auch nach 2000 Iterationen bei Werten im Bereich von 10^-2/10^-3. Zudem liefert die Simulation unphysikalische Ergebnisse. Der Druck am Einlassbereich weicht um mindestens vier Dimensionen vom erwarteten Wert ab. Ich habe bereits verschiedene Gittergrößen (0,5 mm; 0,75 mm; 1 mm) getestet. Das Gitter erfüllt 30 < y+ < 300 und besitzt keine großartigen Fehler:

Code:

s
    points:           1088584
    faces:            3028434
    internal faces:   2874155
    cells:            972660
    faces per cell:   6.0685
    boundary patches: 3
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     852927
    prisms:        59477
    wedges:        0
    pyramids:      0
    tet wedges:    318
    tetrahedra:    4
    polyhedra:     59934
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            4   6394
            5   2783
            6   11197
            7   8659
            8   1192
            9   16926
           10   7
           12   11602
           15   1076
           18   98

Checking topology...
    Boundary definition OK.
    Cell to face addressing 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
                  outlet     1196     1307  ok (non-closed singly connected)
                   inlet     1241     1351  ok (non-closed singly connected)
                    wall   151842   155862  multiply connected (shared edge)
  <<Writing 4 conflicting points to set nonManifoldPoints

Checking geometry...
    Overall domain bounding box (-0.0120914 -0.095067 -0.00835) (0.0118417 0.295067 0.0136329)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (2.51468e-16 -2.00574e-17 -8.88656e-15) OK.
    Max cell openness = 3.41471e-16 OK.
    Max aspect ratio = 20.3961 OK.
    Minimum face area = 2.69967e-09. Maximum face area = 9.5567e-07.  Face area magnitudes OK.
    Min volume = 8.87576e-13. Max volume = 4.56882e-10.  Total volume = 7.58452e-05.  Cell volumes OK.
    Mesh non-orthogonality Max: 64.9869 average: 15.1503
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.20991 OK.
    Coupled point location match (average 0) OK.


Hier zunächst meine boundary-Datein:

Code:

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (0 7.58 0);
    }

    outlet
    {
        type            zeroGradient;
    }

    wall
    {
        type            noSlip;
    }

}


Code:

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
        value           uniform 200;
    }
    wall
    {
        type            zeroGradient;
    }
}


k

Code:

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 1;

boundaryField
{
    inlet
    {
        type            turbulentIntensityKineticEnergyInlet;
        intensity       0.05;
        value           uniform 1;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform 1;
        value           uniform 1;
    }
    wall
    {
        type            kqRWallFunction;
        value           uniform 1;
    }
}


Epsilon

Code:

dimensions      [0 2 -3 0 0 0 0];

internalField   uniform 1;

boundaryField
{
    inlet
    {
        type            turbulentMixingLengthDissipationRateInlet;
        mixingLength    0.0006179;//d_hyd*0,038
        value           uniform 1;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform 1;
        value           uniform 1;
    }
    wall
    {
        type            epsilonWallFunction;
        value           uniform 1;
    }
}



Und die Randbedingungen:

fvSchemes

Code:

ddtSchemes
{
    default         steadyState;
}
gradSchemes
{
    default          cellMDLimited Gauss linear 1.0;
   
}
divSchemes
{
    default            none;
    div(phi,U)          bounded Gauss upwind;
    div(phi,epsilon)    bounded Gauss upwind;
    div(phi,k)          bounded Gauss upwind;

    div((nuEff*dev2(T(grad(U)))))  Gauss linear;
}

laplacianSchemes
{
    default        Gauss linear limited corrected 0.33;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        limited corrected 0.33;
}

wallDist
{
    method meshWave;
}


fvSolution

Code:

solvers
{


    p
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-06;
        relTol          0.01;
    }

    "(U|k|epsilon|R|nuTilda)"
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-05;
        relTol          0.1;
    }

}


SIMPLE
{
    nNonOrthogonalCorrectors 1;
    residualControl
    {
        p              1e-3;
        U              1e-4;
        "(k|epsilon|omega)" 1e-3;
    }
}

relaxationFactors
{
    fields
    {
        p              0.8;
        rho            0.01;
    }
    equations
    {
        U              0.4;
        "(k|omega)"    0.3;
        epsilon        0.3;
    }
}


Getestet hatte ich auch den GAMG(p) smooth solver(*). Der brachte allerdings ähnliche Ergebnisse.

Ich würde mich sehr freuen, wenn ihr mir helfen könnt.

Vielen Dank im Voraus!
Felix

[Diese Nachricht wurde von FeFoe am 29. Mai. 2020 editiert.]

[Diese Nachricht wurde von FeFoe am 06. Jun. 2020 editiert.]

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

FeFoe
Mitglied
Student


Sehen Sie sich das Profil von FeFoe an!   Senden Sie eine Private Message an FeFoe  Schreiben Sie einen Gästebucheintrag für FeFoe

Beiträge: 12
Registriert: 02.04.2020

erstellt am: 06. Jun. 2020 08:31    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Wenn ich anstelle der InletOutlet-Randbedingungen einfache zeroGradient-Randbedingungen wähle, funktioniert die Simulation tadellos. Hat einer von euch eine Idee, woran das liegen könnte? Mit der InletOutlet-Randbedingung simuliert OpenFOAM vielleicht ungewünschte Rückströmungen?

Viele Grüße

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

Shor-ty
Moderator





Sehen Sie sich das Profil von Shor-ty an!   Senden Sie eine Private Message an Shor-ty  Schreiben Sie einen Gästebucheintrag für Shor-ty

Beiträge: 2463
Registriert: 27.08.2010

OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)

erstellt am: 16. Jun. 2020 00:13    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für FeFoe 10 Unities + Antwort hilfreich

Hi, nur kurz als Antwort. inletOutlet ist identisch zu zeroGradient wenn Du negative Flüsse hat, also wenn etwas aus der Domain herauströmt und wechselt zu fixedValue wenn eine Rückströmung aufgrund des Druckprofils zu erwarten ist. Da Du Rückströmungen zulässt (U -> Outlet -> zeroGradient) bekommen dann Deine Felder für k, epsilon die von Dir angegebenen inletValue[i] Werte. Wird wohl der Grund dafür sein. [i]zeroGradient ist ja logisch was hier passiert.


--
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

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

Anzeige.:

Anzeige: (Infos zum Werbeplatz >>)

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen

nächster neuerer Beitrag | nächster älterer Beitrag
Antwort erstellen


Diesen Beitrag mit Lesezeichen versehen ... | Nach anderen Beiträgen suchen | CAD.de-Newsletter

Administrative Optionen: Beitrag schliessen | Archivieren/Bewegen | Beitrag melden!

Fragen und Anregungen: Kritik-Forum | Neues aus der Community: Community-Forum

(c)2023 CAD.de | Impressum | Datenschutz