CFD Online Discussion Forums - strange boundary layer with dbnsTurbFoam

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - strange boundary layer with dbnsTurbFoam (https://www.cfd-online.com/Forums/openfoam-solving/146725-strange-boundary-layer-dbnsturbfoam.html)

strange boundary layer with dbnsTurbFoam

Hi foamers,

I wish you a happy new year!

Here is my first problem for 2015 :) :

i created a test case for a channel flow where the upper and lower boundaries are no slip walls, back and front are inlet and outlet and the side patches are symmetry planes. I want to use dbnsTurbFoam (with local time stepping) and RS turbulence modelling with wall functions.
I use first order discretization for turbulence and roe/venkatakrishnan for rho, rhoU and rhoE (second order).
The attached image shows the case with very strange near wall results.

What i tried:

- no turbulence modelling (works fine)
- using k-epsilon model (even worse, see picture)
- first order discretization (no improvement, very strange right?)
- different limiter (no improvement)
- global time stepping (- " -)

In the simulation i'm actually trying to perform the boundary layer is not as bad as in the test case. But still oscillations in wall normal directions. I think this is due to the fact that the walls end in the domain and not at the outlet (worst results in test case).

I would really appreciate your advises.

Jens

When I use a cellMDLimited gradient scheme there are no unphysical maxima anymore but the boundary layer still seems to be too thick.

Has anybody an idea?
Thank you,
Jens

Hello,

the problem was that I just copied the thermophysicalProperties from somewhere without checking it. The Southerland constants where wrong...

But i am still struggling with the wall functions for dbnsTurbFoam with RSTM turbulence. The turbulent quanteties at the wall are about 50% lower than those i calculated with kEpsilon model (and both kEpsilon and RSTM in Fluent). This leads to very different wall shear stresses.
Has anybody experiences with compressible wall functions for RSTM modelling? For the incompressible case there is an anisotropic wall function for R.

Thanks for your hints

Okay this is really strange,

i allways had the feeling, that the wall functions don't work properly so I added some lines like

"Info<< "\n P = " << P[202] << endl;"

to check the terms in the transport equations at a wall point below

epsilon_.boundaryField().updateCoeffs();

in LaunderGibsonRSTM.C. After recompiling the turbulence models my problem was solved. Obviously the updateCoeffs() function didn't do anything.
But why???

I don't know if someone's reading this, but I keep on writing :).

When I shift to a more complex case (with some bad cells) the results are still not satisfying.

The first picture shows the R values on the wall calculated by fluent (formula 4–216 on http://www.arc.vt.edu/ansys_help/flu...c_rsm_bcs.html).

The second one is a foam result where R is calculated according to LaunderGibsonRSTM.C (by mut and the velocity gradients). The values are about 50% lower (different scale) and the distribution seems to be non-physical in some regions.

For the third case I implemented the fluent formulation in OF. The magnitudes of R are now similar to the ones calculated by fluent, but the field is not smooth.

The mesh influence is visible in both foam cases.
Does anybody know how to get smoother results in openFoam? My current fvSchemes is:

Code:

ddtSchemes

{

   default        EulerLocal physDeltaT CoDeltaT;

}



gradSchemes

{

    default           cellMDLimited leastSquares 1;

}



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,h)               Gauss linear corrected;

    laplacian(DREff,R)                Gauss upwind phi corrected;

}



interpolationSchemes

{

   default         linear;

}



snGradSchemes

{

    default         corrected;

}

Thanks for your help.

Hi Jens,

Quote:

Originally Posted by jensi_t (Post 534189)

Without more details, my guess is that your build of foam-extend 3.1 was not done with complete success when you installed it. To double check if everything is properly built, run:

Code:

foam

./Allwmake > log.make 2>&1

Then check if in the file "log.make", all libraries and applications are built and only give the message that they are already "up-to-date".

Quote:

Originally Posted by jensi_t (Post 537825)

I don't know if someone's reading this, but I keep on writing :).

I'm glad you did, otherwise there wouldn't be a record of this.

Quote:

Originally Posted by jensi_t (Post 537825)

The second one is a foam result where R is calculated according to LaunderGibsonRSTM.C (by mut and the velocity gradients). The values are about 50% lower (different scale) and the distribution seems to be non-physical in some regions.

It's common for turbulence-related fields to give different scales of values between each implementation (e.g. Fluent vs OpenFOAM), due to how the models are implemented.

Quote:

Originally Posted by jensi_t (Post 537825)

For the third case I implemented the fluent formulation in OF. The magnitudes of R are now similar to the ones calculated by fluent, but the field is not smooth.

OK, I believe this is because you've been always using "upwind" for the turbulence equation terms in "fvSchemes".

Quote:

Originally Posted by jensi_t (Post 537825)

The mesh influence is visible in both foam cases.
Does anybody know how to get smoother results in openFoam? My current fvSchemes is:

Try this:

Code:

ddtSchemes

{

   default        EulerLocal physDeltaT CoDeltaT;

}



gradSchemes

{

    default           Gauss linear;

}



divSchemes

{

    default                             none;

    div(phi,k)                          Gauss linear;

    div(phi,epsilon)                    Gauss linear;

    div(devRhoReff)                     Gauss linear;

    div((devRhoReff&U))                 Gauss linear;

    div(phi,R)                          Gauss linear;

    //div(R)                              Gauss linear;

}



laplacianSchemes

{

     default                           none;

    laplacian(DkEff,k)                  Gauss linear corrected;

    laplacian(DepsilonEff,epsilon)      Gauss linear corrected;

    laplacian(alphaEff,h)               Gauss linear corrected;

    laplacian(DREff,R)                Gauss linear corrected;

}



interpolationSchemes

{

   default         linear;

}



snGradSchemes

{

    default         corrected;

}

This way everything should be in second-order.

In addition, if you could share a simple test case, it would make it easier for me/others to try things out as well ;)

Best regards,
Bruno

Hi Bruno,

I'm glad to hear that I'm on your to-do-list :) and thanks for your help. I will try second order for turbulence but I think last time I did that I've run into stability problems.
Unfortunately I can't share the case from the last post where the problem occurs, but I will upload the one from the first post if s.o. wants to test some settings.

Regards,
Jens

Hi,

I have a question about post #17 on this topic:

http://www.cfd-online.com/Forums/ope...mentation.html

Roman says:

"I am not completely sure, but I think the zeroBoundary condition is evaluated while solving kEqn in

Code:
kEqn().relax(); solve(kEqn); bound(k_, kMin_); "

If this is right the R equation is solved with zeroGradient boco for every single reynolds stress component when I use kqRWallFunction. Which makes physically no sense in my opinion. The loop in the end, respectivly in the RWallFunction, only changes shear components so it doesn't affect k and thus y*, G, epsilon and mut are evaluated based on wrong TKE.

I changed the R boco to fixedValue and use the fluent implementation to calculate R (where the stresses are calculated in a local coordinate system). First simulations seem to be promising.

What do you think?

Best regards,
Jens

Hi Jens,

Quote:

Originally Posted by jensi_t (Post 544295)

If this is right the R equation is solved with zeroGradient boco for every single reynolds stress component when I use kqRWallFunction. Which makes physically no sense in my opinion. The loop in the end, respectivly in the RWallFunction, only changes shear components so it doesn't affect k and thus y*, G, epsilon and mut are evaluated based on wrong TKE.

I'm confused with the acronyms :(
I can figure out what you mean by "boco", which is probably "boundary condition". But the "R equation" I can't figure out for certain. Sorry, but this isn't my area of expertise, hence not being fully familiar with the terminology for the turbulence models.

I guess you're referring to how the equations for "k" and "epsilon" are being solved? If this is the case, then here's what I know:

The wall functions for k-epsilon are usually of type "zeroGradient", because it's the values at the centre of the cells that matter most, while the values at the faces don't matter as much. Therefore, it might as well be the same value on the wall as in the centre of the cell, since this way it can speed up a bit the solving process.
Keep in mind that since wall functions emulate of effect of how the flow behaves near the wall (logarithmic profile and so on), these wall functions sometimes don't give values that mean much on the wall... since in theory, the wall is non-slip, which means that no actual flow exists and therefore no turbulence should exist either.
On the other hand, if you look at the "low Reynolds" implementations of k-epsilon, you'll see some tutorials that will show that the wall functions use a fixed value on the wall, usually a very small value. This is because of how the mathematics work on these "low Reynolds" turbulence models, which cannot be used with "zeroGradient".

Therefore, the big question is this: does your simulation test cases have low or high Reynolds numbers?

In addition, this reminds me of a recent thread: http://www.cfd-online.com/Forums/ope...-resource.html - although the document mentioned there relates mostly to the k-omega and Spalart-Allmaras implementations.

Best regards,
Bruno

Hi Bruno,

thanks for your reply and sorry for the acronyms. By boco I mean boundary condition. By R equation I mean the transport equation for the reynolds stresses.
I have high reynolds numbers.

I just wonder if the boundary conditions are automatically updated when the solve() function is called, because for epsilon there is a line
epsilon_.boundaryField().updateCoeffs();
but for k in k-epsilon and R in LaunderGibsonRSTM there nothing accordingly.

Regards,
Jens

Quote:

Originally Posted by jensi_t (Post 544893)

I just wonder if the boundary conditions are automatically updated when the solve() function is called,

Quick answer: When solve is doing its work, it should call evaluate on all fields that are included in the equation.
The need for calling the one for epsilon earlier is... I gotta look into the source code... wait, I wrote about this a few days ago... see post #5 on this thread: http://www.cfd-online.com/Forums/ope...tml#post544806