Hi, Vesselin, are you modelling the Ahmed body? If this were the case or in other aerodynamics cases boundary layer modelation and pressure recovery in the back of the bodies is crucial, surely you know about that. I comment this relative to the value of y+ and the mesh pics, it's necessary to fulfill the requirements of being in the log layer, with a value of y+ ~ 30 if it is possible. This implies to change the size of near wall elements along the wall.
But, in the meanwhile, good luck with the div schemes.

Regards.

Yes, I'm modeling the Ahmed body, starting with the simplest case (symmetrical domain, steady state run, body without stilts, 25° slant angle case). You're right about the mesh dimension near the solid body: I know that it should be slightly refined, in fact when I talk about "satisfactory quality" I'm referring mainly to convergence, numerical stability and physical "acceptability" of the solution. When I'll finish with this preliminary testing phase, for sure I will follow your advice and refine the grid near the walls.
Thanks for your comment

Regards

V.

Yes, sometimes it requires to refine the mesh, but in other parts mesh must be coarsened in order not to have finer nor coarser meshes. In other words y+ mustn't be in laminar sublayer zone nor outer region.


Regards.

Hi, Vesselin,


your intention for the next steps sounds good to me. I hope you'll be successful that way!
And please excuse me if I wasn't perfectly clear regarding the mesh. I was aware of the checkmesh-results and didn't think your mesh is not suitable or something like that, the results are indeed very good and there won't be any problems because of skewness or non-orthogonality, I think. And judging by the pictures you attached everything looks very fine to me.
What I actually meant was that one of the (mesh-wise) critical regions for a blunt body like that might be the wake behind the body. Especially the turbulent kinetic energy can have large gradients in such regions which might require more cells in said region. Remember: higher-order schemes are much more sensitive to cell size (amongst other things), which may cause the instabilities, if the mesh is to coarse in regions of high gradients. But this is just guesswork and it may be helpful to have a look at the contour plots of k and epsilon from the simulations with lower order discretization to get an idea, where it may be neccessary to refine the mesh. It could be an issue, but it doesn't have to be - like you said: your mesh is pretty good already.

Regarding the QUICK scheme: I just had a quick peep into the source files but I didn't came to a proper conclusion, I need to have a deeper look, but I'm too tired right now, sorry.
But there's a clue inside the description:

It could be the downwind contribution which might cause the instabilities, but I can't really tell right now. Maybe this gives you an idea?


Greetings,
Felix.

Hi Felix,
don't worry about the mesh: I posted a more detailed description and the images only for giving you and the other forum readers a better idea of how the mesh itself was built...after this "numerical trial" phase I'll start to compare the results also from a quantitative and physical point of view (there is a very large numerical and experimental literature about the Ahmed body) and I'm quite sure that further mesh refinement and assestment will be needed....
About the QUICK scheme: to my actual knowledge, I can't tell if this kind of downwind contribution could be an instability source...this matter need further investigation, so indeed I also have to go depper in the code (and to enlarge my theorical background)...Hope we'll reach soon some agreement about it
About my tests with the underrelaxation factors: I think that in a few days I will be able to post some results, so wait for me...

Regards

V.

Hi all,

I'm sorry I'm a little late...here there are some results of my numerical tests on the convection scheme for the turbulent quantities. As I said before, assuming that k and epsilon are much more sensitive to the convection scheme type than the velocity field, I've tried to "impose" a higher order scheme for the turbulent quantities by "playing" with the under-relaxation factors. My considerations about this matter are the following:

-Having in mind that my tests are focused (for now) only on the realizable k-epsilon model running in steady-state configuration (simpleFoam solver) and mainly on the Gamma differencing scheme, trying to "force" the convergence of the turbulent quantities (once a higher order scheme for convection, such as the Gamma one, is imposed) by lowering a lot the under-relaxation factors seems to be not a good idea...First of all, as you can see from the attachments, the convergence patterns are not satisfactory because the residuals of k and epsilon tend to remain quite unstable and the residuals of the other quantities remain too high (compared with my previous runs). Secondly, the results are also definetly not physical (the tke distribution in the wake of the body as well as the velocity fields are far from what one should expect by considering previous experimental and numerical works on the Ahmed model).

-Of course, my testing campaign is incomplete (unfortunately I have not so much time neither computational facilities), because I've not covered all the range of combinations between the under-relaxation factors and differencing schemes and I've kept the mesh and the eddy viscosity turbulence model as "fixed parameters", but maybe one can deduce a kind of "trend" in the turbulent quantities behaviour for similar cases and meshes.

About the images: three of them are referred to relaxation factor values identical for k and epsilon (0.1, 0.3, 0.5), the fourth is a combination of two different values (0.1 for epsilon, 0.5 for k). In all of the trials, relaxation factors for U and p are kept as their "standard" values for the SIMPLE algorithm (0.3 for p, 0.7 for U)

V.

Hi all, I'm back again...
It seems that OpenFOAM (at least the 1.6 version) is really, really, sensitive to the convection schemes when someone tries to use a tetrahedron-based unstructured 3D mesh...If you have a look to all the posts above, at least I came to the conclusion that a good compromise between accuracy and convergence of the (steady) solution should be a NVD/TVD scheme for the velocities (such as GammaV 1 or limitedLinearV 1) and the good old first order upwind scheme for the turbulent quantities (k and epsilon in my case)...well, I was wrong, because when I use a practically identical mesh, but with very small differences in the cell distribution (for example, the first cell height of the prism-shaped boundary layer is 1.5 mm instead of 2 mm), the same settings in the fvSchemes tend to diverge slowly, until the solution blows up...So, after, all, I'm still asking for some advice if I'm doing something wrong with the overall settings...In particular I want to know:

1) If with such settings the very instable behaviour of the code (simpleFoam solver) is, by your experience, quite "normal"...
2) Can I change something apart from the divSchemes which could improve the stability of the solution?
3) Now I'm starting to do some tests with the linerUpwind scheme for the velocity: can someone give me some more information abput this scheme? I've searched in the forum and had a look in the user's Guide, but still I cannot understand properly how this scheme is formulated...Am I wrong in saying that it's a second order upwind scheme?

Down below there are my fvSchemes and fvSolution dictionaries. For the BC's you can have a look on the previous posts

Thank you very much

V.

fvSchemes:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default Gauss linear;
grad(p) Gauss linear;
grad(U) Gauss linear;
}

divSchemes
{
default none;
div(phi,U) Gauss GammaV 1;
div(phi,k) Gauss upwind;
div(phi,epsilon) Gauss upwind;
div(R) Gauss linear;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}

laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
laplacian(DkEff,k) Gauss linear corrected;
laplacian(DepsilonEff,epsilon) Gauss linear corrected;
}

interpolationSchemes
{
default linear;
interpolate(U) linear;
}

snGradSchemes
{
default corrected;
}

fluxRequired
{
default no;
p ;
}


// ************************************************** *********************** //

fvSolution:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
p
{
solver PCG;
preconditioner DIC;
tolerance 1e-06;
relTol 0.01;
}

U
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-05;
relTol 0.1;
}

k
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-05;
relTol 0.1;
}

epsilon
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-05;
relTol 0.1;
}


}

SIMPLE
{
nNonOrthogonalCorrectors 3;
}

relaxationFactors
{
p 0.3;
U 0.7;
k 0.7;
epsilon 0.7;
}


// ************************************************** *********************** //

Vesselin,

I am really glad that you and felix had this discussion here. I am also going through a similar phase with my research in modeling tip vortices.

One thing which I noticed with the divSchemes ( as you guys have already pointed out ) is that , the turbulence parameters are very sensitive to the scheme. I am using openfoam 2.0.1 and I get converged results ( less than 10^-5) when I used Gauss linearUpwind. Any other higher order turbulence model for all of the divergence terms resulted in a blowing up of the solution.

Changing the scheme just for the velocity term to a higher order ( QUICK, QUICKV) atleast keeps the run going but the residuals never converge to decent values( hanging around 10^-3).

From all this, I tend to feel that the not just the div schemes but may be any other schemes(especially the interpolation schemes) might have an effect on the stability and the convergence of the solution. May be people who have had experience can explain better.

Kalyan

I am also facing the problem of nonconvergence .Can you give me some advice.The case files are here:http://www.cfd-online.com/Forums/ope...t351846.Thanks in advance.

As far as i remember, QUICK requires hexa mesh, didnt it? This experience is from Fluent, but it would explain behaviour of your QUICK residuals :)