CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > General Forums > Main CFD Forum

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

Register Blogs Community New Posts Updated Threads Search

Like Tree2Likes
  • 1 Post By jed
  • 1 Post By jed

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 29, 2009, 00:05
Smile CFL number for Navier-Stokes (Infinite? How large?)
  #1
Member
 
Join Date: Mar 2009
Posts: 32
Rep Power: 17
gory is on a distinguished road
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
gory is offline   Reply With Quote

Old   April 29, 2009, 05:47
Default
  #2
Senior Member
 
Ford Prefect's Avatar
 
Join Date: Mar 2009
Posts: 157
Rep Power: 17
Ford Prefect is on a distinguished road
Quote:
Originally Posted by gory View Post
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.
Ford Prefect is offline   Reply With Quote

Old   April 29, 2009, 07:48
Default
  #3
Senior Member
 
Join Date: Apr 2009
Posts: 118
Rep Power: 17
lost.identity is on a distinguished road
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.
lost.identity is offline   Reply With Quote

Old   April 29, 2009, 09:03
Default
  #4
jed
Member
 
Jed Brown
Join Date: Mar 2009
Posts: 56
Rep Power: 19
jed is on a distinguished road
Quote:
Originally Posted by lost.identity View Post
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.
Ramzy1990 likes this.
jed is offline   Reply With Quote

Old   April 29, 2009, 16:00
Default
  #5
Member
 
Join Date: Mar 2009
Posts: 32
Rep Power: 17
gory is on a distinguished road
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!
gory is offline   Reply With Quote

Old   April 29, 2009, 16:32
Default
  #6
jed
Member
 
Jed Brown
Join Date: Mar 2009
Posts: 56
Rep Power: 19
jed is on a distinguished road
Quote:
Originally Posted by gory View Post
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},
  url = {http://link.aip.org/link/?SCE/25/553/1},
  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}
}
Ramzy1990 likes this.
jed is offline   Reply With Quote

Old   April 30, 2009, 20:51
Default
  #7
Member
 
Join Date: Mar 2009
Posts: 32
Rep Power: 17
gory is on a distinguished road
Jed,
I learned a lot from your comments,
and will learn a lot more by reading the papers.
Thank you!
Gory
gory is offline   Reply With Quote

Reply


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 Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[mesh manipulation] Mesh Refinement Luiz Eduardo Bittencourt Sampaio (Sampaio) OpenFOAM Meshing & Mesh Conversion 42 January 8, 2017 13:55
DecomposePar unequal number of shared faces maka OpenFOAM Pre-Processing 6 August 12, 2010 10:01
[blockMesh] BlockMeshmergePatchPairs hjasak OpenFOAM Meshing & Mesh Conversion 11 August 15, 2008 08:36
Unaligned accesses on IA64 andre OpenFOAM 5 June 23, 2008 11:37
[Commercial meshers] Trimmed cell and embedded refinement mesh conversion issues michele OpenFOAM Meshing & Mesh Conversion 2 July 15, 2005 05:15


All times are GMT -4. The time now is 04:46.