CFD Online Discussion Forums

CFD Online Discussion Forums (
-   FLUENT (
-   -   Another convergence problem (

willis08 September 3, 2011 05:12

Another convergence problem
Hello Everyone

I am trying to model an open wheeled vehicle in steady state, but the model fails to converge with increased mesh refinement; I am monitoring total lift and drag – my convergence criterion is ∆%<1 over 100 iterations. I am using k-epsilon and default settings elsewhere. The mesh is unstructured and does not contain prism layers. Fluent and ICEM are used for solving and meshing respectively.

I read the link below which says the convergence problems might be due to vortex shedding and that with increased resolution, instability in the solution can occur. The author is discussing convergence problems when CFX is used, and mentions a time-scale factor. I don’t know if this is a unique function to CFX or a feature for time dependent simulations, as I cannot find anything in the Fluent help manual regarding time-scale factors with regard to steady-state simulations.
I also monitored the forces on individual components to see if there was a particular area that was not converging but the forces of most components fluctuated.
Any tips or guidance would be greatly appreciated.

delaneyluke September 7, 2011 07:21

Hi Simon,
CFX is a fully coupled solver and hence only has a timescale factor to control the advancement from iteration to iteration. FLUENT uses pressure-velocity coupling algorithms and hence has relaxation factors to control its advancement from iteration to iteration.
So, to control convergence in FLUENT, reduce your relaxation parameters.

willis08 September 7, 2011 13:26

Cheers Luke, thanks for the reply and clearing up my confusion. I'll try reducing the relaxation factors.

To give an update, I was originally solving with 2nd order discretization schemes but changed to 1st order and have just changed back to 2nd order; convergence has improved but is still not ideal. I’ll try reducing the URF’s, but I thought this would only limit the amount the respective variables can change each iteration; so reducing the URF’s wouldn’t really improve convergence just prevent divergence. By the way, I neglected to mention my convergence has a sinusoidal behaviour, so if there is a way to reduce the ‘amplitude’, if you know what i mean, I’d love to here your suggestions.

stuart23 September 7, 2011 23:29

Hi Simon

Fluent uses a nondimensionalized form the timestep to specify temporal discretionalisation. This number is the Courant Number or CFL and is calculated as u.dt/dx <= CFL. The solver will therefore apply the CFL condition to the maximum velocity/cell size in your model and use this timestep.

Specifying the CFL has the advantage that it is a nondimensional quantity, so you can use apply the same condition to similar cases. The CFL is also useful in that it takes into account your mesh resolution, and so the same number can be applied to cases with dissimilar mesh densities.

Raming the CFL is a good way to speed up convergence. Start low for 10~50 iterations, then increase the CFL every 10~50 iterations. It takes a bit of experimenting to find out how "hard" you can push the solver, but you will be able to get much quicker convergence (and divergence!) using this method.

Good Luck,

willis08 September 8, 2011 02:39

Cheers for the reply Stu! So the Courant number is an option within the density-based solver, right? But is it acceptable to use this solver for my simulation, which I imagine would not contain compressible flows; as this is what FLUENT's help file states the density based solver was designed for. Or have these methods been developed such that it doesn't really matter which solver you use?

willis08 September 11, 2011 14:56

So I tried reducing the URF's which reduced the period of the oscillations but didn't converge. I also tried switching to the density based solver and played around with the CFL when modelling transient and steady state, but the residuals became a bit upset with the change and started fluctuating in both cases. I could have been using rubbish settings because I’m not familiar with using the density based solver or transient modelling but I had a quick read before hand so hopefully I wasn't too far off. I don't have any other ideas at the moment so I'm all open to suggestions.


stuart23 September 11, 2011 19:13


Sorry I didn't reply earlier.
The Courant Number is an option in the Coupled Pressure Based Solver. I think this is the best solver for what your doing. Use the pressure solver, than change the p-v coupling to "Coupled". I would start with a CFL of ~ 25 - 30 then step it up every 50-100 iterations.

Good Luck


willis08 September 12, 2011 08:38

I changed the p-v coupling on my model to Coupled and progressively increased the Courant number up to 50000, which i thought was quite a lot, but the coefficient of lift still oscillates between -14.5 & -16. The time to convergence was improved but the accuracy didn't change. What could be the cause of this instability in the solution?


eishinsnsayshin September 13, 2011 13:28

Hey I've run into this problem before too and maybe it's for the same reason.

I run lots of car models in Fluent using mesh created in Ansa with Tgrid mesh for the volume but you probably don't care about that...

Try changing the Gradient under "Solution Methods" to Green-Gauss Node Based (if before you were using least squares which is default). It's my understanding that least squares is not too great for complex meshes.

It's sounds like a simple change but it was the difference for me!

Another suggestion is to eventually use prisms if you are able. This shouldn't make a difference with your current convergence problem, but it can make a difference when it comes to looking at your results for lift/drag later...especially drag.

You want to mess around with the prism heights such that when you check y-plus, the values are from 30-300 close to 30 as you can but no lower. Do not use enhanced wall treatment unless you are able to make mesh fine enough that your y-plus will be like 1-5.

Hope this helps!

willis08 September 16, 2011 22:51

Cheers eishinsnsayshin

I'm already using the Green-Gauss Node Based scheme, so I tried your other suggestion even though you mentioned it wouldn't make much difference to my convergence problem. I used two prism layers, which seemed to improve convergence for the model with the least number of elements; although, lift and drag did not change by much, which could be considered a little odd. I'll see if the addition of a few prism layers improves convergence on a model with more elements.


johnwinter September 17, 2011 07:31

Hi all,

This thread is interesting to me as I have a similar situation in my probelm. I am carrying out steady state simulation in a room with heat source inisde. The stange thing is my flow is not steady, it is varying with as iteration progresses. i have tried both SIMPLE and COUPLED solver for my problem, in both cases the same situation.

My solution is not converging, it is just orscillating at continuity at 4e-3 and momentum at 4e-4 after reducing URFs.

Any suggestions are welcome.

Nikolopoulos September 19, 2011 03:13

Maybe your problem has no steady state solution.
If the physics are unsteady then you should use an unsteady solver.
Have you checked what happens when you apply an unsteady solver?


johnwinter September 21, 2011 05:00

Hi Nikolopoulos,

Thanks for your reply.
Yes, i have checked unsteady state. Similar situation appeared in unsteady state simulation. It is reaching steady after 100 sec, after that the solution is oscillating.


Nikolopoulos September 21, 2011 08:21

In my opinion, this means that the physics of your flow is unsteady!

You should perform sampling and obtain representative mean values.

johnwinter November 7, 2011 00:51

Hi Nikolopoulos,

Thanks for your suggestion, i try doing that.


Jonathan November 17, 2011 06:09

simple really - if you have a correctly set up simulation which in your opinion is modelling the physics correctly (ie no BC errors, incorrect flow assumptions ie compressibility etc), and you still have periodic oscillations in the residuals, it means you flow is in fact time-dependent and therefore the solver is (despite the fact that you are trying to model it as steady) resolving the time-dependent features of the flow - most likely a shed vortex.

increasing spatial discretization / refining the mesh etc etc, will actually exacerbate the 'problem' ie the solver will just do a better job of picking up the transient features. switching to first order discretization will 'help', in that you add more numerical dissapation to your model, and so dampen out your vortex (by adding "viscosity") to your model, the reality is that you are damping out a real flow feature ...

re: Courant number etc - as a couple people have said, segregated solvers use URF's, coupled (density and pressure based) will use time-stepping, as embodied by the Courant no. I have not used CFX much, but having been originally designed as a turbomachinery code and therefore basically for compressible flows, it will probably use a coupled, density based solver and therefore the need a time-step / Co no. input. Fluent being a multipurpose code has both options, which is pretty handy ...

if your problem is basically incompressible, the segregated pressure based solver is often easier to get to converge without blowing up ...


sorry - the only other issue you should check, is, since you are not using a low Re mesh (ie prism cells), and therefore are using wall functions, check your y+ value is in the right range to make wall functions valid. as i'm sure you know, although BL's are small physically, they can make a large effect on the bulk flow (ie if they separate, think sphere etc), and esp viscosity based coefficients such as viscous drag etc

All times are GMT -4. The time now is 18:02.