[schwermetall]

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 ??

[vkrastev]

Originally Posted by schwermetall

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.

[schwermetall]

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.

[vkrastev]

Originally Posted by schwermetall

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).

Originally Posted by schwermetall

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.

Originally Posted by schwermetall

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.

[schwermetall]

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 http://www.cfd-online.com/Forums/ope...lllimited.html )

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

[alberto]

Originally Posted by vkrastev

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]

Originally Posted by schwermetall

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 http://www.cfd-online.com/Forums/ope...lllimited.html )

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,

[vkrastev]

Originally Posted by alberto

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.

[schwermetall]

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.

[vkrastev]

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.

[schwermetall]

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.

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.

[vkrastev]

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.

[schwermetall]

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

solver          PBiCG;
preconditioner  DILU;

instead of diagonal. What do you think?

[vkrastev]

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.

[schwermetall]

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

[vkrastev]

Originally Posted by schwermetall

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.

[schwermetall]

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

[vkrastev]

Originally Posted by schwermetall

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.

[schwermetall]

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

[ndr]

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.