CFL number for Navier-Stokes (Infinite? How large?)

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 April 28, 2009, 23:05 CFL number for Navier-Stokes (Infinite? How large?) #1 Member   Join Date: Mar 2009 Posts: 33 Rep Power: 10 Sponsored Links Hello, people with Navier-Stokes codes, structured or unstructured, i'm wondering how large the CFL number can be for your Navier-Stokes 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: 10
Quote:
 Originally Posted by gory Hello, people with Navier-Stokes codes, structured or unstructured, i'm wondering how large the CFL number can be for your Navier-Stokes 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
There are situations where transients are not all important, where you can accept some loss in temporal accuracy in order to reach a solution faster (or reach a time where the chosen time-step is acceptable). You might also run into the problem of having too small time-steps in your explicit method where the round-off errors pile up.

 April 29, 2009, 06:48 #3 Senior Member   Join Date: Apr 2009 Posts: 118 Rep Power: 10 HI, Maybe not directly related to the topic of this thread. But I'm running a Navier-Stokes 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: 12
Quote:
 Originally Posted by lost.identity HI, 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.
Some implicit schemes are unconditionally stable. Stability is necessary for convergence to the exact solution, but is not sufficient. For convergence, you also need the scheme to be consistent. Your scheme is not consistent when it does not respect CFL, but it may still converge to the correct steady state. In other words, you cannot resolve phase when you don't respect CFL. If resolving phase is important to you, an explicit or semi-implicit method might be less expensive.

Reasons to prefer an implicit method include

• You only care about steady state, not how fast you get there.
• You have a highly refined mesh and the CFL constraint in those elements is limiting. You are willing to not resolve phase in those elements in exchange for much larger stable time steps.
• Your problem has stiff waves, parabolic processes, or elliptic constraints (as in DAE) which are limiting stability, and is coupled strongly enough that semi-implicit methods perform poorly.
• Your problem is strongly nonlinear and the splitting error from explicit or semi-implicit methods is large.

 April 29, 2009, 15:00 #5 Member   Join Date: Mar 2009 Posts: 33 Rep Power: 10 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: 12
Quote:
 Originally Posted by gory 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 often okay to exceed CFL in some parts of the domain. Remember that it is common that some terms need to be treated implicitly regardless (e.g. pressure in incompressible flow, chemistry in reactive flows).

Quote:
 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.
Yes, both stability and accuracy. Note that stiff waves, such as surface gravity waves or the dispersive whistler wave in MHD cause explicit methods to take excessively small steps. Usually these waves are not actually interesting and we certainly don't care to resolve their phase, but they are nonlinearly coupled to the interesting dynamics so they can't just be "removed".

Quote:
 But then again, I wonder if people really invert a matrix (Jacobian) at each step.
First, when people say "invert", they really mean "solve a system with". Actually computing the inverse is silly because it is dense. That can be made more general:

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 steady-state 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 Differential-Algebraic Equations},
publisher = {SIAM},
year = {2003},
journal = {SIAM Journal on Scientific Computing},
volume = {25},
number = {2},
pages = {553-569},
keywords = {pseudotransient continuation; nonlinear equations; steady-state solutions; global convergence; differential-algebraic equations; multirate systems},
doi = {10.1137/S106482750241044X}
}```
With hyperbolic problems when the time step is large, the Jacobian usually becomes diagonally submissive in which case standard preconditioners perform poorly. Usually the Schur complement is well-conditioned and can be interpreted as being associated with a parabolic equation. Discretizing this parabolic equation, and using it to solve with an approximate block factorization of the original Jacobian, produces a very effective solver. This is called physics-based preconditioning, a good survey is

Code:
```@article{knoll2004jfn,
title={{Jacobian-free Newton--Krylov methods: a survey of approaches and applications}},
author={Knoll, DA and Keyes, DE},
journal={Journal of Computational Physics},
volume={193},
number={2},
pages={357--397},
year={2004},
publisher={Elsevier}
}```

 April 30, 2009, 19:51 #7 Member   Join Date: Mar 2009 Posts: 33 Rep Power: 10 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 Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Luiz Eduardo Bittencourt Sampaio (Sampaio) OpenFOAM Mesh Utilities 42 January 8, 2017 13:55 maka OpenFOAM Pre-Processing 6 August 12, 2010 09:01 hjasak OpenFOAM Native Meshers: blockMesh 11 August 15, 2008 07:36 andre OpenFOAM 5 June 23, 2008 10:37 michele OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 July 15, 2005 04:15