[schwermetall]

Hi Foamers,
I'm pretty new to OpenFoam and CFD in general. I managed to get good results for low subsonic speeds on the NACA 0012. Now I'm trying to go transsonic for my thesis.

I'm struggling to get a shock visible on an NACA 0012 at freestream mach number of 0.82. First I decided to use rhoSimpleFoam. Correct me if I'm wrong but there are no non-reflecting boundary conditions for this solver. So I went on and tried the following:

• rhoPimpleFoam
• kOmegaSST turbulence model with Wallfunction
• waveTransmissive boundary conditions for in- and outlets
• adjustTimeStep with maxCo 0.95

Mesh:

• the has 125426 cells
• Mesh non-orthogonality Max: 79.17, average: 16.17
• Picture see below

Solver:

• relaxation: p. 0.4; rho 0.6; "(U|h|k|epsilon|omega).*" 0.7;
• for p : solver PCG;
  preconditioner DIC;
• for "(rho|U|h|k|epsilon|omega)" : solver PBiCG;
  preconditioner DILU;

Results:

• Yplus is a little too low with around 14 but increasing it doesn't solve the problem
• k, and Omega stay constant throughout the domain. The logfile says nothing about solving for k or omega which is very strange. I'm using waveTransmissve for them as well
• Mach number exceeds 1 but no shock occurs. Below Mach number and Isobars are plotted
• I have a flow acceleration in some cells behind the airfoil see picture below

After I wasn't lucky with rhoPimpleFoam, I also tried sonicFoam but didn't succeed either to get a shock. Neither increasing the velocity nor changing schemes or increasing domain size helped.

I would very much appreciate some critics or advise how I could go on, as I'm running out of Ideas.

Thanks a lot

[praveen]

Use rhoCentralFoam. That is good for shock capturing and compressible flows.

[alberto]

I agree with praveen. With Ma > 1 you should not use a pressure-based solver.

[schwermetall]

Thanks a lot for the hint rhoCentralFoam really works much better than the others for my case. Even if I don't understand why, as I also tried
- rhoPimpleFoam (which should be density based right ?)
- sonicFoam
- rhoSimpleFoam

I didn't used rhoCentralFoam in the first place as the manual suggests that it does not consider turbulence. But it does.

I'll put my results in here if they're finished. Thanks lot !!

[vkrastev]

Originally Posted by alberto

I agree with praveen. With Ma > 1 you should not use a pressure-based solver.

Hi Alberto, could you please justify this statement? To my knowledge, pressure-based solvers CAN handle transonic flows with shocks, and this has been established quite a long time ago (see for instance "Turbulent Transonic Flow Simulation Using a Pressure-Based Method", Y. G. Lai, R. M. C. SO and A. J. Przekwas, International Journal of Engineering Science, vol 33, issue 4, pp 469-483, 1995). I'm not a density-based solver expert, so of course I might be wrong, but I think that the "supremacy" of density-based approaches for this kind of problems is mainly due to the higher computational efficiency in the solution of Riemann-type problems, rather than a matter of accuracy. What's your opinion about this?

Regards

V.

[alberto]

Originally Posted by vkrastev

Hi Alberto, could you please justify this statement? To my knowledge, pressure-based solvers CAN handle transonic flows with shocks, and this has been established quite a long time ago (see for instance "Turbulent Transonic Flow Simulation Using a Pressure-Based Method", Y. G. Lai, R. M. C. SO and A. J. Przekwas, International Journal of Engineering Science, vol 33, issue 4, pp 469-483, 1995). I'm not a density-based solver expert, so of course I might be wrong, but I think that the "supremacy" of density-based approaches for this kind of problems is mainly due to the higher computational efficiency in the solution of Riemann-type problems, rather than a matter of accuracy. What's your opinion about this?

Hi,

yes, they can manage "high-Mach" number flows. The literature on "all-speeds" pressure based solvers is very long, and they all basically rely on similar algorithms.

In practice, compressible methods allow better numerical schemes to be implemented, which reflect the physics of the problem, and naturally deal with some of the numerical difficulties presented by this kind of flow taking advantage of the mathematical nature of the equations.

P.S. I am not an expert either, but recent experience showed that using a pressure based code to solver high-speed compressible flows is a waste of time. Way too many convergence and stability problems compared to a density-based one.

Best,

[alberto]

Originally Posted by schwermetall

Thanks a lot for the hint rhoCentralFoam really works much better than the others for my case. Even if I don't understand why, as I also tried
- rhoPimpleFoam (which should be density based right ?)

rhoPimpleFoam is pressure-based compressible and unsteady.

I didn't used rhoCentralFoam in the first place as the manual suggests that it does not consider turbulence.

Please report it on http://www.openfoam.com/mantisbt/main_page.php so they can fix that.

Best,

[vkrastev]

Originally Posted by alberto

P.S. I am not an expert either, but recent experience showed that using a pressure based code to solver high-speed compressible flows is a waste of time. Way too many convergence and stability problems compared to a density-based one.

Well, this is quite interesting, since now I'm working on transonic internal flows and indeed I'm facing stability issues with the pressure based sonicFoam solver (although I'm quite sure that some of them are mesh-quality related)...I'll definitely give a try to the rhoCentralFoam (with turbulence added) solver to see if things are better in an overall sense (accuracy+stability). Thank you for the interesting discussion!

Best

V.

[Toorop]

Hi schwermetall,
It would be great if you could share your case setup as well. It would serve as a great starting point for my airfoil investigation. Thx!

[schwermetall]

Hi Foamers,
first of all thanks for the support.
Unfortunately I don't get a steady state solution. At first a I got two shocks on the upper and lower side in the region where they belong. But with increasing time my solution gets unsteady.
There is a region of low pressure that emerges from the trailing edge disturbing the complete flow field around the airfoil. This behaviour could be seen in sonicFoam as well, see first post.

What would you consider a reasonable physical time after the flow around the airfoil should reach a steady state if the conditions are as follows
- freestream velocity: 277 m/s
- airfoil length 1 m
- domain length 40 m
- Co<0.5
- 125 000 cells

I added some picture with different time steps. I don't get a steady state after after 0.14 seconds.
Very strange is, that there are two shocks on the upper side at time 0.11. After some time they occur on the lower side.

thanks a lot

[praveen]

Maybe it needs more iterations to reach steady state. Note that rhoCentralFoam uses global time stepping, so reaching steady state can be very slow. And moreover it uses forward euler time stepping. Atleast, some 2/3/4 stage RK scheme with local time stepping would be more robust and better for steady state problems. But this needs to be coded and is not available as a scheme. But your problem could be something else also, I cannot say.

[schwermetall]

It seems I found the problem concerning the unsteady behavior. I changed the mesh at the trailing edge, so that cells around the last point of the airfoil get less skewed. Below you can see pictures from physical time equals 0.152

Nevertheless the fluctuations in density and velocity at the leading edge remain. Does anyone have an idea what they could come from? I already changed the default divScheme from linear to upwind, but that doesn't help.
Below my fvSchemes for the rhoCentralFoam solver:

fluxScheme Kurganov;
ddtSchemes
{
default Euler;
}
gradSchemes
{
default Gauss linear;
}
divSchemes
{
default Gauss upwind;
div(tauMC) Gauss linear;
}
laplacianSchemes
{
default Gauss linear corrected;
}
interpolationSchemes
{
default linear;
reconstruct(rho) vanLeer;
reconstruct(U) vanLeerV;
reconstruct(T) vanLeer;
}
snGradSchemes
{
default corrected;
}

Grateful for any hints

[vkrastev]

Originally Posted by schwermetall

It seems I found the problem concerning the unsteady behavior. I changed the mesh at the trailing edge, so that cells around the last point of the airfoil get less skewed. Below you can see pictures from physical time equals 0.152

Nevertheless the fluctuations in density and velocity at the leading edge remain. Does anyone have an idea what they could come from? I already changed the default divScheme from linear to upwind, but that doesn't help.
Below my fvSchemes for the rhoCentralFoam solver:

fluxScheme Kurganov;
ddtSchemes
{
default Euler;
}
gradSchemes
{
default Gauss linear;
}
divSchemes
{
default Gauss upwind;
div(tauMC) Gauss linear;
}
laplacianSchemes
{
default Gauss linear corrected;
}
interpolationSchemes
{
default linear;
reconstruct(rho) vanLeer;
reconstruct(U) vanLeerV;
reconstruct(T) vanLeer;
}
snGradSchemes
{
default corrected;
}

Grateful for any hints

From your fvSchemes file it is not clear if you are using a turbulence model or not. In addition, your mesh seems of good quality but maybe a little coarse near the wall, considering the very high speed of your case. So, what are your turbulence model, approximate max y+ value at the airfoil surface and, consequently, wall treatment?

Best

V.

[schwermetall]

hi vkrastev
I'm using RAS model with kOmega turbulence model plus wallfunction, not with resolved boundary layer. My y+ ranges between 26 and 167 (see below) . So consequently the mesh should be even a little coarser near the surface right ?

Boundary consitions are
fixedValue for Velocity at the inlet
zeroGrad for Velocity at the outlet

and
fixedValue for pressure at the outlet
zeroGrad for pressure at the inlet

[vkrastev]

Originally Posted by schwermetall

hi vkrastev
I'm using RAS model with kOmega turbulence model plus wallfunction, not with resolved boundary layer. My y+ ranges between 26 and 167 (see below) . So consequently the mesh should be even a little coarser near the surface right ?

Boundary consitions are
fixedValue for Velocity at the inlet
zeroGrad for Velocity at the outlet

and
fixedValue for pressure at the outlet
zeroGrad for pressure at the inlet

No, your y+ in my opinion is ok for a wall function treatment. Instead, your boundary conditions seem not so adequate for a compressible case. I don't know if this will solve your problem, but i would try something different both for pressure and velocity. If the incoming flow is already supersonic you can try (see the nacaAirfoil tutorial inside the sonicFoam/ras/ tutorial folder):

supersonicFreeStream for velocity at the inlet
zeroGradient for pressure at the inlet

inletOutlet for velocity at the outlet
waveTransmissive for pressure at the outlet

Otherwise, if the incoming flow is subsonic,you can change the inlet conditions in:

fixedValue for velocity
waveTransmissive for pressure

Regards

V.

PS - Now I recall that your inlet condition was subsonic, so you can try directly the second option

[schwermetall]

Hi
thanks for the advice. I thought about changing the boundary condition, but the thing that kept from doing it was, that I couldn't find any pressure waves being reflected at the boundaries. Shouldn't I see at least anything coming back into the domain ?

Nevertheless I'm going to try it and I'll report the results.
By the way what do you recommend for this lInf value when using waveTransmissive? I already played with it but I'm not sure.
From what I understand it is the distance behind the boundary where the given boundary value will be reached ?

Regards

[vkrastev]

Originally Posted by schwermetall

Hi
thanks for the advice. I thought about changing the boundary condition, but the thing that kept from doing it was, that I couldn't find any pressure waves being reflected at the boundaries. Shouldn't I see at least anything coming back into the domain ?

Nevertheless I'm going to try it and I'll report the results.
By the way what do you recommend for this lInf value when using waveTransmissive? I already played with it but I'm not sure.
From what I understand it is the distance behind the boundary where the given boundary value will be reached ?

Regards

Well, actually I haven't played that much with the waveTransmissive BC's, but the fact is that the lesser the lInf the more reflective will become the BC (in the limit of lInf=0 you'll have actually a totally reflective fixed pressure condition), so maybe you can start with a value of the order of the chord lenght of the airfoil and see what happens. Regarding the pressure waves, maybe they can occur in some time steps out of your saving points, bun even if they don't there could be some backflow at the boundaries and the inletOutlet condition on velocity can (in principle) account for these backflows while the zeroGradient condition cannot. Anyway, as I said in my previous post, maybe the problem are not the BC's, but is always better to apply the most appropriate combination of them, in order to focus on other (eventual) issues.

Best

V.

[kiran]

Originally Posted by vkrastev

No, your y+ in my opinion is ok for a wall function treatment. Instead, your boundary conditions seem not so adequate for a compressible case. I don't know if this will solve your problem, but i would try something different both for pressure and velocity. If the incoming flow is already supersonic you can try (see the nacaAirfoil tutorial inside the sonicFoam/ras/ tutorial folder):

supersonicFreeStream for velocity at the inlet
zeroGradient for pressure at the inlet

inletOutlet for velocity at the outlet
waveTransmissive for pressure at the outlet

Otherwise, if the incoming flow is subsonic,you can change the inlet conditions in:

fixedValue for velocity
waveTransmissive for pressure

Regards

V.

PS - Now I recall that your inlet condition was subsonic, so you can try directly the second option

Hi all
I would like start with your mesh first. make the y+ to 2.
Then you should use boundary conditions as suggestd by Vkrastev.
Infact simply Inlet BC works good so that you can state all pressure, temperture and velocity etc... at inlet and at oulet you can make use of zerogradient B.C for all.
Use sonicFoam solver this is a turbulent compressible flow. If you are using 1.6 version there are some issues with sonicFoam solver (you cannot resolve thermal boundary layer).

Density based solvers are generally used for not only capturing shocks but also their interactions and these are very sensitive. where pressure based solvers are not better for these cases.

use small time step for analysis.

Thanks
Kiran Ambilpur

[vkrastev]

Originally Posted by kiran

I would like start with your mesh first. make the y+ to 2.

Not if he is using wall functions (wall functions work bad with too low y+ values: this is a quite basic CFD rule for wall treatment of high-Re flows).

Originally Posted by kiran

at inlet and at oulet you can make use of zerogradient B.C for all.

Well, putting to zeroGradient all the non-fixed quantities works usually fine for incompressible flows, but not so in compressible cases where a bit much care should be employed in the BC choice.

Originally Posted by kiran

Use sonicFoam solver this is a turbulent compressible flow. If you are using 1.6 version there are some issues with sonicFoam solver (you cannot resolve thermal boundary layer).

sonicFoam is an option, but (to my experience) it also has stability issues in transonic flows, while the density based rhoCentralFoam (with turbulence added) seem more stable (though requiring a bit smaller time step size).

Originally Posted by kiran

use small time step for analysis.

This is of course desirable whatever the solver (for rhoCentralFoam maxCo < 0.5 should be fine).

Regards

V.

[schwermetall]

I already tried sonicFoam (2.0) using different boundary conditions schemes etc etc ....
But I wasn't able to get a shock visible, with that solver.

I'm using adjustTimeStep yes; with maxCo of 0.5;

So thanks for the ideas, but I already tried that.