CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Wall-resolved RANS with interFoam (https://www.cfd-online.com/Forums/openfoam-solving/176381-wall-resolved-rans-interfoam.html)

Artur August 17, 2016 05:17

Wall-resolved RANS with interFoam
 
5 Attachment(s)
Hi All,

TLDR: When I run RANS with interFoam and k-omega SST and a wall-resolved grid I get terrible problems at the free surface which leads to divergence in most cases. How to get past this?

Usually when I run calculations of ship flows I use wall functions due to high Re and never had any issues (well, I had plenty but not like this). Recently I wanted to benchmark my set-up in OpenFOAM 3.0 on a 1 m long Wigley hull and could not justify using a wall function at Re under 1 million. That's when issues started.

I meshed the case both using snappyHexMesh and Pointwise (structured hexahedral) with y+<1 and used standard low-Re BC's (fixedValue nut 0, fixedValue k 0, omegaWallFunction). I have used very similar, wall-resolved grids with interPhaseChangeFoam (as well as simple/piso/pimpleFoam) and never had any issues but for this particular case I get very bad smearing at the interface which leads to non-physical results and most cases diverge.

I ran the snappy case with nutUSpaldingWallFunction as is and re-meshed the Pointwise grid with y+ 50 and switched on the wall function, both worked very well and gave good results. I then tried modifying the low-Re cases by switching on interface compression, adding surface tension and changing BCs to avoid using the variableHeightFlowRate and outletPhaseMeanVelocity outlet BCs but the results stayed the same.

I checked the mesh quality and in both cases it's fine. The allTopology allGeometry option reports some bad quality tet faces and undetermined cells but these are pretty much the same for the grid with wall function so I don't see why they would make the difference.

I've attached the case set-up below and will appreciate any hints.

Cheers,

Artur

Pointwise case with y+<1:
https://www.dropbox.com/s/hsfc6ukvhe...igley.zip?dl=0

Pointwise y+ 1 checkMesh -allTopology -allGeometry:
Code:

Mesh stats
    points:          6747300
    faces:            19985543
    internal faces:  19731301
    cells:            6619474
    faces per cell:  6
    boundary patches: 7
    point zones:      0
    face zones:      0
    cell zones:      0

Overall number of cells of each type:
    hexahedra:    6619474
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:    0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Topological cell zip-up check OK.
    Face-face connectivity OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch              Faces    Points  Surface topology                  Bounding box
    bottom              68242    68850    ok (non-closed singly connected)  (-1 0 -1) (4 1.5 -1)
    hull                23732    24150    ok (non-closed singly connected)  (-1.38778e-19 0 0) (1 0.0500003 0.125)
    inlet              14453    14700    ok (non-closed singly connected)  (-1 0 -1) (-1 1.5 0.125)
    outlet              14453    14700    ok (non-closed singly connected)  (4 0 -1) (4 1.5 0.125)
    sidePort            20694    21318    ok (non-closed singly connected)  (-1 -3.85186e-33 -1) (4 3.60822e-18 0.125)
    sideStbd            44426    44982    ok (non-closed singly connected)  (-1 1.5 -1) (4 1.5 0.125)
    top                68242    68850    ok (non-closed singly connected)  (-1 0 0.125) (4 1.5 0.125)

Checking geometry...
    Overall domain bounding box (-1 -3.85186e-33 -1) (4 1.5 0.125)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-4.6691e-16 -1.4917e-14 3.07075e-14) OK.
    Max cell openness = 2.30493e-14 OK.
    Max aspect ratio = 444.459 OK.
    Minimum face area = 1.37682e-08. Maximum face area = 0.0332558.  Face area magnitudes OK.
    Min volume = 3.99319e-11. Max volume = 0.00399788.  Total volume = 8.43402.  Cell volumes OK.
    Mesh non-orthogonality Max: 57.682 average: 13.3238
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1.76222 OK.
    Coupled point location match (average 0) OK.
 ***Error in face tets: 7904 faces with low quality or negative volume decomposition tets.
  <<Writing 7904 faces with low quality or negative volume decomposition tets to set lowQualityTetFaces
    Min/max edge length = 9.66666e-06 0.224395 OK.
    All angles in faces OK.
    Face flatness (1 = flat, 0 = butterfly) : average = 1  min = 0.9999
    All face flatness OK.
    Cell determinant (wellposedness) : minimum: 7.9799e-08 average: 1.13825
 ***Cells with small determinant (< 0.001) found, number of cells: 935625
  <<Writing 935625 under-determined cells to set underdeterminedCells
    Concave cell check OK.

Failed 2 mesh checks.

fvSolution:
Code:

solvers
{
    "alpha.water.*"
    {
        nAlphaCorr      2;
        nAlphaSubCycles 1;
        cAlpha          1;
        icAlpha        0;

        MULESCorr      yes;
        nLimiterIter    10;
        alphaApplyPrevCorr  yes;

        solver          smoothSolver;
        smoother        DILUGaussSeidel;
        tolerance      1e-8;
        relTol          0;
        minIter        1;
    }

    pcorr
    {
        solver          PCG;

        preconditioner
        {
            preconditioner  GAMG;

            smoother        DICGaussSeidel;
            agglomerator    faceAreaPair;
            mergeLevels    1;
            nCellsInCoarsestLevel 10;
            cacheAgglomeration true;

            tolerance      1e-5;
            relTol          0;
        };

        tolerance      1e-5;
        relTol          0;
    };

    p_rgh
    {
        solver          GAMG;
        smoother        DIC;
        agglomerator    faceAreaPair;
        mergeLevels    1;
        nCellsInCoarsestLevel 10;
        cacheAgglomeration true;

        tolerance      1e-7;
        relTol          1e-2;
    };

    p_rghFinal
    {
        $p_rgh;
        relTol          0;
    }

    "(U|k|omega).*"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;

        nSweeps        1;
        tolerance      1e-7;
        relTol          0.1;
        minIter        1;
    };
}

PIMPLE
{
    momentumPredictor  no;

    nOuterCorrectors    1;
    nCorrectors        2;
    nNonOrthogonalCorrectors 1;

    maxCo 1.0;
    maxAlphaCo 1.0;

    rDeltaTSmoothingCoeff 0.05;
    rDeltaTDampingCoeff 0.5;
    nAlphaSpreadIter    0;
    nAlphaSweepIter    0;
    maxDeltaT          0.5;
}

relaxationFactors
{
    "p_rgh,U,k,omega,alpha.water" 1;
}

cache
{
    grad(U);
}

fvSchemes:
Code:

ddtSchemes
{
    default        localEuler;
}

gradSchemes
{
    default        Gauss linear;
    grad(U) cellMDLimited Gauss linear 1;
}

divSchemes
{
    div(rhoPhi,U)  Gauss linearUpwindV grad(U);
    div(phi,alpha)  Gauss interfaceCompression vanLeer01;
    div(phirb,alpha) Gauss linear;
    div(phi,k)      Gauss upwind;
    div(phi,omega)  Gauss upwind;
    div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default Gauss linear limited corrected 0.33;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        none;
    snGrad(p_rgh)        limited corrected 0.33;
    snGrad(rho)            limited corrected 0.33;
    snGrad(alpha.water)    limited corrected 0.33;
}

wallDist
{
    method meshWave;
}

Attachment 49914

Attachment 49915

Attachment 49916

Attachment 49917

Attachment 49918

SD@TUB November 27, 2016 01:58

Hi Artur, have you made progress on this?
To my knowledge the interface compression scheme should cause trouble when using high aspect ratio cells at the interface. That means increasing the cell number in longitudinal direction may help, if you still need to fully resolve boundary layers.
Anyway, what about the 2 mesh errors that you posted? Are these from the pointwise mesh?
/Stefan

Artur November 28, 2016 05:58

Hi,

Thanks for the reply. I haven't resolved the issue yet because this is a side project and I had to put it on halt for a while due to other commitments.

The mesh errors are from the Pointwise mesh, yes, but they only appear when you use the -allGeometry option. I see them on most of my grids and never had any issues (the low determinant is a different symptom of the high aspect ratio as far as I understand).

I tried increasing the number of cells along the waterline but I'll try to push it a bit more. My thoughts were also that the interface compression scheme would cause issues in this situation hence I ran a few cases without it but it didn't make much of a difference.

If you have any other comments they'll be most welcome :)

All the best

A

Artur January 24, 2017 04:06

Solved
 
2 Attachment(s)
To anyone who's interested, here's the solution:

Following Stefan's suggestion, I switched off the interface compression in fvSolution by setting
Code:

cAlpha          0;
icAlpha        0;

This seems to have done the trick and allowed me to run the wall-resolved mesh without wall functions OK. Obviously, had to then work on figuring out appropriate time steps etc. since the settings which worked fine on the wall-function grid no longer worked. Something I am struggling with right now is jagged interface (see attached pictures) but I'm sure that can be alleviated with a fine grid and better iterative convergence.

Happy foaming

A


All times are GMT -4. The time now is 09:51.