We all know about stability conditions for explicit schemes, etc... I understand CFL in this case...

But why in implicit schemes using CD (for LES, for instance), we need to keep CFL number low in order to avoid checkered board problems?

(At least so I heard, correct me if I am wrong...)

Is there anything else related to CFL that is not commonly covered in text books?

Thanks

Stability does not imply accuracy, even though you can use large time step by implicity schemes, the result may not be accurate.

Another consideration, even though the scheme is implicity, time step depends on how you solve the resulting scheme.

Forgetting about accuracy, is there any reason why high courant numbers tends to be "unstable" even with implicit schemes?

May I speculate? Well I will anyway.

Generally, for large problems, implicit codes must be solved iteratively (SOR, Alternating direction schemes, multi-grid, approximate factorization are a few of the techniques). And a lot of iterative schemes are really based on linear systems of equations - the nonlinear terms are somehow linearized or just thrown into the right-hand side of the equation system being solved. As the time step (CFL number) grows larger, the non-linearities grow in (of course) a non-linear fashion. What works for CFL small (that is, near 1) just doesn't work for large values. The size of the non-linearities just overwhelms the assumption of linear behavior.

I've seen this happen but have no theorems to prove when it might bite you. Maybe some other folks will share their experience?

The CFL condition is a heuristic construct that attempts to tell the user the maximum time step that he/she can take without overstepping the linear stability domain of the integrator. Here are some assorted thoughts.

1) Many implicit methods are not A-stable. Most are not L-stable. If you want good stability, use methods that are L-stable. This means things like the multistep BDF methods or the multistage ESDIRK methods. Remember that even if you are stable, you have an order property which says that the global error of the temporal discretization is proportional to the time step raised to some number like 1,2,3, or 4. How many people reading this use a code that provides the user with a temporal error estimate??

2) Just because stability suggests that you can take monstrous time steps doesn't mean you can. There is an issue of "solvability" of the nonlinear equations. This is related to the magnitude of a one-sided Lipschitz constant for your equations. I have never seen anyone use this to predict the maximum step size that guarantees a unique solution to the nonlinear equations. In principal, this would dictate the upper bound on the step size. These systems get more and more squirrelly as the error tolerance gets worse and worse. Also, the iterative tolerance needs to be set to between 10 and 100 times as tight as the integration error tolerance. This is called the tolerance ratio. How many people reading this have a code that ensures that the iterative process satifies the need for a tolerance ratio of 10 or more??

http://www.springerlink.com/app/home...ationresults,1:101751,1

3) The checkerboard problem is simply insufficient spatial dissipation at high wavenumbers.

4) Put an error controller on your calculations. Many users are likely to find that they are attempting to integrate with insanely large temporal errors. Nothing works as advertised when the error becomes huge.

5) There's an interesting paper on how to synchronize the integrator with the iterative solver in cases where you are using a direct solver (not CFD)

http://epubs.siam.org/sam-bin/getfil...cles/28710.pdf