CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

No shock in airfoil 0012 case despite of Mach number exceeds 1

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   October 12, 2011, 10:44
Default
  #21
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi guys
I now changed the boundary conditions for velocity at the outlet to
type inletOutlet
inletValue (0 0 0)

and pressure at the outlet to
waveTransmissive with lInf 2

Doesn't seem to change anything.

I'm now trying somthing completly different. I'm using this MUSCL scheme for divSchemes. Does any of you has experience with it ?

From what I understand this schemes tries to keep fluctuations as low as possible. Which is exactly my problem. Any experience with that ??
schwermetall is offline   Reply With Quote

Old   October 12, 2011, 11:07
Default
  #22
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by schwermetall View Post
Hi guys
I now changed the boundary conditions for velocity at the outlet to
type inletOutlet
inletValue (0 0 0)

and pressure at the outlet to
waveTransmissive with lInf 2

Doesn't seem to change anything.

I'm now trying somthing completly different. I'm using this MUSCL scheme for divSchemes. Does any of you has experience with it ?

From what I understand this schemes tries to keep fluctuations as low as possible. Which is exactly my problem. Any experience with that ??
If you have already tried upwind (and you did, right?), this was the most stable choice you can make about divSchemes. Why don't you try instead with a different turbulence model (for instance, the Spalart-Allmaras one)? Another possibility would be to resolve the boundary layer with a low-Re model, but this would increase a lot the computational time. Finally, you should also consider that the flow could be instable in nature or that it would require a long time to reach a steady-state condition.

Best

V.
vkrastev is offline   Reply With Quote

Old   October 12, 2011, 11:22
Default
  #23
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi vkrastev,
first of all many thanks for staying with me and my problem.

Yes I tried upwind, but not for div(tauMC). I'm now trying MUSCL 0.9 for div(phi,omega) and div(phi,k).

As it takes Ages to make a run, I haven't done major changes like changing the turbulence model today, but I'll let it run over night and report tomorrow.

This is also the reason why resolving boundary layer is no option for me. To get a physical time of 0.2 seconds, my computer is running for nearly 1.5 days. My target is to get an airfoil polar in the end (like Cl over alpha, Cd over Cl ...). So if the computation time increases further for each angle of attack I have to stop there.
schwermetall is offline   Reply With Quote

Old   October 12, 2011, 12:53
Default
  #24
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by schwermetall View Post
Hi vkrastev,
first of all many thanks for staying with me and my problem.
No problem, I'm interested in the performances of rhoCentralFoam too (though my case is quite different from yours).

Quote:
Originally Posted by schwermetall View Post
Yes I tried upwind, but not for div(tauMC). I'm now trying MUSCL 0.9 for div(phi,omega) and div(phi,k).
div(tauMC) is not a convective term, but an explicitly calculated divergence term, so I don't think it could make some difference in the stability of the calculations (actually I'm not even sure it could be calculated in other ways than linear interpolation, as in this case there's no convection velocity involved and thus the concept of "upwind direction" becomes meaningless). Instead, div(phi,<something>) are convective terms, which are always source of stability issues (and in my experience this is especially true for convective terms involving turbulent quantities): so, if you have already tried the upwind scheme on them, then you cannot do anything more about their stability behavior.

Quote:
Originally Posted by schwermetall View Post
As it takes Ages to make a run, I haven't done major changes like changing the turbulence model today, but I'll let it run over night and report tomorrow.

This is also the reason why resolving boundary layer is no option for me. To get a physical time of 0.2 seconds, my computer is running for nearly 1.5 days. My target is to get an airfoil polar in the end (like Cl over alpha, Cd over Cl ...). So if the computation time increases further for each angle of attack I have to stop there.
I understand. In this case you can change the turbulence model retaining the wf treatment near the walls (running for a bit more the simulation and see what happens remains also an option).

Best

V.
vkrastev is offline   Reply With Quote

Old   October 12, 2011, 13:13
Default
  #25
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi vkrastev

concerning div(tauMC) I now think, that I remember that Openfoam returned an error when I tried the upwind scheme. But your explanation is pretty convinient.

short Update:
For the laplacianSchemes it is possible to choose cellLimitedSchemes. If I understand the intention correct, theses Schemes reduce fluctuations by limiting the gradient between neighbouring cell centers. (found a very good explanation cellMDLimited vs. cellLimited )

so I changed my fvSchemes as follows:

gradSchemes
{
default none;
grad(p) cellLimited leastSquares 0.9;
grad(U) Gauss linear;
grad(rho) cellLimited leastSquares 0.9;
grad(rhoU) cellLimited leastSquares 0.9;
grad((1|psi)) Gauss linear;
grad(e) Gauss linear;
grad(sqrt(((Cp|Cv)*(1|psi)))) Gauss linear;
grad(T) Gauss linear;
grad(omega) Gauss linear;
grad(k) Gauss linear;
}

The reason was, that pressure/density are probably the ones causing trouble.

It now seems (! no long time confirmation) as if the pressure oscillations are diminishing. See pictures below
Attached Images
File Type: jpg densityAt0_1841.jpg (18.9 KB, 71 views)
File Type: jpg densityAt0_2171.jpg (18.5 KB, 57 views)
schwermetall is offline   Reply With Quote

Old   October 12, 2011, 22:15
Default
  #26
Senior Member
 
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26
alberto will become famous soon enoughalberto will become famous soon enough
Quote:
Originally Posted by vkrastev View Post
div(tauMC) is not a convective term, but an explicitly calculated divergence term, so I don't think it could make some difference in the stability of the calculations (actually I'm not even sure it could be calculated in other ways than linear interpolation, as in this case there's no convection velocity involved and thus the concept of "upwind direction" becomes meaningless). Instead, div(phi,<something>) are convective terms, which are always source of stability issues (and in my experience this is especially true for convective terms involving turbulent quantities): so, if you have already tried the upwind scheme on them, then you cannot do anything more about their stability behavior.
div(tauMC) must be discretized with a central scheme, since it does not introduce directional bias. Direction-biased schemes are appropriate only for convection.

Best,
__________________
Alberto Passalacqua

GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image.
OpenQBMM - An open-source implementation of quadrature-based moment methods
alberto is offline   Reply With Quote

Old   October 12, 2011, 22:35
Default
  #27
Senior Member
 
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26
alberto will become famous soon enoughalberto will become famous soon enough
Quote:
Originally Posted by schwermetall View Post
Hi vkrastev

concerning div(tauMC) I now think, that I remember that Openfoam returned an error when I tried the upwind scheme. But your explanation is pretty convinient.

short Update:
For the laplacianSchemes it is possible to choose cellLimitedSchemes. If I understand the intention correct, theses Schemes reduce fluctuations by limiting the gradient between neighbouring cell centers. (found a very good explanation cellMDLimited vs. cellLimited )

so I changed my fvSchemes as follows:

gradSchemes
{
default none;
grad(p) cellLimited leastSquares 0.9;
grad(U) Gauss linear;
grad(rho) cellLimited leastSquares 0.9;
grad(rhoU) cellLimited leastSquares 0.9;
grad((1|psi)) Gauss linear;
grad(e) Gauss linear;
grad(sqrt(((Cp|Cv)*(1|psi)))) Gauss linear;
grad(T) Gauss linear;
grad(omega) Gauss linear;
grad(k) Gauss linear;
}

The reason was, that pressure/density are probably the ones causing trouble.

It now seems (! no long time confirmation) as if the pressure oscillations are diminishing. See pictures below
I would systematically apply the same limiter (I'd suggest cellLimited leastSquares 1 to all the gradients. Notice that the number here has a different effect in comparison to the effect it has in Laplacian and snGrad! 1 does NOT mean you do not limit.)

Best,
__________________
Alberto Passalacqua

GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image.
OpenQBMM - An open-source implementation of quadrature-based moment methods
alberto is offline   Reply With Quote

Old   October 13, 2011, 04:26
Default
  #28
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by alberto View Post
div(tauMC) must be discretized with a central scheme, since it does not introduce directional bias. Direction-biased schemes are appropriate only for convection.

Best,
That is my point too.
vkrastev is offline   Reply With Quote

Old   October 13, 2011, 07:58
Default
  #29
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hey Foamers,
I did as alberto suggested:
gradSchemes
{
default cellLimited leastSquares 1;
{

The result got much better after that as you can see below. But the fluctuations haven't vanished completely.
So I'll now try the Spalart-Almaras model and see what happens then.
Attached Images
File Type: jpg rhoCentralFoam_afterCellLimited_T0_3701.jpg (61.1 KB, 73 views)
schwermetall is offline   Reply With Quote

Old   October 13, 2011, 08:33
Default
  #30
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Just a short add-on from my side: it seems (at least in my internal flow case) that Tadmor's flux scheme is more stable than Kurganov's one (probably because it's slightly more dissipative, at least as I was able to understand from Kurganov and Tadmor's original paper).

Regards

V.
vkrastev is offline   Reply With Quote

Old   October 13, 2011, 10:19
Default
  #31
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi Foamers,
as I'm running the Spalart-Almaras model I get the following warning:

--> FOAM Warning :
From function tmp<volScalarField> SpalartAllmaras::k() const
in file SpalartAllmaras/SpalartAllmaras.C at line 262
Turbulence kinetic energy not defined for Spalart-Allmaras model. Returning zero field

I had a look at the source code, but as my c++ is worse than my Chinese I can really tell what is happening there.
The Spalart-allmaras model doesn't need the kinetic turbulent energy at all. So I don't understand why the model is creating a field k mit zero entries.

Code:
00241 tmp<volScalarField> SpalartAllmaras::k() const
00242 {
00243     WarningIn("tmp<volScalarField> SpalartAllmaras::k() const")
00244         << "Turbulence kinetic energy not defined for Spalart-Allmaras model. "
00245         << "Returning zero field" << endl;
00246 
00247     return tmp<volScalarField>
00248     (
00249         new volScalarField
00250         (
00251             IOobject
00252             (
00253                 "k",
00254                 runTime_.timeName(),
00255                 mesh_
00256             ),
00257             mesh_,
00258             dimensionedScalar("0", dimensionSet(0, 2, -2, 0, 0), 0)
00259         )
00260     );
I would like to understand that. Especially because when I ran the incompressible case, I didn't get that warning. In the incompressible Spalart-Allmaras code there is a similar line than the one shown above.
schwermetall is offline   Reply With Quote

Old   October 13, 2011, 10:41
Default
  #32
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
That piece of code is missing in OF 1.7.1 (which is my reference version), and I really don't understand why is there in OF 2.0.0/1/x ... I think you can ignore the warning message without any consequence for your calculations. Anyway, have you tried the Tadmor scheme instead of the Kurganov one?

Regards

V.
vkrastev is offline   Reply With Quote

Old   October 13, 2011, 12:01
Default
  #33
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi vkrastev
just changed to Tadmor, but it does not seem to change the fluctuations.

As the fluctuations are spacial, I'm thinking the problem might be connected to fvSolution. Maybe I gonna try
Code:
solver          PBiCG;
preconditioner  DILU;
instead of diagonal. What do you think?
schwermetall is offline   Reply With Quote

Old   October 13, 2011, 12:05
Default
  #34
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
No, I don't think you should change the diagonal solver options for rho, rhoU and rhoE, because as far as I have understood a little the rhoCentralFoam algorithm, these quantities are solved explicitly via the Kurganov/Tadmor reconstrucion procedure. What about the Spalart-Allmaras model compared to the kOmega?

V.
vkrastev is offline   Reply With Quote

Old   October 13, 2011, 12:43
Default
  #35
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Hi vkrastev
my actual case is running with spalart-Almaras. As you can see below, the Amplitude of the fluctuations diminished a little bit.

The position of the shock probably becomes better after some time, thats at least what normally happens.

I'm open for new ideas ... thanks a lot
Attached Images
File Type: jpg SpalartAllmarasVSkOmegaSST.jpg (91.9 KB, 72 views)
File Type: jpg SpalartAllmarasVSkOmegaSST_zoom.jpg (91.3 KB, 38 views)
schwermetall is offline   Reply With Quote

Old   October 13, 2011, 12:52
Default
  #36
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by schwermetall View Post
Hi vkrastev
my actual case is running with spalart-Almaras. As you can see below, the Amplitude of the fluctuations diminished a little bit.

The position of the shock probably becomes better after some time, thats at least what normally happens.

I'm open for new ideas ... thanks a lot
I think that you have to let the simulations go ahead until at least the shock position becomes sufficiently stable for both models and then make some comparison. In the end your results appear not bad, and honestly I don't have at the moment other suggestions for smearing out those little oscillations...

Regards

V.
vkrastev is offline   Reply With Quote

Old   October 14, 2011, 10:11
Default
  #37
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
So after waiting for ages I reached a time of 0.186 and you're the oscillations are slowly decaying, as you can see below. So I'm going to wait a little longer.

I got some input from my supervisor and she thinks the problem I have here is a odd even decoupling. I'll have a look at the literature, see what I find out about it and if there's a way to get better results
Attached Images
File Type: jpg Cp_SpalartAllm_T0_186.jpg (92.5 KB, 60 views)
schwermetall is offline   Reply With Quote

Old   October 14, 2011, 10:38
Default
  #38
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by schwermetall View Post
So after waiting for ages I reached a time of 0.186 and you're the oscillations are slowly decaying, as you can see below. So I'm going to wait a little longer.

I got some input from my supervisor and she thinks the problem I have here is a odd even decoupling. I'll have a look at the literature, see what I find out about it and if there's a way to get better results
Do you mean a pressure-velocity decoupling? This could be interesting, but honestly I can't say if it is a reasonable hypothesis...Anyway, if I understand you properly, the pressure-velocity coupling in the rhoCentralFoam solver occurs in the inviscid part of the solution, which is driven by the Tadmor/Kurganov algorithms: so the answer to the question would be inside the nature of such algorithms, which (at least to my actual knowledge of compressible flow solution procedures) are quite a mystery to me, so you'll have to face it all by yourself..Good luck!

V.
vkrastev is offline   Reply With Quote

Old   October 14, 2011, 10:41
Default
  #39
New Member
 
Join Date: Aug 2011
Posts: 28
Rep Power: 5
schwermetall is on a distinguished road
Yes it's about a pressure velocity decoupling.

thanks a lot for all your help until now. I'll let you if I find anything out, but maybe I can unmystify it a little bit ;-)

Have nice weekend.

regards from Munich
schwermetall is offline   Reply With Quote

Old   October 25, 2011, 04:12
Default
  #40
ndr
New Member
 
Join Date: Aug 2009
Location: Stuttgart, Germany
Posts: 20
Rep Power: 7
ndr is on a distinguished road
Hi schwermetall,

I observed something very similar to this when simulating a supersonic channel flow using rhoCentralFoam and kOmegaSST. The wall pressure at top and bottom walls of the channel is fluctuating a lot and it looks a lot like in your profiles. However, temperature and velocity profiles along the channel are fine, so it only seems to be a pressure problem.

I did as you suggested and changed to cellLimited for grad schemes: It helped, but the fluctuations are not completely gone. As I am usually using grids with y+ of around 30 and wall functions I tried to refine the grid. For y+ = 15 and wall functions the instabilities looked weaker. And when I deactivated the wall functions for a fine grid of y+ = 1 also the pressure fluctuations were gone completely. However, the results now seem to suffer quite a lot from numerical dissipation and are considerably less accurate in temperature and velocity profiles.

Did you try to refine your grid at the walls? It would be interesting to see if you can observe the same behaviour of the solver for your NACA case.
ndr is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
mach number and selection of the fluent solver turbinesv FLUENT 4 April 24, 2011 00:14
How to find Mach Number Tobias FLUENT 2 October 18, 2005 09:59
non-dimensional analysis in Fluent Endee FLUENT 8 September 7, 2005 16:16
Inviscid Drag at subsonic, subcritical Mach # Axel Rohde Main CFD Forum 1 November 19, 2001 13:19
Strouhal number of an airfoil Tim Franke Main CFD Forum 0 April 4, 2000 03:10


All times are GMT -4. The time now is 14:10.