
[Sponsors] 
April 28, 2009, 23:05 
CFL number for NavierStokes (Infinite? How large?)

#1 
Member
Join Date: Mar 2009
Posts: 33
Rep Power: 9 
Hello, people with NavierStokes codes, structured or unstructured,
i'm wondering how large the CFL number can be for your NavierStokes codes for steady calculations (or inner iterations within one physical time step). I'm sure you use an implicit scheme, which theoretically alows infinite CFL number, but do you really set CFL=10000000000000 (Wow! You will reach a steady state just in one time step!)? If your CFL is not really that large, I'm interested to know why, and why you still use implicit scheme even without infinite CFL. Thanks! Gory 

April 29, 2009, 04:47 

#2  
Member
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
Quote:


April 29, 2009, 06:48 

#3 
Senior Member
Join Date: Apr 2009
Posts: 118
Rep Power: 9 
HI,
Maybe not directly related to the topic of this thread. But I'm running a NavierStokes code implicitly. I've been told that the physical time step (outer iteration), should be such that it gives a CFL of 1 by taking into account the velocity and mesh size. Indeed, the solution is not physical when the CFL for the physical time steps is larger than 1. What I don't understand is why this should be the case? I thought that when you run implicitly it didn't matter what the time step sizes were. Thanks. 

April 29, 2009, 08:03 

#4  
Member
Jed Brown
Join Date: Mar 2009
Posts: 56
Rep Power: 11 
Quote:
Reasons to prefer an implicit method include


April 29, 2009, 15:00 

#5 
Member
Join Date: Mar 2009
Posts: 33
Rep Power: 9 
Thank you all for your inputs!
>the solution is not physical when the CFL for the physical time steps is larger than 1. Interesting. Maybe, it is not accurate with large CFL (too much dissipation). But if CFL<1, why not using explicit scheme? It is extremely expensive to invert a matrix at each time step,then. > Reasons to prefer an implicit method include I see. So, implicit schemes are not just to take a large time step, but also for gaining robustness (stability) associated, for example, stiff source terms. But then again, I wonder if people really invert a matrix (Jacobian) at each step. If it is not fully solved, then I would understand that CFL cannot be infinite. Thanks! 

April 29, 2009, 15:32 

#6  
Member
Jed Brown
Join Date: Mar 2009
Posts: 56
Rep Power: 11 
Quote:
Quote:
Quote:
The inverse of anything interesting is dense. In addition, "solve a system with" rarely means "factor" for 3D problems because it is too expensive. Instead, a Krylov iteration is used, and everything interesting goes into the preconditioner. For nonlinear problems, it's not just a single linear solve, you have to solve a nonlinear system. If you are time stepping near CFL=1, and don't have especially nasty stiff terms, it is common to converge in one Newton iteration. In addition, it's common that you can reuse the preconditioner from the last time step. So it's not always a huge amount of work (though it is always more work than a function evaluation as in an explicit method). For solving steadystate problems, you will typically want to take time steps as large as possible without impacting your Newton iteration's ability to converge quickly. This method is called pseudotransient continuation and can include a scaling so that the step length is spatially variable. A good paper on the subject is Code:
@article{coffey2003ptc, author = {Todd S. Coffey and C. T. Kelley and David E. Keyes}, collaboration = {}, title = {Pseudotransient Continuation and DifferentialAlgebraic Equations}, publisher = {SIAM}, year = {2003}, journal = {SIAM Journal on Scientific Computing}, volume = {25}, number = {2}, pages = {553569}, keywords = {pseudotransient continuation; nonlinear equations; steadystate solutions; global convergence; differentialalgebraic equations; multirate systems}, url = {http://link.aip.org/link/?SCE/25/553/1}, doi = {10.1137/S106482750241044X} } Code:
@article{knoll2004jfn, title={{Jacobianfree NewtonKrylov methods: a survey of approaches and applications}}, author={Knoll, DA and Keyes, DE}, journal={Journal of Computational Physics}, volume={193}, number={2}, pages={357397}, year={2004}, publisher={Elsevier} } 

April 30, 2009, 19:51 

#7 
Member
Join Date: Mar 2009
Posts: 33
Rep Power: 9 
Jed,
I learned a lot from your comments, and will learn a lot more by reading the papers. Thank you! Gory 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Mesh Refinement  Luiz Eduardo Bittencourt Sampaio (Sampaio)  OpenFOAM Mesh Utilities  42  January 8, 2017 13:55 
DecomposePar unequal number of shared faces  maka  OpenFOAM PreProcessing  6  August 12, 2010 09:01 
BlockMeshmergePatchPairs  hjasak  OpenFOAM Native Meshers: blockMesh  11  August 15, 2008 07:36 
Unaligned accesses on IA64  andre  OpenFOAM  5  June 23, 2008 10:37 
Trimmed cell and embedded refinement mesh conversion issues  michele  OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ...  2  July 15, 2005 04:15 