
[Sponsors] 
September 3, 2011, 06:12 
Another convergence problem

#1 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
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 kepsilon 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 timescale 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 timescale factors with regard to steadystate simulations. http://www.cfdonline.com/Wiki/Ansys_FAQ 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. Regards, Simon 

September 7, 2011, 08:21 

#2 
Senior Member
Join Date: Mar 2009
Location: Indiana, US
Posts: 185
Rep Power: 7 
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 pressurevelocity 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. Regards Luke 

September 7, 2011, 14:26 

#3 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
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. Cheers, Simon 

September 8, 2011, 00:29 

#4 
Senior Member
Stuart Buckingham
Join Date: May 2010
Location: United Kingdom
Posts: 267
Rep Power: 15 
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, Stu 

September 8, 2011, 03:39 

#5 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
Cheers for the reply Stu! So the Courant number is an option within the densitybased 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?


September 11, 2011, 15:56 

#6 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
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.
Cheers, Simon 

September 11, 2011, 20:13 

#7 
Senior Member
Stuart Buckingham
Join Date: May 2010
Location: United Kingdom
Posts: 267
Rep Power: 15 
Simon,
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 pv coupling to "Coupled". I would start with a CFL of ~ 25  30 then step it up every 50100 iterations. Good Luck Stu 

September 12, 2011, 09:38 

#8 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
I changed the pv 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?
Ta, Simon 

September 13, 2011, 14:28 

#9 
Member
Join Date: Jun 2011
Posts: 48
Rep Power: 5 
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 GreenGauss 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 yplus, the values are from 30300 ...as 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 yplus will be like 15. Hope this helps! 

September 16, 2011, 23:51 

#10 
New Member
Simon Williams
Join Date: Sep 2011
Posts: 6
Rep Power: 5 
Cheers eishinsnsayshin
I'm already using the GreenGauss 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. Thanks, Simon 

September 17, 2011, 08:31 

#11 
Member
john
Join Date: Nov 2010
Posts: 50
Rep Power: 6 
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 4e3 and momentum at 4e4 after reducing URFs. Any suggestions are welcome. 

September 19, 2011, 04:13 

#12 
Member
Nikolopoulos Aristeidis
Join Date: Jan 2011
Location: Athens, Greece
Posts: 62
Rep Power: 5 
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? aris 

September 21, 2011, 06:00 

#13 
Member
john
Join Date: Nov 2010
Posts: 50
Rep Power: 6 
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. John 

September 21, 2011, 09:21 

#14 
Member
Nikolopoulos Aristeidis
Join Date: Jan 2011
Location: Athens, Greece
Posts: 62
Rep Power: 5 
In my opinion, this means that the physics of your flow is unsteady!
You should perform sampling and obtain representative mean values. 

November 7, 2011, 00:51 

#15 
Member
john
Join Date: Nov 2010
Posts: 50
Rep Power: 6 
Hi Nikolopoulos,
Thanks for your suggestion, i try doing that. John 

November 17, 2011, 06:09 

#16 
Senior Member
Join Date: Mar 2010
Location: Cape Town, SA
Posts: 141
Rep Power: 7 
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 timedependent and therefore the solver is (despite the fact that you are trying to model it as steady) resolving the timedependent 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 timestepping, 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 timestep / 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 ... cheers jon 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 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
convergence problem when use pisoFoam, LES for wind tunnel case  Forrest_Lei  OpenFOAM  3  July 19, 2011 07:00 
convergence problem  commonyue  Main CFD Forum  1  December 1, 2009 04:54 
Convergence of CFX field in FSI analysis  nasdak  CFX  2  June 29, 2009 02:17 
3D Fluid Flow Convergence problem  Emily  FLUENT  2  March 22, 2007 00:18 
Non Convergence of 3D Heat transfer cfd problem  Balraj  Main CFD Forum  3  December 9, 2004 01:24 