[Lets Talk CFD]

Hello everyone,

I am looking to model the velocity distribution profile in a closed bend channel and my fluid is water, in-compressible, using pisoFoam running LRR turbulent model.

I am currently using OF.6 and here is some information about my simulation's conditions.

The Reynolds number is high, 10^7

Since I am looking at the water velocity in a curved closed channel, my mesh has an inlet, outlet, and four walls.

I am using different wall functions as:

kqRWallFunction in k dictionary
epsilonWallFunction in epsilon dictionary, and
nutURoughWallFunction for the upper wall and nutkWallFunction for other walls in nut dictionary.

At the end of my simulation, when I check the y+ value for my LRR model I got the following value for the average:

upperWall=0 , lowerWall=18, frontAndBackWall=33

I understand that y+>0 and was wondering can someone let me know what could be the reason causing upper wall y+ to be 0? (just to also add that all values of y+ for this wall is 0)

Thank you.
Ebr

[HPE]

So, no decimal points were reported? Just 0? Should have some decimal points, otherwise impossible to have y1+=0 from a running simulation.

[Lets Talk CFD]

Hi Herpes,

That's the exact number I get when I use the y+ function, only 0 for all values (min, max, average) for the upper wall of my channel. I double-checked again and it is just 0 for this wall.

The other walls have the values around 20 and 40 something. I can't understand what is going on with the one wall and how I can solve this problem. Can you think of anything similar?

Thanks again.

[HPE]

what is the value of `controlDict.writePrecision`? can you increase it to like 16, if it is a low value?

[Lets Talk CFD]

It was 6 and I changed it to 16, then checked the yPlus function using:

pisoFoam -postProcess latestTime -func yPlus

and it just gives me 0 for all the three values (min, max, average)! Just to add that it gives the same value 0 when I check for other timesteps too.


Should i re-run my simulations again with the new write Precision value and then check the yPlus?

Thanks again.

[HPE]

For some reason, u* or tau is zero for the upper wall then. Hmm. Difficult to judge without the case itself, but some further points?

Any reason why `nutURoughWallFunction for the upper wall` was being used?
Have you chosen roughness parameters (particularly height) correctly? The wall-normal cell-centre height vs roughness height inconsistency might be the reason?

Can you sample the velocity field by using nearWallFields FO?

[Lets Talk CFD]

I use this wall function because it allows me to change the different roughness parameters and see the effect.

Currently, I am looking at the effect of roughness height change, for 3 values of 5e-4, 1e-4, and 1e-3, corresponding to 0.5 mm,0.1 mm, and 1 mm respectively. It is for I am assuming the top wall is ice, for the water freezes and forms ice and act as a rigid top surface cover.

Here, I also kept the roughness constant 0.5 which is same as default.

I re-started the simulations just earlier to see if y+ value changes, and have to wait a couple of days for the simulations to get to 1/3 or 1/2 of the end time and then check some of my new results.


Do you think changing the initial values in the R dictionary (from the default which is (0 0 0 0 0 0) currently) would help?

Thanks much again.

[HPE]

>> Do you think changing the initial values in the R dictionary (from the default which is (0 0 0 0 0 0) currently) would help?

I really don't think so.

I also really don't know the solution (without the case), I'm afraid. Hope some other person can give a hand.

[Lets Talk CFD]

Thanks much Herpes for your comments, I just checked the latest simulations, although it is just over 10% done, but I see the value of y+ is now increased to 18-something for the upper wall (where the problem was). This is thanks to your comments that I found a simple unit conversion missed in the earlier simulation, and now that it is corrected in these new runs, it seems to be solving the problem.

Also, changing the initial value for R gave an error as soon as I started the run, so you are right and it wasn't helpful.

Thanks again and wishing you all the bests.
Ebr