CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

yPlusLES

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   February 2, 2014, 07:18
Default
  #41
Senior Member
 
Join Date: Jan 2013
Posts: 157
Rep Power: 3
openfoammaofnepo is on a distinguished road
Yes, thanks. Strongly support your jobs!!
openfoammaofnepo is offline   Reply With Quote

Old   February 2, 2014, 12:20
Default
  #42
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,122
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
Quick note: I've adapted the official bug fix to my repository, but there is a somewhat small discrepancy in the results achieved with the function object versus my custom utility.
The reason is likely because I'm using the "rho" from the thermodynamic model, while the function object is using the one from the turbulence model.

I have not yet changed this, because it's a bit complicated to do so. There is an issue open for fixing this, so for anyone reading this, feel free to contribute: https://github.com/wyldckat/yPlusLES...sible/issues/1
wyldckat is offline   Reply With Quote

Old   April 10, 2014, 09:15
Question
  #43
Senior Member
 
Join Date: Jan 2013
Posts: 157
Rep Power: 3
openfoammaofnepo is on a distinguished road
Just comment here:

In openfoam, to correctly predict the y+, we need the the velocity gradient at the wall snGrad. Actually, this is just just a difference using the deltaCoeff and velocity difference, so in LES, if the first cell is very far from the wall, the y+ that OF give will not be very accurate.

This is my personal understanding, Please comment as well if what I am saying is not reasonable.

OFFO

Quote:
Originally Posted by wyldckat View Post
Hi openfoammaofnepo,

OK, let's see how I can manage LaTeX equations here on the forum... based on these wiki pages:
The fully extended equation is: y^+ \equiv y \, \frac{\sqrt{\frac{\mu \left(\frac{\partial u}{\partial y} \right)_{y=0}}{\rho}}}{\frac{\mu}{\rho}}

In contrast, the equation present on the utility is this (if I'm not mistaken): y^+ \equiv y \, \frac {\sqrt{ \mu_{Eff} \, \|{\frac{\partial u}{\partial y}}\| } } {\mu}

Yes, you are correct!!! It's missing a \rho inside the square root! Feel free to report this at the official bug tracker: http://www.openfoam.org/bugs/ - since this problem is present in the original code of the function object "yPlusLES".

If you don't want to report this yourself, I can report this for you.

Best regards,
Bruno
openfoammaofnepo is offline   Reply With Quote

Old   April 10, 2014, 16:03
Default
  #44
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,122
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
Hi OFFO,

Quote:
Originally Posted by openfoammaofnepo View Post
In openfoam, to correctly predict the y+, we need the the velocity gradient at the wall snGrad. Actually, this is just just a difference using the deltaCoeff and velocity difference, so in LES, if the first cell is very far from the wall, the y+ that OF give will not be very accurate.
Technically, the first cell is never far away from the wall, as it is glued to the wall . But that cell might be very large and its centre might be very far away from the wall.
The thing is that if the cell centre is very far away, then the y+ value will probably be very large as well, which would make it a bit redundant to know if the y+ is 1002 or 1100, since... well, it's clearly still in the region where we can use the wall function. And in such a case, it probably means that your mesh needs some fine tuning.

But there are a few other problems associated with this:
  • If the wall function does need y+ for the model calculation, then it might overestimate or underestimate the expectable turbulence values near the wall.
  • If the cell is distorted and it's centre isn't aligned with the normal of the wall, then the y+ might range from "not very accurate" to "very wrong".
Sometime ago there was a bug report/discussion regarding the wall distance calculation... actually, there are two:
edit: my guess is that those bug reports won't be closed, unless there is explicit sponsorship for those fixes to be implemented.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   April 11, 2014, 05:36
Default
  #45
Senior Member
 
Join Date: Jan 2013
Posts: 157
Rep Power: 3
openfoammaofnepo is on a distinguished road
Thank you for your comments.

For wall function in RANS for mut (mutUWallFunction):
Since log law will be used for the first cell near the wall, then we must make that y lie in the log-law region (y+>30);

For wall function in LES for muSsgs (USpaldingWallFunction):
Since this wall law is semi-emperical formula to fit the linear law and log law, so this law can be used in whole inner turbulent boundary layer, i.e. viscous sublayer, buffer layer and log law regions. So for this case, y+ is only reqiured to lie in inner layer, instead of only log law.

About the way to calculate the y+, actually, in the implementations for MutUWallFunction
Code:
OpenFOAM-2.1.x / src / turbulenceModels / compressible / RAS / derivedFvPatchFields / wallFunctions / mutWallFunctions / mutUWallFunction / mutUWallFunctionFvPatchScalarField.C
, we have another form:

Code:
tmp<scalarField> mutUWallFunctionFvPatchScalarField::calcYPlus
(
    const scalarField& magUp
) const
{
    const label patchI = patch().index();

    const RASModel& rasModel = db().lookupObject<RASModel>("RASProperties");
    const scalarField& y = rasModel.y()[patchI];
    const fvPatchScalarField& rhow = rasModel.rho().boundaryField()[patchI];
    const fvPatchScalarField& muw = rasModel.mu().boundaryField()[patchI];

    tmp<scalarField> tyPlus(new scalarField(patch().size(), 0.0));
    scalarField& yPlus = tyPlus();

    forAll(yPlus, faceI)
    {
        scalar kappaRe = kappa_*magUp[faceI]*y[faceI]/(muw[faceI]/rhow[faceI]);

        scalar yp = yPlusLam_;
        scalar ryPlusLam = 1.0/yp;

        int iter = 0;
        scalar yPlusLast = 0.0;

        do
        {
            yPlusLast = yp;
            yp = (kappaRe + yp)/(1.0 + log(E_*yp));

        } while (mag(ryPlusLam*(yp - yPlusLast)) > 0.01 && ++iter < 10);

        yPlus[faceI] = max(0.0, yp);
    }

    return tyPlus;
}
This approach is based on the log law and y+ is iteratively predicted from that law.

OFFO

Quote:
Originally Posted by wyldckat View Post
Hi OFFO,


Technically, the first cell is never far away from the wall, as it is glued to the wall . But that cell might be very large and its centre might be very far away from the wall.
The thing is that if the cell centre is very far away, then the y+ value will probably be very large as well, which would make it a bit redundant to know if the y+ is 1002 or 1100, since... well, it's clearly still in the region where we can use the wall function. And in such a case, it probably means that your mesh needs some fine tuning.

But there are a few other problems associated with this:
  • If the wall function does need y+ for the model calculation, then it might overestimate or underestimate the expectable turbulence values near the wall.
  • If the cell is distorted and it's centre isn't aligned with the normal of the wall, then the y+ might range from "not very accurate" to "very wrong".
Sometime ago there was a bug report/discussion regarding the wall distance calculation... actually, there are two:
edit: my guess is that those bug reports won't be closed, unless there is explicit sponsorship for those fixes to be implemented.

Best regards,
Bruno
openfoammaofnepo is offline   Reply With Quote

Old   April 11, 2014, 17:32
Default
  #46
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,122
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
Hi OFFO,

Problem is that most (if not all) implementations will require the distance of the centre of the cell (or at least I think it is) to be accurate enough, otherwise all y+ calculations will be too different from the "real" values.

I took a quick look at where y+ was used in the source code:
  • Many of the "Mut" and "Nut" fields for the wall functions depend on y+.
  • There are several other situations where y+ is also used, mostly related to turbulence modelling.
I guess that the 2 bug reports I mention in the previous post are referring to exactly this issue you're mentioning, namely that a non-accurate calculation of y will lead to non-accurate y+ and therefore affect the turbulence models. And as I wrote before, it's unlikely that this issue will be fixed without a support contract being hired from them. Which makes sense, since this requires a lot of validation tests and performance assessments.


With some effort, it's possible to adapt the code made available on the second bug report: http://www.openfoam.org/mantisbt/view.php?id=968 - the idea would be to copy-paste-rename the turbulence models you want to use and modify them to use this new wall distance calculation, instead of the standard one.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   April 11, 2014, 17:43
Default
  #47
Senior Member
 
Join Date: Jan 2013
Posts: 157
Rep Power: 3
openfoammaofnepo is on a distinguished road
What you said is correct. The discussion with you always make me learn lots of knowledge about Openfoam. Thank you.

OFFO
openfoammaofnepo is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
yPlusLES for compressible cases borrbyper OpenFOAM Bugs 3 March 29, 2013 20:23
Problem with yPlusLES youyoufish1987 OpenFOAM Post-Processing 1 July 2, 2012 08:33
yPlusLES and thermophysicalProperties wizard1301 OpenFOAM Running, Solving & CFD 1 January 27, 2012 10:01
Compressible LES, yPlusLES problem. fgal OpenFOAM Post-Processing 0 June 3, 2010 10:02
CheckYPlus bug paka OpenFOAM Running, Solving & CFD 5 July 30, 2008 04:34


All times are GMT -4. The time now is 14:32.