[schwermetall]

Hi ndr,
no I didn't resolve the Boundary layer with y+ = 1.The reason is, that it would take ages. I now got the possibility to run my cases on 6 processors and simulating one second of flow takes 3,5 days.

Be careful, if you use wallfunctions I believe your y+ should be well above 30 !

It is very likely that the instability we observe here is a so called checkerboard instability, which is a decoupling of velocity and pressure. Unfortunatelly the best means would be a staggered grid, which is - as far as I know- not possible in OF at the moment. I can give you another possibility to try: use faceLimited instead of cellLimited, depending on the case that changes again a lot.

My results also still suffer from slight oscillations, but the values are are not smeared. The problem I have at the moment is, that the shocks keeps moving backwards with increasing angle of attack.

regards

P.S.: what just comes to mind: we found that using snappyHexMesh can cause problems when you are at high reynoldsnumbers. The reason seem to be little trinagulars (tetraeder) that emerge from the snapping process. So if you have any object in your channel be careful at high reynoldsnumbers. We're using gmesh instead.

[ndr]

Hi,

regarding the wall functions for the standard setup y+ should be around 30 or higher, but I found this post quite useful:

http://www.cfd-online.com/Forums/ope...tml#post295659

It seems that OF is able to handle 1 < y+ < 30 as well, because the so-called Spalart-Allmaras wall function despite its name seems to be some kind of Spalding composite wall function.

I'm doing my meshes (which use structured hexaeders) with ICEM, and they have been tested using other CFD codes as well, so I can rule out the mesh as a possible origin of the fluctuations.

As far as I understand faceLimited schemes are more dissipative than cellLimited schemes - please correct my if I'm wrong. So when changing to a more dissipative scheme the fluctuations seem to diminish, but at least for my case also does the accuracy of the solution. Up to now the cellLimited scheme yields the best results.

What really surprised me was the fact that all fluctuations completely vanish when I was using no wall functions, because if this is a kind of checkerboard phenomenon it should occur independent of the grid resolution, shouldn't it? Just out of curiosity I used my grid for y+ = 15 and did two runs with exactly the same numerical schemes and setup, only one with wall functions and one without. I know the resolution in theory is too coarse for this no-WF setup, but it showed exactly the same behaviour as y+ = 1: No fluctuations anymore.

Do you know some more people dealing with this fluctuation phenomenon? Because if it's some kind of numerical checkerboard instability or if it has do with the wall functions this should be quite a common problem for all users of rhoCentralFoam...

Regards

[vkrastev]

Originally Posted by ndr

What really surprised me was the fact that all fluctuations completely vanish when I was using no wall functions, because if this is a kind of checkerboard phenomenon it should occur independent of the grid resolution, shouldn't it? Just out of curiosity I used my grid for y+ = 15 and did two runs with exactly the same numerical schemes and setup, only one with wall functions and one without. I know the resolution in theory is too coarse for this no-WF setup, but it showed exactly the same behaviour as y+ = 1: No fluctuations anymore.

Do you know some more people dealing with this fluctuation phenomenon? Because if it's some kind of numerical checkerboard instability or if it has do with the wall functions this should be quite a common problem for all users of rhoCentralFoam...

These are all interesting considerations. It seems like the wall functions are the source of pressure fluctuations in your case, but for me it's quite hard to give a sound-logical explanation for this...At the moment I'm doing some 2D computations with rhoCentralFoam (1.7.1 version of the solver, modified to account for turbulence) for an internal transonic flow case, represented by a throttle valve in a nearly closed position: sampling the pressure distribution around the valve, I didn't see any fluctuations as the one reported by you and schwermetall. For computational time reduction I also use wall functions, with a max y+ value of about 100 for the channel walls and around 50 for the valve. I've tried different turbulence models (Spalart-Allmaras, k-omega SST, standard k-epsilon) as well as the SpalartAllmaras (actually Spalding's) wall function, but no pressure oscillations in any case...For more completeness, I have to underline that my case has an hybrid quad-tria mesh (graded quads near the solid surfaces, trias elsewhere) and that, also, the turbulent kinetic energy and turbulent viscosity generation in the valve wake are very strong, thus my runs are quite diffusive in nature. Finally, as interpolant functions for rho, U and T I'm using the Gamma scheme instead of the vanLeer default one (but results with the vanLeer scheme are very similar).

Best

V.

[schwermetall]

As far as I understand faceLimited schemes are more dissipative than cellLimited schemes - please correct my if I'm wrong

Thats what I heared too.

I'm now trying to run rhoCentralFoam in inviscid mode. The fluctuations are not too big in my case, but the main problem I have is that, the shock on my airfoil is too far downsstream. Has anyone a suggestion how to get a better shock position?

regards

[ndr]

Hi schwermetall,

when I did the test runs with different grids the results showed that the positions of the reflected shock waves in the channel varied depending on the grid resolution. For example compared to a commercial code the positions of the shocks were too far downstream when I used a coarse grid, but with a finer grid also the reflected shocks moved upstream.

I don't know if the same holds true for a single shock on your profile, but it may be worth a try to change the grid resolution a bit and see what happens. You don't even have to go down to y+ = 1, I observed this kind of shock shifting already when changing from y+ = 60 to y+ = 30 without any other changes in the setup. The numerical setup, i.e. the schemes, had no influence on the shock positions at least for my case.

Regards

[schwermetall]

the schemes, had no influence on the shock positions at least for my case

I would support that. The Schemes only influenced the fluctuations.

When it comes to cell size of the mesh, I'm trying a very coarse mesh in inviscid mode at the moment and the shock is off 10%. That's the same for a the fine grid. The coarse grid has 40 000 cells whereas the fine has 140 000 cells.

So I could probably conclude that the shock position is at least not wrong due to the wall model.

Maybe I also try to make the wall nearest cells smaller as you suggested, just to rule that out for sure.

Any other suggestions?

[ndr]

Hi,

I'm still testing different combinations of settings and grids, but up to now the only thing shifting the shock positions was the wall resolution. I attached a picture of my wall pressure distribution for three different grids and as you can see the positions of the reflected shock downstream of about x = 0.6 change quite a lot.

Compared to other codes the results for y+ = 15 are the most accurate, but they still show the pressure fluctuations in the first part of the channel.

Another possibility could be to change the time discretization to a higher order scheme, for example Crank-Nicolson, but for my case this configuration is not running stable at all.

[Technoyoungman]

Dear Schwermetall,
After the simultion, did you happen to check the total pressure and total temperature? I think u should check. I would like to know the result. When I run supersonic flow, OpenFoam cannot give the correct stagnation pressure drop, instead rise in stagnation pressure after shock wave.

[ndr]

Hi,

I had a look at my total pressure within the channel and I could not observe any strange behaviour when calculating using the isentropic formulation:



However, when using Bernoulli's equation I get a pressure rise behind the shock waves. But in my opinion Bernoulli can not be applied here as the total pressure has to be evaluated for each cell and the original equation is only valid along a 1D-streamline.

@schwermetall:

Did you have any success with your shock positions? I kept testing some more cases with another solver and it showed a similar behaviour: Depending on the near wall resolution the positions shifted considerably. However, I still don't have an explanation why this happens...

Regards

[Technoyoungman]

Hi Nils Droeske

Originally Posted by ndr

Hi,

I had a look at my total pressure within the channel and I could not observe any strange behaviour when calculating using the isentropic formulation:



However, when using Bernoulli's equation I get a pressure rise behind the shock waves. But in my opinion Bernoulli can not be applied here as the total pressure has to be evaluated for each cell and the original equation is only valid along a 1D-streamline.

@schwermetall:

Did you have any success with your shock positions? I kept testing some more cases with another solver and it showed a similar behaviour: Depending on the near wall resolution the positions shifted considerably. However, I still don't have an explanation why this happens...

Regards

On Youtube you can see my simulation of intake system of aircraft with 500m/c velocity, 100kPa pressure and 300K temperature. Velocity at compressor inlet is 120m/c. Solver is rhoCentralFoam. The other solvers rhopSonicFoam and rhoSonicFoam didn't work. I don't know why. Floting point error!! Only velocity distribution is shown in video. Static pressure raises after shock but more than it should be. So I checked the total pressure and total pressure also rises. So I checked the tutorial of openFoam "Wedge15M5". The same result occurs. So I assume that it is the bug of openFoam in supersonic flow.There is my post about Wedge15M5 http://www.cfd-online.com/Forums/ope...le-urgent.html

About the grid? Actually using the fine gird should get better results. But When I run the intake with dense mesh, I found that the last one cell at the compressor inlet was calculated wrongly and total pressure has risen to maximum impossible value. I really don't get it.

You can't use Bernoulli's equation on compressible flow.

[vkrastev]

Hi all,
if some of you have encountered accuracy problems with rhoCentralFoam, take a look at the following tread (especially post #11)


http://www.cfd-online.com/Forums/ope...tml#post331239

Regards

V.

[schwermetall]

Hi all,
sorry for not responding for while.

@Technoyoungman:
Yes I did check the total pressure, but as I didn't made a picture back then, I can't tell you anything at the moment. I have to wait until I have access to good hardware again --> my computer crashed and I'm not at the company at the moment. But I'll post it asap
The static pressure overshooted the experimental results, no matter what I tried.

@ndr:
Unfortunatelly I didn't have success with the shock position. It alway remained 15% too far downstream
I even tried to run rhoCentral Foam in inviscid mode and the result was nearly the same.

Had any of you sucess with vkrastev's hint on the bug ?

regards

[ndr]

Hi schwermetall,

I implemented the changes into my rhoCentralFoam version and it improved the restart behaviour considerably. However, it had absolutely no influence on shock positions and flow profiles. As far as I understand in the old version there was simply a redefinition of phi within the rhoCentralFoam.C file while the variable phi had already been defined in createFields.H. So now this is corrected, but it seems this really only affects restarting.

I did some more work on the wall function issue and found another strange phenomenon: When comparing the rhoCentralFoam solution to other solvers it seems that the boundary layer thickness is not correctly predicted for every mesh resolution. Only if no wall functions are used (k--SST and ) the thickness is more or less correct, but when coarsening the mesh (with wall functions) the boundary layer gets thinner the coarser the mesh is. So for and the Spalding WF setup it is about 2/3 the normal size, for and normal WF setup it is only about 20% of the normal thickness. I think because of this difference in boundary layer thickness also the shock reflections at the wall are shifting for my case when changing the grid resolution.

Does any of you have any idea why this might be? I know there have been considerable changes in the wall functions for OF 2.0 (at the moment I'm still using 1.7.x), but can these changes really that important for rhoCentralFoam?

Regards

[vkrastev]

Originally Posted by schwermetall

Thats what I heared too.

I'm now trying to run rhoCentralFoam in inviscid mode. The fluctuations are not too big in my case, but the main problem I have is that, the shock on my airfoil is too far downsstream. Has anyone a suggestion how to get a better shock position?

regards

I know that you had problems with the shock position also in the viscous turbulent runs, but I don't think that you should use the inviscid simulation as a comparison with the experimental data. Anyway, what is your experimental database? I know that in some cases the angle of attack should be corrected in the simulations to take into account the blockage effetcs in the experimental wind tunnel facility (see for instance "Recent experience with different turbulence models applied to the calculation of flow over aircraft components", L. D. Kral, Progress in Aerospace Sciences 34, 1998, pp. 481 541)

V.

ps-also in the case of zero angle of attack, the blockage effects could influence the shock position; in addition, you should be careful about the BL condition at the leading edge of your airfoil: if no artificial "tripping" is introduced in the experiments, in the first part of the airfoil surface the BL is more likely laminar, and this has an influence on the shock position too...remember that using wall functions you are assuming a fully-turbulent BL over the whole airfoil (but it would be difficult to capture the laminar-to-turbulent transition also with most of the more commonly used low-Re turbulence models)