[jensi_t]

Hello,

i'm using dbnsTurbFoam with LRR turbulence modeling to simulate the mixing process of core- and bypass stream in a jet engine.
I created a structured mesh for a slice of the geometry and applied cyclic boundaries.
Due to the complex geometry of the forced mixer between core and bypass, the mesh contains a V-shaped Structure.
My foam solutions are obviously effected by this structure whereas a fluent calculation on the same mesh shows smooth vortexes (see pictures).
I had a similar problem with rhoCentralFoam.

I use the following schemes:

ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default         none;
    div(phi,k)      Gauss upwind;
    div(phi,epsilon) Gauss upwind;
    div(devRhoReff) Gauss linear;
    div((devRhoReff&U)) Gauss linear;
    div(phi,R) Gauss limitedLinear 1;
    div(R) Gauss linear;
}

laplacianSchemes
{
    default         none;
    laplacian(DkEff,k) Gauss linear limited 0.5;
    laplacian(DepsilonEff,epsilon) Gauss linear limited 0.5;
    laplacian(alphaEff,e) Gauss linear limited 0.5;
    laplacian(alphaEff,h) Gauss linear limited 0.5;
    laplacian(DREff,R) Gauss linear limited 0.5;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
}

Has anybody an idea how to solve this problem? Is there something like a correction for non-orthogonal meshes in dbns?

Thanks for your help.

Jens

[jensi_t]

No suggestions?
I mean I can change the mesh, but i wonder why it works with fluent. And even a mesh without the V-shape wouldn't be orthogonal so it would still influence the flowfield.

Thanks for your help!

[wyldckat]

Greetings Jens,

OpenFOAM can be pretty picky about meshes. I've seen some interesting situations and documented them here: OpenFOAM: Interesting cases of bad meshes and bad initial conditions
Furthermore the presentation "OFW09.0005 How grid quality affects solution accuracy" available at http://openfoam-extend.sourceforge.n.../download.html gives a pretty good description/analysis on this topic!

Beyond this, from the images, I can state two tips right off the bat:

1. Refinement transitions in the wrong place can be fatal. Have a look at "Case two" from the first link.
2. http://openfoamwiki.net/index.php/FA...is_in_ParaView

Beyond this, a few of questions:

1. How is your "fvSolution" configured?
2. Is your mesh composed mainly of tetrahedral cells?
3. What does checkMesh say about your mesh?

Best regards,
Bruno

[jensi_t]

Hi Bruno,

thanks for the links. I already knew the OFW09.0005 presentation and found it very interesting. It gives a good explanation why my mesh is not so good .
BUT fluent seems not to care about it and the riemann-solver of Oliver Borm neither.
I try to figure out what makes the difference.

To answer your questions:

1.

solvers
{
    rho
    {}

    rhoU
    {}

    rhoE
    {}

    k
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-08;
        relTol          0.01;
    }
    epsilon
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-08;
        relTol          0.01;
    }
    R
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-10;
        relTol          0.01;
    }

}

2. The mesh is only composed of hexaedral cells

3.

Initializing the GGI interpolator between master/shadow patches: pr1/FaceGroup46
Time = 0.00633488

Mesh stats
    all points:           1218912
    live points:          1218912
    all faces:            3559903
    live faces:           3559903
    internal faces:       3463877
    cells:                1170630
    boundary patches:     14
    point zones:          0
    face zones:           13
    cell zones:           1

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

Checking topology...
    Boundary definition 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   Area [m^2]  Surface topology                  
    nacelle             6732     6956     0.961432    ok (non-closed singly connected)  
    mixer               2536     2715     0.0657216   ok (non-closed singly connected)  
    lower_bypass_duct   4500     4641     0.184251    ok (non-closed singly connected)  
    upper_core_duct     4410     4575     0.0317756   ok (non-closed singly connected)  
    lower_core_duct     4356     4530     0.0442502   ok (non-closed singly connected)  
    guide_vane          2132     2184     0.0323396   ok (non-closed singly connected)  
    mixer-shadow        2536     2715     0.0657216   ok (non-closed singly connected)  
    farfield_outlet     6624     6803     1.04829     ok (non-closed singly connected)  
    farfield            2880     2997     3.07944     ok (non-closed singly connected)  
    farfield_inlet      1008     1073     0.966654    ok (non-closed singly connected)  
    pr1                 26582    27026    6.42692     ok (non-closed singly connected)  
    bypass_inlet        2646     2752     0.0447299   ok (non-closed singly connected)  
    core_inlet          2502     2634     0.0187553   ok (non-closed singly connected)  
    FaceGroup46         26582    27026    6.42692     ok (non-closed singly connected)  

Checking geometry...
    This is a 3-D mesh
    Overall domain bounding box (-1.87781 -0.480979 -4.75413e-09) (1.29674 0.480979 2.1615)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Mesh (non-empty, non-wedge) dimensions 3
    Boundary openness (-2.24215e-17 -1.00571e-15 -1.06939e-15) Threshold = 1e-06 OK.
    Max cell openness = 3.26762e-15 OK.
    Max aspect ratio = 392.632 OK.
    Minumum face area = 6.2554e-09. Maximum face area = 0.010648.  Face area magnitudes OK.
    Min volume = 1.67449e-12. Max volume = 0.00029025.  Total volume = 3.29267.  Cell volumes OK.
    Mesh non-orthogonality Max: 80.2948 average: 18.1626 Threshold = 70
   *Number of severely non-orthogonal faces: 3085.
    Non-orthogonality check OK.
  Writing 3085 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.63031 OK.

Mesh OK.

Fluent automatically corrects the schemes for "Meshes of poor Quality". I didn't find something similar in Mr Borm's solver but I think that this is the point.

Thanks again for your help. I'm really stuck at the moment so I appreciate every suggestion.

Jens

[jensi_t]

Moinmoin,

I could improve my results by changing the approximate Riemann-solver from Rusanov to Roe method. I also changed the Limiter to Venkatakrishnan.
Honestly I don't understand why this makes things better. I thought it should be some non-orthogonal or skew correction in the fvSchemes (where is div(dbnsFlux.rhoFlux) defined? i couldn't find it).
To achieve better stability I used the following fvSchemes:

gradSchemes
{
    default         Gauss linear corrected;

}

divSchemes
{
    default                             none; 
    div(phi,k)                          Gauss upwind cellLimited Gauss linear 1;
    div(phi,epsilon)                    Gauss upwind cellLimited Gauss linear 1;
    div(devRhoReff)                     Gauss linear;
    div((devRhoReff&U))                 Gauss linear;
    div(phi,R)                          Gauss upwind cellLimited Gauss linear 1;
    div(R)                              Gauss upwind cellLimited Gauss linear 1;//Gauss linear;
}

laplacianSchemes
{   
    default                             none;
    laplacian(DkEff,k)                  Gauss upwind phi corrected;
    laplacian(DepsilonEff,epsilon)      Gauss upwind phi corrected;
    laplacian(alphaEff,e)               Gauss linear corrected;
    laplacian(alphaEff,h)               Gauss linear corrected;
    laplacian(DREff,R)                  Gauss upwind phi corrected;
}   

interpolationSchemes
{
    default         linear;

}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
}

I'm still very thankful for explanations.
Thanks,

Jens


P.S.: My calculation are still very time-consuming due to the fact that I have to use cyclicGgi as globalFaceZones instead of cyclics to get my rsm model run. (http://www.cfd-online.com/Forums/ope...onditions.html)

[wyldckat]

Hi Jens,

I've had this on my to-do list and it took me a long time to get back to you on this. Fortunately I know some more details today than I knew a few months ago.

Regarding the latest post, there are a few entries that you have that won't do anything at all, due to how each scheme is designed to work... although I'm assuming this is the same for both foam-extend 3.1 and OpenFOAM 2.x (I'm more familiar with OpenFOAM). The following is what the solver is probably using:

gradSchemes
{
    default         Gauss linear;

}

divSchemes
{
    default                             none; 
    div(phi,k)                          Gauss upwind;
    div(phi,epsilon)                    Gauss upwind;
    div(devRhoReff)                     Gauss linear;
    div((devRhoReff&U))                 Gauss linear;
    div(phi,R)                          Gauss upwind;
    div(R)                              Gauss upwind;
}

laplacianSchemes
{   
    default                             none;
    laplacian(DkEff,k)                  Gauss upwind phi corrected;
    laplacian(DepsilonEff,epsilon)      Gauss upwind phi corrected;
    laplacian(alphaEff,e)               Gauss linear corrected;
    laplacian(alphaEff,h)               Gauss linear corrected;
    laplacian(DREff,R)                  Gauss upwind phi corrected;
}   

interpolationSchemes
{
    default         linear;

}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
}

I still have to take a better look into how dbnsTurbFoam works and I see you've continued this topic in the following threads:

• http://www.cfd-online.com/Forums/ope...-dbnsfoam.html
• http://www.cfd-online.com/Forums/ope...sturbfoam.html

I'll take a look into it now and answer on those threads.

Best regards,
Bruno