CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Wall-resolved RANS with interFoam

Register Blogs Community New Posts Updated Threads Search

Like Tree1Likes
  • 1 Post By Artur

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   August 17, 2016, 06:17
Default Wall-resolved RANS with interFoam
  #1
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 20
Artur will become famous soon enough
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;
}
alpha_pointwise_y+1.jpg

alpha_pointwise_y+50.jpg

alpha_snappy_y+1.jpg

lowQualityTetFaces.jpg

undeterminedCells.jpg
lourencosm likes this.
Artur is offline   Reply With Quote

Old   November 27, 2016, 02:58
Default
  #2
Member
 
Stefan
Join Date: Jan 2010
Location: Kiel, Germany
Posts: 81
Rep Power: 16
SD@TUB is on a distinguished road
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
SD@TUB is offline   Reply With Quote

Old   November 28, 2016, 06:58
Default
  #3
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 20
Artur will become famous soon enough
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 is offline   Reply With Quote

Old   January 24, 2017, 05:06
Default Solved
  #4
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 20
Artur will become famous soon enough
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
Attached Images
File Type: png waveCuts.png (85.4 KB, 79 views)
File Type: jpg bowWave.jpg (194.9 KB, 89 views)
Artur is offline   Reply With Quote

Reply

Tags
interfoam diverging, interfoam hull, low-re rans, structured hex mesh


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Divergence in AMG solver! marina FLUENT 20 August 1, 2020 12:30
Natural convection in a closed domain STILL NEEDING help! Yr0gErG FLUENT 4 December 2, 2019 01:04
Wall forces in interFoam Terp OpenFOAM Running, Solving & CFD 14 April 11, 2017 11:11
Very technical question about solving wall boundary layer ... jlb001 FLUENT 6 December 27, 2014 06:56
Wall functions Abhijit Tilak Main CFD Forum 6 February 5, 1999 02:16


All times are GMT -4. The time now is 15:54.