CFD Online Discussion Forums
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM (https://www.cfd-online.com/Forums/openfoam/)
-   -   y+ and u+ values with low-Re RANS turbulence models: utility + testcase (https://www.cfd-online.com/Forums/openfoam/86562-y-u-values-low-re-rans-turbulence-models-utility-testcase.html)

florian_krause March 26, 2011 05:30
y+ and u+ values with low-Re RANS turbulence models: utility + testcase
 
2 Attachment(s)
Dear all,

This issue was already discussed in some length in various threads. Therefore I finally reviewed and attached my plusPostRANS utility.

It calculates y+ and u+ values when using one of the available low-Re RANS turbulence models. I hope the code as well as the output will be self-explaining

I also attached a case. It is a straight pipe (wedge) with periodic inlet/outlet boundary conditions. The Reynolds number based on the mean axial velocity is Re=5300. You can run the case using pisoFoam.

I would appreciate any feedback, it might be still improved at some point! :)

Best regards,
Florian

jms March 28, 2011 11:50
Dear Florian,

Thank you very much for the utility you have uploaded. I really need something like that.

I am doing a study of the flow around an airfoil using k-w SST in low-Re meshes. I tried your utility and hve some comments. Everything looks ok for me until the point where you write these two lines:
1) yPlus = y.y() * uTauAvg / RASModel->nu();
2) uPlus = U / uTauAvg;

1) yPlus is what you call "YpTemp", isn´t it? I don´t know why you use this uTauAvg value you have calculated to recalculate it.
2) uPlus =u_mean/uTau. This would be the velocity of the mean flow over the what you call "uTau".

If you agree and you change it, could you please upload it? Otherwise give me some comments about it.

Thank you very much!

Best Regards,

José

florian_krause March 28, 2011 18:16
Dear Jose,
thanks for your feedback!

First I calculate y+ of the first grid point normal to the wall(s). I store the values in YpTemp and output the corresponding min, max, avg values on the screen.
Then I calculate the wall-averaged friction velocity uTauAvg (see below why I do that).

I think it is clear so far and for some people the y+ value of the first grid point normal to the wall might be sufficient.

Within the two mentioned lines I calculate fields of y+ and u+. If you think about a fully developed turbulent channel or pipe flow you might want to compare your results to, for instance, available DNS data by means of the near wall velocity profile in wall units or in other words comparing a profile of u+ over y+.

I hope it is clear now?

Best,
Florian

vaina74 March 29, 2011 06:31
Florian, you're simply great. Seven years for this useful, precious utility.
I builded it and seems to work fine. I hope it's right too :-)
I can't really understand the implementation of y*. I looked for it on internet and it seems to be used only in FLUENT. In the FLUENT User Guide I read:
Quote:
Note that y+ and y* have comparable values when the first cell is placed in the log-layer
But the question is: even if it was true (but it doesn't look so after my first tests), are they still comparable in the subviscous layer? I'm not sure about that, if I check my mesh quality when going to solve the boundary layer. Anyway, I can't get the physical sense of y*. I'm probably wrong, but I think that the average fluctuating kinetic energy is correlated to fluctuations, not to local or friction velocity. I can have large or small fluctuations with high or low velocity.
Well, I hope your utility will be tested and included in OF. I builded it in OF-1.5-dev and it's OK - I simply changed some paths.

jms March 29, 2011 07:04
@Florian: This averaging you have done makes sense for me when talking about flow in a pipe or a channel, where you will have the same y+ and u+ in all its walls. However, for an airfoil, where you have this different distribution of velocities and pressures you can not do it. It has to be done without averaging, as I told you in the previous message.
The part of the code that gives you in the command prompt y+ (coming from Yptemp) is ok for me to get y+. However, I cannot use the files yplus and uplus to draw the boundary layer.

@vaina74: I am sure based on the results I get that y* and y+ are not comparable inside the viscous sublayer. This is why I am using Florian´s code and one which was already uploaded but did not create the files "yplus" and uplus".

Regards,

José

vaina74 March 29, 2011 07:45
I'm involved with marine propellers, so I study external flows as jms. I understand what he means, I agree with him. I also think you can't have that assumption about averaging operation.

florian_krause March 29, 2011 10:50
Dear Jose,

I totally agree with you on the point that the averaging over the wall is not usefull for your case.

I have implemented that because I was studying, as said in the previous message, fully developed turbulent pipe and channel flow using low-Re RANS models and LES models.

If it really bothers you guys, that it writes the files yPlus and uPlus in the corresponding time directory, I suggest you to remove the relevant sections in the code, so that you just output the min, max, avg y+ value of the first grid point normal to the wall :)

Best,
Florian

vaina74 March 29, 2011 11:21
OK, I can remove the above lines or even don't look at those values :-D
It was just a suggestion in order to make your utility more 'universal', if included in OF in the future.
Anyway, thanks a lot again. Now I see why I obtained strange results from my case, when I tried to have a finer mesh and solve the boundary layer. the f*** y* said 'you're inside it!' but I was in the forbidden zone :-)

rob3rt 0ng May 9, 2011 01:36
Hello All,

I'm still abit unclear about this issue of y+ and y*. So is it right to say that yPLusRAS and yPlusLES return y* values whereas the code Florian uploaded returns y+?

Thanks very much for your time and attention.

Thanks
Robert

florian_krause May 9, 2011 03:56
Hello Robert,

my code calculates y+ as defined here:

http://www.cfd-online.com/Wiki/Dimen...e_%28y_plus%29

so, basically, my little utility calculates the wall normal distance (and velocity) in wall units.

The yPlusRAS utility calculates y* as defined here (normally I try not to quote the FLUENT manual):

http://my.fit.edu/itresources/manual...ug/node512.htm

The yPlusLES utility again calculates y+, quite similar (references to the turbulence model, etc are different) to my utility.

You should check the source code:

http://foam.sourceforge.net/doc/Doxy...8C_source.html

http://foam.sourceforge.net/doc/Doxy...8C_source.html

To understand why, plusPostRANS (my utility) and yPlusLES are used when no wall function are employed, whereas yPlusRAS is used when you employ wall functions.

hope this helps! for everyone, please correct me if I am unclear or wrong at some point.

Best,
Florian

rob3rt 0ng May 9, 2011 04:16
That's crystal clear to me. Thanks very much for your time and attention.

Regards,
Robert

vaina74 May 10, 2011 07:02
Hi, Florian. I have two more little questions for you.

1. I don't understand what you mean with
Quote:
To understand why, plusPostRANS (my utility) and yPlusLES are used when no wall function are employed, whereas yPlusRAS is used when you employ wall functions.
I can't use your code, when a turbulent model with wall functions is applied?

2. I sometimes have the following error, when I run your utility:
Code:
[of_mauro@ofmaster:
/daten/of_mauro/tandem/SVA/tandem_35mm_70plusdeg_VERTIG/propeller]
plusPostRANS
/*---------------------------------------------------------------------------*
| ========= |
|
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox
|
| \ / O peration | Version: 1.5-dev
|
| \ / A nd | Revision: exported
|
| \/ M anipulation | Web: http://www.OpenFOAM.org
|
*---------------------------------------------------------------------------*/
Exec : plusPostRANS
Date : May 10 2011
Time : 09:35:37
Host : ofmaster.cluster
PID : 11391
Case : /daten/propeller
nProcs : 1

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

Create mesh for time = 0

Calculating wall distance

Writing wall distance to field y

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches:
stitch_in/stitch_out
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 0.000660947 average:
0.000164952
Largest master weighting factor correction: 0.0616967 average: 0.000553025

Initializing the GGI interpolator between master/shadow patches:
cyclic_1/cyclic_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.61023e-06 average:
4.22461e-09
Largest master weighting factor correction: 2.6471e-06 average:
4.24771e-09

Initializing the GGI interpolator between master/shadow patches:
symmetry_1/symmetry_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.76395e-17
Largest master weighting factor correction: 2.77556e-15 average:
6.92661e-17

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
Summary:

y+ for Patch 0 named blade1: min: 0 max: 0 average: 0 avgUGradWall: 0

y+ for Patch 1 named blade2: min: 0 max: 0 average: 0 avgUGradWall: 0

avg. friction velocity uTau is: 0 (averaged over 2 wall(s))

Floating point exception
Have you ever encountered it? What does it mean, in your opinion?

Thanks for your help, regards.

rob3rt 0ng May 10, 2011 08:11
Hello,

For your question 2, that happens to me as well everytime I set my wall velocity as fixedValue&$internalField. In contrast everytime I set the wall velocity as fixedValue&uniform (0 0 0) or slip, the utility works fine.

Perhaps Florian may comment on this?

Thanks and regards,
Robert

vaina74 May 10, 2011 08:17
Mh. I don't think so. I also set
Code:
type            fixedValue;
value          uniform (0 0 0);
as wall velocity

rob3rt 0ng May 10, 2011 09:55
Hello again,

As it turns out for my case that both the $internalField and uniform (0 0 0) now give me the y+ value. My problem was setting the wall velocity the same as my inlet velocity, so now for my wall velocity I just set something very close to the inlet velocity.

Thanks
Robert

florian_krause May 10, 2011 13:07
@vaina74-what I mean is, if you use a high-Re RANS model, as for instance standard k-eps RANS model, you will use wall functions and thus your first grid point normal to the wall will not be located at around y+=<1, but somewhere, lets say in the logarithmic region. Then plusPostRANS is not the right tool, because for instance the gradient calculation will not be accurate. I think for this purspose, you should use yPlusRAS.

In fact, if you are about to generate a grid and you want to know if your first grid point is located at the right wall normal distance, then you should be able to use it, plusPostRANS and yPlusRAS should give you almost the same. I never tried that, but would be nice if you would let me know what it gives... sorry for the confusion!

Considering the second problem, without having a look at the case, ICs and BCs I cannot tell you why you get a floating point exception. But it seems that you velocity gradient is for some reason zero?!

Hope I could help!

Best,
Florian

vaina74 May 17, 2011 04:33
Quote:
what I mean is, if you use a high-Re RANS model, as for instance standard k-eps RANS model, you will use wall functions and thus your first grid point normal to the wall will not be located at around y+=<1, but somewhere, lets say in the logarithmic region. Then plusPostRANS is not the right tool, because for instance the gradient calculation will not be accurate. I think for this purspose, you should use yPlusRAS
Well, I didn't understand that, thanks for your specification. I use k-w SST turbulent model with high-Re grids and wall functions. But I don't know if yPlusRAS tool is really meaningful. In another thread i wrote:
Quote:
I'm really surprised to find out that yPlusRAS evaluate y*, not y+. Why was y* implemented?! I can't understand the reason. I looked for it on internet and it seems to be used only in FLUENT. In the FLUENT User Guide I read:

Note that y+ and y* have comparable values when the first cell is placed in the log-layer.

But are they still comparable in the subviscous layer? I'm not sure about that, so the question is: how can I check my mesh quality if I'm going to solve the boundary layer? Only a yPlusRAS (based on y*) is available. Anyway, I can't get the physical sense of y*. I'm probably wrong, but I think that the average fluctuating kinetic energy is correlated to fluctuations, not to local or friction velocity. I can have large or small fluctuations with high or low velocity. Can anyone explain that?
I already tried to apply both y+ post-processing tools. Your code seems to output higher values, but I can't say if it depends on my specific case.

About the second problem I wrote about, I attach my IC and BC. What seems strange to me is that your tool sometimes fails (I'm running very similar cases on these weeks in order to test different propellers configurations).

romant July 1, 2011 09:25
not compatible with OF 2.0.0
 
hej,

unfortunately, one cannot compile this one with OF 2.0.0. It throws the following error message:

Code:
plusPostRANS.C: In function ‘int main(int, char**)’:
plusPostRANS.C:96:40: error: ‘class Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >’ has no member named ‘boundaryField’
plusPostRANS.C:99:36: error: ‘class Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >’ has no member named ‘boundaryField’
apparently, the class geometric field was changed.

florian_krause July 1, 2011 10:19
I haven't downloaded and installed OF-2.0.0 yet, so I might be of limited help here...

Anyway, if the plusPostRANS source is not modified, then the compiler seems to complain about RASModel->nu().boundaryField()[patchi]

I would suggest you to check out the source of the yPlusLES utility of OF-2.0.0 and look for differences to the previous version, lets say OF-1.7.x

The point is, in all three codes (yPlusLES.C from OF-2.0.0, yPlusLES.C from OF-1.7.x and plusPostRANS.C from OF-1.7.x) you need something like RASModel->nu().boundaryField()[patchi] or sgsModel->nu().boundaryField()[patchi] respectively.

Best,
Florian

grandgo July 11, 2011 03:41
Quote:
Originally Posted by vaina74 (Post 306974)
Hi, Florian. I have two more little questions for you.

1. I don't understand what you mean withI can't use your code, when a turbulent model with wall functions is applied?

2. I sometimes have the following error, when I run your utility:
Code:
[of_mauro@ofmaster:
/daten/of_mauro/tandem/SVA/tandem_35mm_70plusdeg_VERTIG/propeller]
plusPostRANS
/*---------------------------------------------------------------------------*
| ========= |
|
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox
|
| \ / O peration | Version: 1.5-dev
|
| \ / A nd | Revision: exported
|
| \/ M anipulation | Web: http://www.OpenFOAM.org
|
*---------------------------------------------------------------------------*/
Exec : plusPostRANS
Date : May 10 2011
Time : 09:35:37
Host : ofmaster.cluster
PID : 11391
Case : /daten/propeller
nProcs : 1

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

Create mesh for time = 0

Calculating wall distance

Writing wall distance to field y

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches:
stitch_in/stitch_out
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 0.000660947 average:
0.000164952
Largest master weighting factor correction: 0.0616967 average: 0.000553025

Initializing the GGI interpolator between master/shadow patches:
cyclic_1/cyclic_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.61023e-06 average:
4.22461e-09
Largest master weighting factor correction: 2.6471e-06 average:
4.24771e-09

Initializing the GGI interpolator between master/shadow patches:
symmetry_1/symmetry_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.76395e-17
Largest master weighting factor correction: 2.77556e-15 average:
6.92661e-17

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
Summary:

y+ for Patch 0 named blade1: min: 0 max: 0 average: 0 avgUGradWall: 0

y+ for Patch 1 named blade2: min: 0 max: 0 average: 0 avgUGradWall: 0

avg. friction velocity uTau is: 0 (averaged over 2 wall(s))

Floating point exception
Have you ever encountered it? What does it mean, in your opinion?

Thanks for your help, regards.

hi vaina,

i've encountered the same problem about some "floating point exception".
do you know the solution for this problem?

EDIT: after some testing i've found out that it's something about this code at the end the .C file:

Code:
    yPlus = y.y() * uTauAvg / nuEff;
    uPlus = U / uTauAvg;
if you comment these lines out, the tool will calculate at least. i think it's because somewhere nuEff or uTauAvg is zero and division causes the crash.

here's the error i get:

Code:
#0  Foam::error::printStack(Foam::Ostream&) in "/sw/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1  Foam::sigFpe::sigFpeHandler(int) in "/sw/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2  in "/lib64/libc.so.6"
#3 
 in "/home/stss8/OpenFOAM/stss8-1.7.x/applications/bin/linux64GccDPOpt/uyPlusLES"
#4 
 in "/home/stss8/OpenFOAM/stss8-1.7.x/applications/bin/linux64GccDPOpt/uyPlusLES"
#5  __libc_start_main in "/lib64/libc.so.6"
#6 
 at /usr/src/packages/BUILD/glibc-2.11.2/csu/../sysdeps/x86_64/elf/start.S:116
Gleitkomma-Ausnahme  //floating point exception
i made some changes (LES) and renamed the tool, for your information

best regards
grandgo

florian_krause July 11, 2011 05:55
Hi grandgo,
if its a division by zero, then its definitely not in

Code:
yPlus = y.y() * uTauAvg / RASModel->nu();
or in nuEff what you are using. nu is non-zero as well as nuEff = nu + nu_t. By the way, why do you use nuEff to calculate yPlus?

So division by zero happens then in

Code:
uPlus = U / uTauAvg;
which makes sense if I look at the output vaina74 posted: avgUGradWall: 0. Clearly, the velocity gradient at the wall

Code:
U.boundaryField()[patchi].snGrad()
gives you zero.

Now, my question is, why is this? I dont know your case, but is it possible by any chance, that this is at time 0 and you initialize your internal velocity field as (0 0 0)? just a guess...

Best,
Florian

grandgo July 11, 2011 07:14
hi florian,

Quote:
By the way, why do you use nuEff to calculate yPlus?
i'm using nuEff, because i need the tool for a LES case.

Quote:
nu is non-zero as well as nuEff = nu + nu_t
are you sure? i commented the "uplus line" out and it didnt work as well. same error message.

Quote:
Now, my question is, why is this? I dont know your case, but is it possible by any chance, that this is at time 0 and you initialize your internal velocity field as (0 0 0)? just a guess...
i changed the internal velocity field a little bit from (0 0 0) to (0.001 0 0), but it's no use. the error occurs not at time t = 0 anyway....


best regards
grandgo

florian_krause July 11, 2011 07:40
Hi grandgo,

my understanding is, kinematic viscosity nu shouldn't be zero, since its a physical property, therefore nuEff is not zero. I also think that you should divide by nu and not nuEff even if its a LES case, see

http://www.cfd-online.com/Wiki/Dimen...e_%28y_plus%29

and the source code of the yPlusLES utility.

It really puzzles me where should be a division by zero if you comment out

Code:
uPlus = U / uTauAvg;
since you only divide by nu apart from that.

Is this the only case where you get the error message?

Could you give me a small case where you get the same error message?

Best,
Florian

grandgo July 11, 2011 11:50
Quote:
Originally Posted by florian_krause (Post 315653)
Hi grandgo,

my understanding is, kinematic viscosity nu shouldn't be zero, since its a physical property, therefore nuEff is not zero. I also think that you should divide by nu and not nuEff even if its a LES case, see

http://www.cfd-online.com/Wiki/Dimen...e_%28y_plus%29

and the source code of the yPlusLES utility.

It really puzzles me where should be a division by zero if you comment out

Code:
uPlus = U / uTauAvg;
since you only divide by nu apart from that.

Is this the only case where you get the error message?

Could you give me a small case where you get the same error message?

Best,
Florian
hi florian,

i don't know why nuEff instead of nu is used in yPlusLES utility. i guess it makes no difference.

and it's not the only case, where i get an error message. i picked the pitzDaily case in incompressible/pisoFoam/les and the same problem there.


best,
grandgo

florian_krause July 11, 2011 13:50
Thats weird! I just run the pitzDaily case a few second until t=0.017 (random) and used my own plusPostLES utility-it works!

Here are the relevant code snippets of my plusPostLES:

Code:
int main(int argc, char *argv[])
{
    timeSelector::addOptions();

    #include "setRootCase.H"
#  include "createTime.H"
    instantList timeDirs = timeSelector::select0(runTime, args);
#  include "createMesh.H"

    forAll(timeDirs, timeI)
    {
        runTime.setTime(timeDirs[timeI], timeI);
        Info<< "Time = " << runTime.timeName() << endl;
        fvMesh::readUpdateState state = mesh.readUpdate();

        wallDist y(mesh, true);
        // Wall distance
        if (timeI == 0 || state != fvMesh::UNCHANGED)
        {
            Info<< "Calculating wall distance\n" << endl;
            Info<< "Writing wall distance to field "
                << y.name() << nl << endl;
            y.write();
        }

...

#      include "createPhi.H"

        singlePhaseTransportModel laminarTransport(U, phi);

        autoPtr<incompressible::LESModel> sgsModel
        (
            incompressible::LESModel::New(U, phi, laminarTransport)
        );

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

        const fvPatchList& patches = mesh.boundary();
       
        dimensionedScalar utauAvg("utauAvg", dimVelocity, 0);

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

            if (typeid(currPatch) == typeid(wallFvPatch))
            {
                yPlus.boundaryField()[patchi] =
                    d[patchi]
                  *sqrt
                    (
                        sgsModel->nu().boundaryField()[patchi]
                      *mag(UMean.boundaryField()[patchi].snGrad())
                    )
                  /sgsModel->nu().boundaryField()[patchi];
                const scalarField& Yp = yPlus.boundaryField()[patchi];

                uTau.boundaryField()[patchi] =
                  sqrt
                  (
            sgsModel->nu()
                  *mag(UMean.boundaryField()[patchi].snGrad())
                  );

                const fvPatchScalarField& utauWall =
                  uTau.boundaryField()[patchi];
               
                dimensionedScalar utauTmp("utauTmp", dimVelocity, average(utauWall));
               
                utauAvg += utauTmp;

                nPatch ++;

                Info<< "Patch " << patchi
                    << " named " << currPatch.name()
                    << " y+ : min: " << min(Yp) << " max: " << max(Yp)
                    << " average: " << average(Yp)
                    << " avgUMeanGradWall: " <<  average(mag(UMean.boundaryField()[patchi].snGrad())) << nl << endl;
            }
        }

        utauAvg /= nPatch;
       
        Info << "Avg. shear velocity is: "
            << utauAvg << "; # of walls: " << nPatch << "." << endl;
     

        yStar = y.y() * utauAvg / sgsModel->nu();
        uStar = U / utauAvg;
Maybe some more info. I am using OF-1.7.x and didn't set any additional FPE options in my bashrc file.

Sorry, at the moment there is nothing else coming to my mind what might cause the error.

Regards,
Florian

grandgo July 11, 2011 14:22
Quote:
Originally Posted by florian_krause (Post 315723)
Thats weird! I just run the pitzDaily case a few second until t=0.017 (random) and used my own plusPostLES utility-it works!

Here are the relevant code snippets of my plusPostLES:

Code:
int main(int argc, char *argv[])
{
    timeSelector::addOptions();

    #include "setRootCase.H"
#  include "createTime.H"
    instantList timeDirs = timeSelector::select0(runTime, args);
#  include "createMesh.H"

    forAll(timeDirs, timeI)
    {
        runTime.setTime(timeDirs[timeI], timeI);
        Info<< "Time = " << runTime.timeName() << endl;
        fvMesh::readUpdateState state = mesh.readUpdate();

        wallDist y(mesh, true);
        // Wall distance
        if (timeI == 0 || state != fvMesh::UNCHANGED)
        {
            Info<< "Calculating wall distance\n" << endl;
            Info<< "Writing wall distance to field "
                << y.name() << nl << endl;
            y.write();
        }

...

#      include "createPhi.H"

        singlePhaseTransportModel laminarTransport(U, phi);

        autoPtr<incompressible::LESModel> sgsModel
        (
            incompressible::LESModel::New(U, phi, laminarTransport)
        );

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

        const fvPatchList& patches = mesh.boundary();
       
        dimensionedScalar utauAvg("utauAvg", dimVelocity, 0);

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

            if (typeid(currPatch) == typeid(wallFvPatch))
            {
                yPlus.boundaryField()[patchi] =
                    d[patchi]
                  *sqrt
                    (
                        sgsModel->nu().boundaryField()[patchi]
                      *mag(UMean.boundaryField()[patchi].snGrad())
                    )
                  /sgsModel->nu().boundaryField()[patchi];
                const scalarField& Yp = yPlus.boundaryField()[patchi];

                uTau.boundaryField()[patchi] =
                  sqrt
                  (
            sgsModel->nu()
                  *mag(UMean.boundaryField()[patchi].snGrad())
                  );

                const fvPatchScalarField& utauWall =
                  uTau.boundaryField()[patchi];
               
                dimensionedScalar utauTmp("utauTmp", dimVelocity, average(utauWall));
               
                utauAvg += utauTmp;

                nPatch ++;

                Info<< "Patch " << patchi
                    << " named " << currPatch.name()
                    << " y+ : min: " << min(Yp) << " max: " << max(Yp)
                    << " average: " << average(Yp)
                    << " avgUMeanGradWall: " <<  average(mag(UMean.boundaryField()[patchi].snGrad())) << nl << endl;
            }
        }

        utauAvg /= nPatch;
       
        Info << "Avg. shear velocity is: "
            << utauAvg << "; # of walls: " << nPatch << "." << endl;
     

        yStar = y.y() * utauAvg / sgsModel->nu();
        uStar = U / utauAvg;
Maybe some more info. I am using OF-1.7.x and didn't set any additional FPE options in my bashrc file.

Sorry, at the moment there is nothing else coming to my mind what might cause the error.

Regards,
Florian
hi florian,

why are you using UMean now? and what's Umean?

and whats the difference between utauavg and utauavg.value() ?

florian_krause July 11, 2011 15:41
Quote:
why are you using UMean now? and what's Umean?
sorry for the confusion with UMean in the code snippet... I used the utility for a fully developed turbulent pipe flow and time-averaged the velocity field. With that I calculated the mean (time-averaged) velocity gradient at the wall... I only wanted to show you the code of the utility I used for the pitzDaily case.

Quote:
and whats the difference between utauavg and utauavg.value() ?
I don't understand what you mean by this! Are you talking about this one

Code:
utauAvg += utauTmp;
Its just a dimensionScalar with the dimensions of velocity, see defintion of utauTmp. Its not a class with a member value().

Regards,
Florian

grandgo July 11, 2011 15:50
Quote:
Originally Posted by florian_krause (Post 315739)
sorry for the confusion with UMean in the code snippet... I used the utility for a fully developed turbulent pipe flow and time-averaged the velocity field. With that I calculated the mean (time-averaged) velocity gradient at the wall... I only wanted to show you the code of the utility I used for the pitzDaily case.

I don't understand what you mean by this! Are you talking about this one

Code:
utauAvg += utauTmp;
Its just a dimensionScalar with the dimensions of velocity, see defintion of utauTmp. Its not a class with a member value().

Regards,
Florian
no, in the original code you user this code
Code:
Info << "  avg. friction velocity uTau is: "
            << uTauAvg.value() << " (averaged over " << nPatch << " wall(s))" << nl <<endl;
i'm just wondering...

i don't know what the problem could be. i'm a newbie in c++ programming

the utility would fit perfectly to what i need.
i just go on trying and testing

best
grandgo

florian_krause July 11, 2011 16:13
Quote:
Its just a dimensionScalar with the dimensions of velocity, see defintion of utauTmp. Its not a class with a member value().
OK now I should say sorry for the non-sense... :(

It is a class, would have to check the documentation for the exact definition... but think it comes from the generic dimensioned Type class dimensioned<Type> with member function value(). That means, if you only use uTauAvg it will output name, value and dimension.

Even I am not a C++ expert...
sorry again!

grandgo July 13, 2011 05:09
hi florian,

i'm struggling with the modification :)

the thing is: i'm not changing much at all and it still doesn't work.

here is what i changed in the createFields.H file:

Code:
        autoPtr<incompressible::LESModel> sgsModel
        (
            incompressible::LESModel::New(U, phi, laminarTransport)
        );
and in the .C file i substituted RASModel->nu() with sgsModel->nu().
that's all.

the openfoam version is 1.7.1.
i used the utility with the tutorial case: /incompressible/pisoFoam/les/pitzDaily, too. no chance.

i dont understand this.

EDIT: i think, my problem is history.

these two lines in the modified utility caused the problems in my case:

Code:
1) yPlus = y.y() * uTauAvg / nuEff;
2) uPlus = U / uTauAvg;
the problem with the first line was, that i used nuEff instead of sgsModel->nu(). and nuEff did become zero (nuEff = nu + nuSgs, with negative values of nuSgs possible). so i changed to sgsModel->nu().

the second line caused problems, because uTauAvg was zero at time = 0. as florian assumed, my 0/U internelField value is (0 0 0). so the solution is either to change the internalField value, or, as i did, change the code of the utility a little bit:


Code:
timeSelector::addOptions(false, true);
now the 0 directory is excluded in the calculation and everything is fine.

best
grandgo

jona November 17, 2011 17:05
plusPostRANSUtitility for OF 2.0
 
1 Attachment(s)
Hi *,

for converting the code of Florian to OF 2.0, "RASModel->nu()" had to be explicitely treated as "volScalarField&".

The corrected code is attached.

Have fun,

Jona

fakekarma March 8, 2012 05:28
Hi jona,

I've tried to build the utility as follow:

:~/OpenFOAM/OpenFOAM-2.0.1/applications/utilities/postProcessing/wall/plusPostRANS$ wmake libso
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file plusPostRANS.C
SOURCE=plusPostRANS.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-100 -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/meshTools/lnInclude -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/transportModels -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/turbulenceModels -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/turbulenceModels/incompressible/RAS/RASModel -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/turbulenceModels/incompressible/LES/LESModel -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/turbulenceModels/LES/LESdeltas/lnInclude -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/OpenFOAM/lnInclude -I/home/ag-peinke/OpenFOAM/OpenFOAM-2.1.0/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/plusPostRANS.o
'libNULL.so' is up to date.

so it seems to be no error, but I should now use it it, since it doesn't work simply typing plusPostRANS in the case folder. Should I do something more???

Thanks for your help,

Cheers,

Elia

wouter March 8, 2012 17:29
hello,

type wmake, not wmake libso

hope this works
Wouter

fakekarma March 9, 2012 02:47
Hallo Wouter,
with the command "wmake" works as it should for compiling.
Thanks very much.

Elia

chegdan April 16, 2012 17:24
Hello All,

First of all, thanks to Florian for making this, I have used some other yPlus utilities floating around here and this one was particularly interesting. I was attempting to get a uPlus and yPlus for something other than a pipe flow and I have been reading this thread thinking about the problem. Have made a modification to the plusPostRANSUtility utility provided (for OF 2.1.x) and I nearly get the same answer on Florian's test case (running pisoFoam) with my utility and his. However, it is (edit was) dreadfully slow since it searches for the nearest uTau over all wall faces for each cell.

Right now it calculates a new y value (we will call it cellToFaceDistance), compares it to the current already calculated y value created using wallDist, and if there is a user specified fraction difference (i.e. (cellToFaceDistance-y)/cellToFaceDistance) than it is close enough and grabs that uTau for that cell and stops searching.

I have uploaded the code to github and it can be downloaded with

Code:
git clone git://github.com/chegdan/yPlusUplus.git
It is currently made for OF 2.1.x

EDIT: However, after thinking a bit...I'm not quite sure if this sort of u+ vs y+ is useful in cases where there is boundary layer separation around objects. For something where the streamlines are nice close to the object, it makes sense. For something with separation, it may not be best to non-dimensionalize the velocity field with respect to the friction velocity but the mean velocity. Either way, it was a good bit of code and if anyone can find it useful, enjoy.

Cheers.
Dan

The King April 21, 2012 12:58
Hi! Did you found the error. I get the same, nothing found yet...

eysteinn June 11, 2012 10:11
Quote:
Originally Posted by florian_krause (Post 301087)
Dear all,

This issue was already discussed in some length in various threads. Therefore I finally reviewed and attached my plusPostRANS utility.

It calculates y+ and u+ values when using one of the available low-Re RANS turbulence models. I hope the code as well as the output will be self-explaining

I also attached a case. It is a straight pipe (wedge) with periodic inlet/outlet boundary conditions. The Reynolds number based on the mean axial velocity is Re=5300. You can run the case using pisoFoam.

I would appreciate any feedback, it might be still improved at some point! :)

Best regards,
Florian
Hi Florian,

I have one question regarding your example case.
I noticed that you use zero gradient for epsilon and nut at the wall. Can you ellaborate on why that is?
(I somehow expected epsilon = 1e-9 or something small as you are solving for epsilon tilda and calculated for nut.)

Best regards,
Eysteinn

owayz July 24, 2012 22:33
Hi Jona and Florian,
Thanks for the utility I am sure it will help a lot of people.
I am also interested in calculating the y+ for my case. But I have compressible simulation.
I want to know two things:
1- If its a transient simulation shouldn't we use the mean values of U, rho and other variables?
2- How could I extend this utility to calculate the same numbers of compressible flow?

Regards,
Ali

owayz July 26, 2012 08:42
Compressible y+
 
1 Attachment(s)
Hi,
I have made some small changes in the utility, developed by Florian/Jona. I have tried to make it work with compressible simulations.
Please check it, if you see its working as it is supposed to work.
Regards,
Awais Ali
P.S: For my case it reports a very low y+ values on the wall (unexpectedly). But the value that it writes seems to be Ok.

owayz August 13, 2012 18:56
compressibleyPlusLES
 
1 Attachment(s)
Hi All,
I have written this utility (again by modifying the utility previously developed) to calculate y+ and u+ values for compressible LES simulation.
Please let me know if you find this utility working. For me its working fine. I have used on my own case. The yPlus values are as they were expected to be.

Regards,
Awais


All times are GMT -4. The time now is 15:57.
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page