[JackFischer]

So hello dear CFD Online forum,


I usually get a lot of help just by reading other ones questions and your awesome responses, but this time, I'm kinda lost.


I need to do a grid refinement study for an airfoil. I'm using a k-w Menter SST Turbulence Model in TAU-Code with preconditioning due to the low Machnumber of only 0.079.

Usually I just set up the airfoil with different sets of structured boundary layers, namely the number of cells in the boundary layer and get the initial height and growth rate from an y+ calculator. So far so good.

But as I increase the cell count on the surface, my y+ value starts to jitter no matter what I do.


An example of this is shown in the image. The blue line represents yplus on the upper surface of the airfoil with 100 points on the surface. The orance line is the same airfoil with all the same settings, but 300 points on the surface. I've got good convergence on lift and drag coefficients though.


I thought about the time steppinig, hence I played around with the CFL value, which didnt affect the outcome at all.



Any ideas why the yplus starts to jitter that much? It appears as well in cp and shear stress coefficient which is used to calculate y+.


Thanks a lot for any suggestions

[FMDenaro]

It seems that you have numerical wiggles ... What I can think is that such oscillations are a consequence of the velocity used to compute y+. IT could be the onset of a numerical instability.

You need to check the velocity field.

[JackFischer]

Originally Posted by FMDenaro

It seems that you have numerical wiggles ... What I can think is that such oscillations are a consequence of the velocity used to compute y+. IT could be the onset of a numerical instability.

You need to check the velocity field.

Thanks for the quick reply. Nothing suspicious in the veloctiy field though, I'd say. Is it possible, that the first layer (from which yplus is calculated) can get "too small"?

[FMDenaro]

Originally Posted by JackFischer

Thanks for the quick reply. Nothing suspicious in the veloctiy field though, I'd say. Is it possible, that the first layer (from which yplus is calculated) can get "too small"?

Possibile only if you are using single precision and y+ gets magnitude of that order

[JackFischer]

That being the residuals btw. I don't know what to think about the cuts and jumps of the residuals of drag and lift after 2500 iterations.

[jola]

Interesting problem, I've seen similar behavior in other codes before. As already mentioned the first thing to check is that you are running everything, including the meshing and the stored mesh, in double precision.

The wiggles do not seem to be related to the cell size, so that it directly is odd-even decoupling (up in one cell and down in the next), is that correct? If the wiggles are related to the mesh cells it is most certainly numerical problems, but the plot you showed indicates that the wiggles are bigger than the cells, is that correct?

If you are running everything in double precision and the wiggles are larger than the cells, it could still be numerical problems. It could also be model problems, perhaps related to numerical problems. You had tried to change the CFL number and that didn't help. If I remember correctly Tau is an explicit Runge-Kutta solver, which inherently is not very good at low Ma-number flows or very resolved boundary layers. Has the pre-conditioning been validated for so low Ma-number as you are running? Are there any pre-conditioning parameters that you could change to see if the problem is affected? Or are there different pre-conditioners available?

To check if the problem is somehow related to the turbulence model you could also try to use a different turbulence model. If Tau has an algebraic model like Balwdin-Lomax or Spalart-Allmaras, try one of those to see if the wigles are related to the turbulence model. The code where I saw this problem with before had these problems with the SST k-omega model on double-curved surfaces with resolved boundary layers. It was a combination of numerics and modeling that caused it.

[JackFischer]

Originally Posted by jola

Interesting problem, I've seen similar behavior in other codes before. As already mentioned the first thing to check is that you are running everything, including the meshing and the stored mesh, in double precision.

The wiggles do not seem to be related to the cell size, so that it directly is odd-even decoupling (up in one cell and down in the next), is that correct? If the wiggles are related to the mesh cells it is most certainly numerical problems, but the plot you showed indicates that the wiggles are bigger than the cells, is that correct?

If you are running everything in double precision and the wiggles are larger than the cells, it could still be numerical problems. It could also be model problems, perhaps related to numerical problems. You had tried to change the CFL number and that didn't help. If I remember correctly Tau is an explicit Runge-Kutta solver, which inherently is not very good at low Ma-number flows or very resolved boundary layers. Has the pre-conditioning been validated for so low Ma-number as you are running? Are there any pre-conditioning parameters that you could change to see if the problem is affected? Or are there different pre-conditioners available?

To check if the problem is somehow related to the turbulence model you could also try to use a different turbulence model. If Tau has an algebraic model like Balwdin-Lomax och Spalart-Allmaras, try one of those to see if the wigles are related to the turbulence model. The code where I saw this problem with before had these problems with the SST k-omege models on double-curved surfaces with resolved boundary layers. It was a combination of numerics and modeling that caused it.

Wow, thanks for that informative answer!



I'm struggling with single/double precision, what exactly do you mean by that?



You're right, the wiggles are a lot bigger than the cell size on the surface. I'll check for parameters in and for different preconditioners as well as for another turbulence modell and come back with the results. Spalart-Allmaras is indeed implemented, I'll start with that to validate the turbulence modell.
I doublechecked the residuals for the "working case" and found fluctuations in the resiudals especially for drag as well btw.

[FMDenaro]

Check also the density and pressure field. The oscillations seems to be dissipated along the x-direction, that makes me suspect about the starting of numerical problems in the compression zone. What about the BCs?

[JackFischer]

Originally Posted by FMDenaro

Check also the density and pressure field. The oscillations seems to be dissipated along the x-direction, that makes me suspect about the starting of numerical problems in the compression zone. What about the BCs?

Thanks for the input. Density and pressure fields dont show anythin unusual I'd say. Boundary Conditions are set to viscious wall on the surface. But its a good point, the oscillation indeed gets lower over the chordlength. I'll do the different settings for preconditioning and turbulence models, I hope I'll find something there.

[FMDenaro]

Originally Posted by JackFischer

Thanks for the input. Density and pressure fields dont show anythin unusual I'd say. Boundary Conditions are set to viscious wall on the surface. But its a good point, the oscillation indeed gets lower over the chordlength. I'll do the different settings for preconditioning and turbulence models, I hope I'll find something there.

Have you tried to reduce further the thresholds for the residuals?

[JackFischer]

Originally Posted by FMDenaro

Have you tried to reduce further the thresholds for the residuals?

I did with Menter SST but the Oszillation kept going, especially in drag residual. The value itself decreased to e-10 but oszillated up around a whole Magnitude.
I tested a courser grid (because of Simulation time) with Spalart Allmaras and it seems, that it stopped oszillating after around 2000 steps. I'll do the fine mesh with the same Settings and come back with the results.

Thanks a lot so far!

[sbaffini]

May I suggest to run the case with all things equal except for the viscosity, which you should choose sufficiently bigger to have a fully laminar, steady case. Then try to plot the resulting Cf.

If it is ok, then I would conclude the problem is somehow related to the turbulence model/wall function. Otherwise it is somewhere else in the code or grid.

As a second step I would try an intermediate Re number (still acting on the viscosity only), which is turbulent but such that you don't need the wall function (I know, easier to write than doing). And check again Cf or y+.

If it is ok, then the problem is somehow related to the wall function. Otherwise it is the turbulence model itself (or its use with all the rest).

In this case, trying with another, simpler, turbulence model (SA, like you did) is certainly giving more hints.

[JackFischer]

So, I got somewhat of an interesting solution for the Spalart Allmaras simulation as seen in the image. The drop of y+ at x=0.1 diasappeared to my surprise. Everythin else is as seen before.



Density, pressure and cf plots for the surface show the exact same pattern as the yplus value.

[JackFischer]

Hey folks, got some news here. After several attemps with different settings as you kindly suggested, and no change whatsoever, I went back all to the beginning and noticed, that the database I used for meshing was set up wrong.... Somewhere in the meshing process the setting for akima was resetted to standard line which had the effect, that a finer mesh just made the airfoil kind of rougher. Not much, but enough as it seems.


After setting up the mesh from scratch with focus on the akima setting and doing a few simulations I can state now, that both Menter SST and Spalart Allmaras are doing fine with the preconditioning and the low Mach numbers.


Neverthelesse, thanks a lot for all the great input, I cerntainly looked deeper into the topic with this experience and maybe someone else may find your tips or my error helpful.

[jola]

Thanks for letting us know. This is at least an easy problem to fix