[saeed jamshidi]

Hello,

I have simulated flow around a cylinder in turbulent flow (Re=2*10^5) with the K- omega SST in 3D.
However, I have a question about the vorticity field that I have attached. Why there is such let's say noise in the area where I have shown by arrow?!!

I am going to share my fvsolution and fvscheme to have a better discusion.
Could you give me general advice on this matter?

Thank you.

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v2106                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver          GAMG;
        smoother        DICGaussSeidel;
        tolerance       1e-06;
        relTol          0.05;
    }

    pFinal
    {
        $p;
        relTol          0;
    }

    "(U|k|omega|s)"
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-6;
        relTol          0.1;
    }

    "(U|k|omega|s)Final"
    {
        $U;
        relTol          0;
    }
}


SIMPLE
{
    nNonOrthogonalCorrectors 0;
    pRefCell        0;
    pRefValue       0;
}

PIMPLE
{
    nOuterCorrectors 1;
    nCorrectors      3;
    nNonOrthogonalCorrectors 1;
    pRefCell        0;
    pRefValue       0;
	momentumPredictor yes;
	correctPhi no;
}

relaxationFactors
{
    fields
    {
    }
    equations
    {
        ".*"        1;
    }
}


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

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v2112                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         backward;
}

gradSchemes
{
    default         Gauss linear;
    grad(p)         Gauss linear;
}

divSchemes
{
    default         none;

    div(phi,U)      Gauss linear;

    div(phi,k)      Gauss limitedLinear 1;

    div(phi,omega) Gauss limitedLinear 1;
	
	div(phi,s) Gauss limitedLinear 1;

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

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

wallDist
{
    method          meshWave;
    nRequired       yes;
}


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

[saeed jamshidi]

I'm still looking for your contribution.

[saeed jamshidi]

Any idea 💡??

[dlahaye]

Is the issue that you raise a mesh sensitive issue? Do artifacts disappear when you make the mesh finer?

[saeed jamshidi]

Thank you dlahaye for the reply,

No it is not the issue of mesh refinement to some what.

Actually, couple of hours ago I found that the problem is very sensitive with div(phi, U) scheme.
What I found is that

div(phi,U)      Gauss LUST grad(U);

has better performance than

div(phi,U)      Gauss linear;

[dlahaye]

I suspect the sensitivity to the discretization scheme to disappear on finer meshes.

[saeed jamshidi]

I will share my results with different div. Schemes.
Thanks.

[dlahaye]

Results using various div schemes are hard to make sense of in the absence of a analytical reference solution.

My suggestion again is to try various mesh sizes. I do realize this is a nuisance as

1/ you will need to create various meshes;
2/ you will need to run on various meshes.

[saeed jamshidi]

I'll try it.
Thank you again dlahaye.

[dlahaye]

Cool! Please post your results here for us to have a look at.

[saeed jamshidi]

Hello everyone,
I hope you have nice days.

I came back after few days in response to previous posts.

As you saw I came across smearing gradients for flow around a cylinder at Re=200000 with the following mesh and discretization scheme:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v2112                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         backward;
}

gradSchemes
{
    default         Gauss linear;
    grad(p)         Gauss linear;
}

divSchemes
{
    default         none;

    div(phi,U)      Gauss linear;

    div(phi,k)      Gauss limitedLinear 1;

    div(phi,omega) Gauss limitedLinear 1;
	
	div(phi,s) Gauss limitedLinear 1;

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

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

wallDist
{
    method          meshWave;
    nRequired       yes;
}


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

Screenshot (210).jpg

However, in order to get rid of this issue I employed various methods in openfoam.

The procedures are as below:

1) Studing the effects of the mesh refinement and transition between cells (Number of cells between layers):

I adopted the same numerical scheme and used refinement level of (6,6) instead of level of (5,5) for cylinder, Nevertheless, there was not significant changes!
Of course mesh refinement plays an important role in CFD, but it was not the issue at least in this case.
Results: Screenshot (218).jpg and Screenshot (223).jpg

2) Studing the effects of different numerical schemes on the same mesh:

In this state, I consider previuos mesh with refinement level of (5,5) and utilized different discretization scheme whether spatial or temporal. I tested various methods for ddtSchemes (Time) , gradSchemes (Gradient) and divSchemes (Divergence) ; what I found is that just applying different methods for divergence of velocity (U) considerably affects the solution of our problem.
I used Gauss linear for divergence of U and employed leastSquares and cellMDLimmited Gauss linear 1 as a gradient schhemes; as you can see there isn't noticeably progress:
Results: Screenshot_(209).jpg and Screenshot_(213).jpg
...

[saeed jamshidi]

Due to attachment restrictions, I have to make multiple posts, So I apologise for that.

…2)

Besides, once again on the previous mesh with a refinement level of (5,5); the Gauss linear method was kept constant as a gradient Scheme and different divergence schemes were utilized:
Results: Screenshot (203).jpg, Screenshot (204).jpg, Screenshot (205).jpg, Screenshot (206).jpg & Screenshot (207).jpg

[saeed jamshidi]

...2)

Results indicate that Gauss linearUpwind grad(U) scheme has the best performance among all utilized schemes. Also, this (second-order upwind) is the most common scheme which is used in Ansis Fluent as a second-order scheme for spatial discretisation.
Rest of the Results: Screenshot (208).jpg & Screenshot (236).jpg

[saeed jamshidi]

3) Studing the effects mesh topology:

All of the previous results were taken on the mesh which was generated with the snappyHexMesh utility:
Screenshot (225).jpg
Now, we are going to observe the results of O-Grid type which is created by just blockMesh in openfoam. Here is the topology of the mesh:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2112                                  |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : _6e1fca0e-20220610 OPENFOAM=2112 patch=220610 version=2112
Arch   : "LSB;label=32;scalar=64"
Exec   : checkMesh
Date   : Jan 03 2024
Time   : 09:15:08
Host   : DESKTOP-TK3D7CI
PID    : 567
I/O    : uncollated
Case   : /mnt/e/OpenFoam/Run/cylinder3D1
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Time = 0

Mesh stats
    points:           740740
    faces:            2076200
    internal faces:   1931800
    cells:            668000
    faces per cell:   6
    boundary patches: 7
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     668000
    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.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology
    inlet               1600     1771     ok (non-closed singly connected)
    outlet              1600     1771     ok (non-closed singly connected)
    cylinder            2400     2640     ok (non-closed singly connected)
    top                 2600     2871     ok (non-closed singly connected)
    bottom              2600     2871     ok (non-closed singly connected)
    back                66800    67340    ok (non-closed singly connected)
    front               66800    67340    ok (non-closed singly connected)

Checking faceZone topology for multiply connected surfaces...
    No faceZones found.

Checking basic cellZone addressing...
    No cellZones found.

Checking geometry...
    Overall domain bounding box (-0.4 -0.4 -0.01) (1 0.4 0.01)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-4.41575e-18 -7.09869e-18 1.66212e-14) OK.
    Max cell openness = 9.0192e-16 OK.
    Max aspect ratio = 65.3413 OK.
    Minimum face area = 1.5997e-08. Maximum face area = 0.000174079.  Face area magnitudes OK.
    Min volume = 3.20006e-11. Max volume = 3.48158e-07.  Total volume = 0.0223749.  Cell volumes OK.
    Mesh non-orthogonality Max: 44.1889 average: 7.86983
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.434082 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

saeedfoam@DESKTOP-TK3D7CI:/mnt/e/OpenFoam/Run/cylinder3D1$

Screenshot (229).jpg & Screenshot (230).jpg

Again I used Gauss linear and linearUpwind grad(U) schemes, as you can see linearUpwind grad(U) showed its superiority than Gauss linear. Furthermore, when we use this mesh all of the smearing gradients disappear!
Results: Screenshot (232).jpg & Screenshot (234).jpg

In conclusion, linearUpwind grad(U) scheme along with the O-Grig type was the best choice.
If you have any complementary opinions and ideas it would be really welcome.
Best Regards,
Saeed Jamshidi

[dlahaye]

Congrats for your results.

Well done!

[NotOverUnderated]

linear scheme is second-order unbounded. That's why you are getting those oscillations. You should never use linear scheme for divergence terms under any circumstances for RANS simulations.

Regards

Update: Specified that linear scheme is not suitable for RANS simulations.

[Tobermory]

Nice thread, but let me just address the following:

Originally Posted by NotOverUnderated

[You should never use linear scheme for divergence terms under any circumstances.

this is too sweeping. There are plenty of situations where it is acceptable, or even necessary to apply linear for divergence terms, since it provides a cleaner discretisation than linearUpwind (linearUpwind is more diffusive or dispersive than central differencing ... I forget which) - LES or DNS simulations are an example. You're right, though, that for the majority of RANS simulations, linearUpwind can be a more stable scheme, but this comes at a slight accuracy cost (you don't get anything for free in this life!) so pick what works best for you and be careful with the linearUpwind gradient limiter ... which will also lower the accuracy of the scheme.

[saeed jamshidi]

Thank all of you for the opinions.

I want to add another type of divergence scheme which is frequently used in openfoam tutorials for the Detached Eddy Simulation, like

surfaceMountedCube

.

Example of the DEShybrid scheme specification using linear within the LES region and linearUpwind within the RAS region:

    divSchemes
    {
        .
        .
        div(phi,U)      Gauss DEShybrid
            linear                    // scheme 1
            linearUpwind grad(U)      // scheme 2
            hmax                      // LES delta name, e.g. 'delta', 'hmax'
            0.65                      // DES coefficient, typically = 0.65
            30                        // Reference velocity scale
            2                         // Reference length scale
            0                         // Minimum sigma limit (0-1)
            1                         // Maximum sigma limit (0-1)
            1.0e-03;                  // Limiter of B function, typically 1e-03
        .
        .
    }

Notes:

Scheme 1 should be linear (or other low-dissipative schemes) which will be used in the detached/vortex shedding regions.

Scheme 2 should be an upwind/deferred correction/TVD scheme which will be used in the free-stream/Euler/boundary layer regions.

According to the above scheme, it seems that linearUpwind is a good choice for the RAS regions.

Also, I employed this scheme and it gave me satisfactory result for the IDDES method:
Screenshot (237).jpg

[NotOverUnderated]

Originally Posted by Tobermory

Nice thread, but let me just address the following:



this is too sweeping. There are plenty of situations where it is acceptable, or even necessary to apply linear for divergence terms, since it provides a cleaner discretisation than linearUpwind (linearUpwind is more diffusive or dispersive than central differencing ... I forget which) - LES or DNS simulations are an example. You're right, though, that for the majority of RANS simulations, linearUpwind can be a more stable scheme, but this comes at a slight accuracy cost (you don't get anything for free in this life!) so pick what works best for you and be careful with the linearUpwind gradient limiter ... which will also lower the accuracy of the scheme.

Thank you for your input. I have updated the my post above to specify the RANS context.

[Tobermory]

Yep - that makes sense Saeed: linear in the LES regions and linearUpwind in the RANS regions.