Questions to utility yPlusLES

aylalisa · March 13, 2014, 13:20

Dear Foamers!

I'd like to use yPlusLES (./applications/utilities/postProcessing/wall/yPlusLES/yPlusLES.C).

code snippet:

Code:

volScalarField::GeometricBoundaryField d = nearWallDist(mesh).y();
        volScalarField nuEff(sgsModel->nuEff());

        const fvPatchList& patches = mesh.boundary();

        const volScalarField nuLam(sgsModel->nu());

        forAll(patches, patchi)
        {
            const fvPatch& currPatch = patches[patchi];

            if (isA<wallFvPatch>(currPatch))
            {
                yPlus.boundaryField()[patchi] =
                    d[patchi]
                   *sqrt
                    (
                        nuEff.boundaryField()[patchi]
                       *mag(U.boundaryField()[patchi].snGrad())
                    )
                   /nuLam.boundaryField()[patchi];
                const scalarField& Yp = yPlus.boundaryField()[patchi];

                Info<< "Patch " << patchi
                    << " named " << currPatch.name()
                    << " y+ : min: " << gMin(Yp) << " max: " << gMax(Yp)
                    << " average: " << gAverage(Yp) << nl << endl;
            }
        }

According to the computation of

for using Reynolds-averaged Navier-Stokes Equations we have these formulas: $y^+ = \frac{y*u_\tau}{\nu}$ , $u_\tau= \sqrt{\frac{\tau_W}{\rho}}$ and $\tau_W = \mu\frac{\delta \overline{u}}{\delta y}$

1)
Computation of yPlusLES according to the code snippet above:
Calculation of $\tau_W$ uses nuEff, instead of nu.
Whereas nu in the denominator is nuLam (nu).

Does this proceeding have a physical or mathematical background?
(nuEff could become zero, which is not allowed to happen in the denominator?)

2)

Code:

 *mag(U.boundaryField()[patchi].snGrad())

.

Is there a case where you have to replace U by a time averaged field U (UMean?)
according to the formula for

(RANS)?
a)
RANS with turbulence model (wall region not resolved)
Usage of time averaged U field maybe yes, but since a wall function is used,

must anyway be computed differently with regard to the wall function's results???
b)
RANS with low Reynolds turbulence model (wall region resolved)
Case b) seems to be the only case where it is necessary to use a time averaged field for U. Is this assumption right?
c)
LES (wall region resolved)
Which velocity vector field U has to be used to compute $\tau_W$ to catch the real physical situation very close to the wall in a LES computation? Is it assumed that we have a laminar flow very close to the wall and therefore no statistical fluctuations in the viscous sublayer? Therefore use mag(U) as the code shows?

3)
In case I want to compute

not only close to the wall but for the complete flow domain, how do I have to compute $\tau$ ?
something like --> mag(U.snGrad())???

Thanks to everyone who answers!

Aylalisa

wyldckat · March 16, 2014, 07:41

Greetings Aylalisa,

Quote:

Originally Posted by aylalisa

1)
Computation of yPlusLES according to the code snippet above:
Calculation of $\tau_W$ uses nuEff, instead of nu.
Whereas nu in the denominator is nuLam (nu).

Does this proceeding have a physical or mathematical background?
(nuEff could become zero, which is not allowed to happen in the denominator?)

Some time ago I had to extend the y+ equation (i.e. merge all parts into a single equation), which is available here: http://www.cfd-online.com/Forums/ope...tml#post471818 post #27 - which is as follows: $y^+ \equiv y \, \frac{\sqrt{\frac{\mu \left(\frac{\partial u}{\partial y} \right)_{y=0}}{\rho}}}{\frac{\mu}{\rho}}$
The details (i.e. background) for y+ can be found here:

"nuEff" is essentially the turbulent kinematic viscosity, i.e. which already takes into account the equivalent viscosity of the fluid when subjected to the turbulent flow.

In general, the viscosity should never be zero.

Quote:

Originally Posted by aylalisa

2)

Code:

 *mag(U.boundaryField()[patchi].snGrad())

.

Is there a case where you have to replace U by a time averaged field U (UMean?)
according to the formula for

(RANS)?
a)
RANS with turbulence model (wall region not resolved)
Usage of time averaged U field maybe yes, but since a wall function is used,

must anyway be computed differently with regard to the wall function's results???
b)
RANS with low Reynolds turbulence model (wall region resolved)
Case b) seems to be the only case where it is necessary to use a time averaged field for U. Is this assumption right?
c)
LES (wall region resolved)
Which velocity vector field U has to be used to compute $\tau_W$ to catch the real physical situation very close to the wall in a LES computation? Is it assumed that we have a laminar flow very close to the wall and therefore no statistical fluctuations in the viscous sublayer? Therefore use mag(U) as the code shows?

I'm not able to answer to these questions, as I know very little on this topic. The best that I can do is suggest that you look at OpenFOAM's source code. For example, you can begin by studying the code in this folder: "src/turbulenceModels/incompressible/RAS/RNGkEpsilon" - and then proceed to examine the neighbouring folders.

Quote:

Originally Posted by aylalisa

3)
In case I want to compute

not only close to the wall but for the complete flow domain, how do I have to compute $\tau$ ?
something like --> mag(U.snGrad())???

I'm not sure if it makes much sense calculating y+ for the whole domain, but technically it's just a matter of extending the calculation to the whole domain.
Problem is that "nearWallDist" was designed to provide only the "y" values only near the patches/walls, therefore it's not just a matter of changing the calculation around "U".

Best regards,
Bruno

cosimobianchini · March 17, 2014, 12:43

1) agree with Bruno
2) y+ should not be calculated with mean velocity. However for RANS UMean = U (wether you resolve or resolve the viscous sublayer is not important: this is handled by different values of nut at the wall). For LES you could, if respecting the instantaneous velocity constraint is a too tight requirement, time-average yPlus directly instead of using time averaged velocity.
3) As far as I remember, the right class to export wall data in the internal field is the wallDistData class (have a look at vanDriestDelta for usage). In that case you could use the tau_wall of the closest wall distance to define internal field y+. Anyhow I agree with Bruno, I don't see the point in doing that.

Hope this help,
Cosimo

aylalisa · March 20, 2014, 08:10

Dear Bruno, Dear Cosimo,

I would like to calculate

für a channel flow (LES).
So far I can follow Bruno's extension of

equation:

(1),

(2) ,

(3) , $\nu =\frac{ \mu} {\rho}$ (4)
end up with

(5),
(3) in (2), (2)in (1) --> (5) (according to the links).

To 1)
In formula (5) $\nu$ shows up twice (nominator and denominator).
In Bruno's code the used $\nu$ in the nominator is "nuEff", $\nu$ in the denominator whereas is "nuLam".

Is the definition of "nuEff" $\nu_{eff} = \nu + \nu_t$ ?

Why did you use different values for $\nu$ in the formula for computation of

?
Probably stupid question but why didn't you use "nuEff" in denominator as well?

From a physical point of view $\nu$ can never be zero, but from a mathematical point of view, it could. Is that the reason for using "nuEff" in the nominator?
Does it mean that "nuLam" can't get zero but "nuEff" can?

To 2)

Quote:

For LES you could, if respecting the instantaneous velocity constraint is a too tight requirement, time-average yPlus directly instead of using time averaged velocity.

I don't get that point.

I thought in LES I have to use UMean instead of mag(U)?
In the official file "yPlusLES.C" mag(U) is used. Does this mean that you have to time-average

?

In which flow situation is it possible that the instantaneous velocity constraint is a too tight requirement as you said?

To 3)
Case: the duct flow (LES) is wall bounded according to bottom and top (z direction), cyclic according to left wall and right wall (y direction). The wall regions (bottom/top) are resolved, no wall function is used.

I would like to compare the logarithmic law of the wall with the dimensionless wall units, computed from the results of an LES.
Is the plot

(y-axis)

(x-axis) from y = 0 to y = channel half height the correct way to do that?

florian_krause started a discussion and published his code for such a plot.

I've seen that distance to the wall y can be computed with wallDist y(mesh, true).
Did florian_krause implement what Cosimo described in answer 3)?

Code:

if( diffDist <= matchTol){ uTau[cellI] = uTau.boundaryField()[patchi][facei];    break;}

'Map' to each volume cell the $u_{\tau}$ of the perpendicular wall boundary field cell ??? (I am at an absolutely beginning stage of C++).

Maybe you could clarify these points a bit more

Aylalisa

cosimobianchini · March 21, 2014, 05:44

1) This is to deal with wall-function approach. In your case at the wall mu_eff = mu so you could use it in both terms without errors but for wall function approach mu_eff != mu so it is more robust to follow the correct definition of tau_w (i.e. using mu_eff) so it can be applied to both cases.
If your nu is going to zero then your flow is inviscid thus I do not see the point in calculating y+.
2) As I said previously I think using UMean is wrong (at least in principle) since its gradients could largely differ from instantaneous velocity one. On the other side verifying on a single instantaneous solution might not be representative because y+ constraints should be verified on each wall point for each time step. In order to avoid this tedious operation you could try time-averaging y+ and verify which is your margin to 1.
3) This is a code extract showing how to use wallDistData class. It was written to implement Chien Low-Reynolds k-epsilon turbulence model for OpenFOAM-1.3. Might be a but out-of-date but I guess the relevant part is unchanged. Good luck

Code:

forAll(mesh_.boundary(), patchi)
{
      const fvPatch& patch = mesh_.boundary()[patchi];

      //Calculate wall properties : velocity gradient, shear stress, friction velocity
      if (typeid(patch) == typeid(wallFvPatch))
      {
        fvPatchScalarField& wallData = yStar.boundaryField()[patchi];
	wallGradU.boundaryField()[patchi] = - U_.boundaryField()[patchi].snGrad();
	Tau_wall.boundaryField()[patchi] = (- mesh_.Sf().boundaryField()[patchi]                  / mesh_.magSf().boundaryField()[patchi]) & Dev.boundaryField()[patchi];

        U_tau.boundaryField()[patchi] = sqrt(mag(Tau_wall.boundaryField()[patchi]));
        wallData = mu().boundaryField()[patchi]/ rho_.boundaryField()[patchi]
                                                                       / U_tau.boundaryField()[patchi];
               
       }
}

// Assign yStar value to y_.data()	
wallDistData<wallPointData<scalar> > y_(mesh_, yStar, true);
yPlus = y_/y_.data();

littlescorpion · May 4, 2014, 09:24

Quote:

Originally Posted by cosimobianchini

1) This is to deal with wall-function approach. In your case at the wall mu_eff = mu so you could use it in both terms without errors but for wall function approach mu_eff != mu so it is more robust to follow the correct definition of tau_w (i.e. using mu_eff) so it can be applied to both cases.
If your nu is going to zero then your flow is inviscid thus I do not see the point in calculating y+.
2) As I said previously I think using UMean is wrong (at least in principle) since its gradients could largely differ from instantaneous velocity one. On the other side verifying on a single instantaneous solution might not be representative because y+ constraints should be verified on each wall point for each time step. In order to avoid this tedious operation you could try time-averaging y+ and verify which is your margin to 1.
3) This is a code extract showing how to use wallDistData class. It was written to implement Chien Low-Reynolds k-epsilon turbulence model for OpenFOAM-1.3. Might be a but out-of-date but I guess the relevant part is unchanged. Good luck

Code:

forAll(mesh_.boundary(), patchi)
{
      const fvPatch& patch = mesh_.boundary()[patchi];

      //Calculate wall properties : velocity gradient, shear stress, friction velocity
      if (typeid(patch) == typeid(wallFvPatch))
      {
        fvPatchScalarField& wallData = yStar.boundaryField()[patchi];
	wallGradU.boundaryField()[patchi] = - U_.boundaryField()[patchi].snGrad();
	Tau_wall.boundaryField()[patchi] = (- mesh_.Sf().boundaryField()[patchi]                  / mesh_.magSf().boundaryField()[patchi]) & Dev.boundaryField()[patchi];

        U_tau.boundaryField()[patchi] = sqrt(mag(Tau_wall.boundaryField()[patchi]));
        wallData = mu().boundaryField()[patchi]/ rho_.boundaryField()[patchi]
                                                                       / U_tau.boundaryField()[patchi];
               
       }
}

// Assign yStar value to y_.data()	
wallDistData<wallPointData<scalar> > y_(mesh_, yStar, true);
yPlus = y_/y_.data();

I am also studying the utility, yPlusLES, these days. Thank cosimo for the answers. I was also confused by the use of nuEff instead of nu until cosimo gave the answers.
But can you also explain why it uses nuLam in the denominator instead of nu, cosimo? Thank you in advance.

aylalisa · May 6, 2014, 08:01

Dear All,

I still stick on the answers of Bruno and Cosimo and my remaining questions are:

I can follow the explanation about $\nu_{eff}$ whereas I don't understand why $\nu_{Lam}$ is used in the code, respectively why it is necessary to introduce $\nu_{Lam}$ ?

According to Cosimo's explanation I understand why the best approach for LES cases finally is to directly time-average y+. Which information gives me this verification?

Quote:

...and verify which is your margin to 1

If I want to display the velocity profile

,

near wall patches is insufficient. Why is it no reasonable to compute

for whole domain???

Is the computation of internalFields (for

and

) in principle possible by using functionObjects (type swakExpression)?

kind regards,
Aylalisa

cosimobianchini · May 9, 2014, 05:25

Hi Elisabeth and Qin,
1) nuLam is introduced due to y+ definition which is based on a comparison between effective shear on the wall and laminar viscosity.
2) if your time-averaged y+ is well below 1 you can substantially sure that your grid satisfy LowReynolds y+ requirements in most time steps.
3) Well if it is for post processing you can make y dimensionless simply computing tau_w on the reference location. The other option is to use wallDistData as previously suggested.
4) Don't think it is easily feasible.

aylalisa · May 9, 2014, 06:37

Hello Cosimo,

thanks a lot, your answers are absolutely helpful for me!

I want to show u+/y+ from a point on the wall, in the viscous layer, in the transition layer and finally in the area where wall turbulence comes up and the last point should be positioned in an area where free shear flow exists. For that graph I need more y+ (and u+) values, therefore I stick on the idea to access/compute internal volume scalar fields for y+ and u+ (instead of a single values).
Is that idea wrong?

Aylalisa

littlescorpion · May 9, 2014, 10:33

Quote:

Originally Posted by cosimobianchini

Hi Elisabeth and Qin,
1) nuLam is introduced due to y+ definition which is based on a comparison between effective shear on the wall and laminar viscosity.

Thank you, cosimo. So nuLam represents molecular dynamic viscosity in the Laminar flow, right? If so, in a LES computation without use of wall function, the yPlusLES utility gives the y+ defined by the equation in the 1st post: y+=y*u_tau/nu. Am I right?

March 13, 2014, 13:20	Questions to utility yPlusLES	#1
aylalisa Senior Member Join Date: Nov 2012 Location: Bavaria Posts: 145 Rep Power: 14	Dear Foamers! I'd like to use yPlusLES (./applications/utilities/postProcessing/wall/yPlusLES/yPlusLES.C). code snippet: Code: volScalarField::GeometricBoundaryField d = nearWallDist(mesh).y(); volScalarField nuEff(sgsModel->nuEff()); const fvPatchList& patches = mesh.boundary(); const volScalarField nuLam(sgsModel->nu()); forAll(patches, patchi) { const fvPatch& currPatch = patches[patchi]; if (isA<wallFvPatch>(currPatch)) { yPlus.boundaryField()[patchi] = d[patchi] sqrt ( nuEff.boundaryField()[patchi] mag(U.boundaryField()[patchi].snGrad()) ) /nuLam.boundaryField()[patchi]; const scalarField& Yp = yPlus.boundaryField()[patchi]; Info<< "Patch " << patchi << " named " << currPatch.name() << " y+ : min: " << gMin(Yp) << " max: " << gMax(Yp) << " average: " << gAverage(Yp) << nl << endl; } } According to the computation of for using Reynolds-averaged Navier-Stokes Equations we have these formulas: $y^+ = \frac{yu_\tau}{\nu}$ , $u_\tau= \sqrt{\frac{\tau_W}{\rho}}$ and $\tau_W = \mu\frac{\delta \overline{u}}{\delta y}$ 1) Computation of yPlusLES according to the code snippet above: Calculation of $\tau_W$ uses nuEff, instead of nu. Whereas nu in the denominator is nuLam (nu). Does this proceeding have a physical or mathematical background? (nuEff could become zero, which is not allowed to happen in the denominator?) 2) Code: mag(U.boundaryField()[patchi].snGrad()) . Is there a case where you have to replace U by a time averaged field U (UMean?) according to the formula for (RANS)? a) RANS with turbulence model (wall region not resolved) Usage of time averaged U field maybe yes, but since a wall function is used, must anyway be computed differently with regard to the wall function's results??? b) RANS with low Reynolds turbulence model (wall region resolved) Case b) seems to be the only case where it is necessary to use a time averaged field for U. Is this assumption right? c) LES (wall region resolved) Which velocity vector field U has to be used to compute $\tau_W$ to catch the real physical situation very close to the wall in a LES computation? Is it assumed that we have a laminar flow very close to the wall and therefore no statistical fluctuations in the viscous sublayer? Therefore use mag(U) as the code shows? 3) In case I want to compute not only close to the wall but for the complete flow domain, how do I have to compute $\tau$ ? something like --> mag(U.snGrad())??? Thanks to everyone who answers! Aylalisa

March 17, 2014, 12:43		#3
cosimobianchini Member cosimo bianchini Join Date: Mar 2009 Location: Florence, Tuscany, Italy Posts: 88 Rep Power: 17	1) agree with Bruno 2) y+ should not be calculated with mean velocity. However for RANS UMean = U (wether you resolve or resolve the viscous sublayer is not important: this is handled by different values of nut at the wall). For LES you could, if respecting the instantaneous velocity constraint is a too tight requirement, time-average yPlus directly instead of using time averaged velocity. 3) As far as I remember, the right class to export wall data in the internal field is the wallDistData class (have a look at vanDriestDelta for usage). In that case you could use the tau_wall of the closest wall distance to define internal field y+. Anyhow I agree with Bruno, I don't see the point in doing that. Hope this help, Cosimo __________________ Cosimo Bianchini Ergon Research s.r.l. Via Panciatichi, 92 50127 Florence - ITALY Tel: +39 055 0763716 Mob: +39 320 9460153 e-mail: cosimo.bianchini@ergonresearch.it URL: www.ergonresearch.it

March 21, 2014, 05:44		#5
cosimobianchini Member cosimo bianchini Join Date: Mar 2009 Location: Florence, Tuscany, Italy Posts: 88 Rep Power: 17	1) This is to deal with wall-function approach. In your case at the wall mu_eff = mu so you could use it in both terms without errors but for wall function approach mu_eff != mu so it is more robust to follow the correct definition of tau_w (i.e. using mu_eff) so it can be applied to both cases. If your nu is going to zero then your flow is inviscid thus I do not see the point in calculating y+. 2) As I said previously I think using UMean is wrong (at least in principle) since its gradients could largely differ from instantaneous velocity one. On the other side verifying on a single instantaneous solution might not be representative because y+ constraints should be verified on each wall point for each time step. In order to avoid this tedious operation you could try time-averaging y+ and verify which is your margin to 1. 3) This is a code extract showing how to use wallDistData class. It was written to implement Chien Low-Reynolds k-epsilon turbulence model for OpenFOAM-1.3. Might be a but out-of-date but I guess the relevant part is unchanged. Good luck Code: forAll(mesh_.boundary(), patchi) { const fvPatch& patch = mesh_.boundary()[patchi]; //Calculate wall properties : velocity gradient, shear stress, friction velocity if (typeid(patch) == typeid(wallFvPatch)) { fvPatchScalarField& wallData = yStar.boundaryField()[patchi]; wallGradU.boundaryField()[patchi] = - U_.boundaryField()[patchi].snGrad(); Tau_wall.boundaryField()[patchi] = (- mesh_.Sf().boundaryField()[patchi] / mesh_.magSf().boundaryField()[patchi]) & Dev.boundaryField()[patchi]; U_tau.boundaryField()[patchi] = sqrt(mag(Tau_wall.boundaryField()[patchi])); wallData = mu().boundaryField()[patchi]/ rho_.boundaryField()[patchi] / U_tau.boundaryField()[patchi]; } } // Assign yStar value to y_.data() wallDistData<wallPointData<scalar> > y_(mesh_, yStar, true); yPlus = y_/y_.data(); wyldckat and aylalisa like this. __________________ Cosimo Bianchini Ergon Research s.r.l. Via Panciatichi, 92 50127 Florence - ITALY Tel: +39 055 0763716 Mob: +39 320 9460153 e-mail: cosimo.bianchini@ergonresearch.it URL: www.ergonresearch.it

May 9, 2014, 05:25		#8
cosimobianchini Member cosimo bianchini Join Date: Mar 2009 Location: Florence, Tuscany, Italy Posts: 88 Rep Power: 17	Hi Elisabeth and Qin, 1) nuLam is introduced due to y+ definition which is based on a comparison between effective shear on the wall and laminar viscosity. 2) if your time-averaged y+ is well below 1 you can substantially sure that your grid satisfy LowReynolds y+ requirements in most time steps. 3) Well if it is for post processing you can make y dimensionless simply computing tau_w on the reference location. The other option is to use wallDistData as previously suggested. 4) Don't think it is easily feasible. __________________ Cosimo Bianchini Ergon Research s.r.l. Via Panciatichi, 92 50127 Florence - ITALY Tel: +39 055 0763716 Mob: +39 320 9460153 e-mail: cosimo.bianchini@ergonresearch.it URL: www.ergonresearch.it

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Frequently Asked Questions about Installing OpenFOAM	wyldckat	OpenFOAM Installation	3	November 14, 2023 12:58
[Other] Contribution a new utility: refine wall layer mesh based on yPlus field	lakeat	OpenFOAM Community Contributions	58	December 23, 2021 03:36
problem with sampling Utility in openFOAM 1.6	carmir	OpenFOAM Post-Processing	10	February 26, 2014 03:00
How to compile a new utility	rudy	OpenFOAM	4	October 1, 2011 23:48
StreamFunction utility	titio	OpenFOAM Post-Processing	0	May 19, 2010 17:04

May 9, 2014, 06:37		#9
aylalisa Senior Member Join Date: Nov 2012 Location: Bavaria Posts: 145 Rep Power: 14	Hello Cosimo, thanks a lot, your answers are absolutely helpful for me! I want to show u+/y+ from a point on the wall, in the viscous layer, in the transition layer and finally in the area where wall turbulence comes up and the last point should be positioned in an area where free shear flow exists. For that graph I need more y+ (and u+) values, therefore I stick on the idea to access/compute internal volume scalar fields for y+ and u+ (instead of a single values). Is that idea wrong? Aylalisa