Dealing with a Bad CFL

Symptom:

In the middle of a run, AstroBEAR throws the message "Horribly bad CFL. Die." and quits.

Problem:

The ​Courant, Friedrichs, Levy number specified in bear.data under the item cflv(2) controls acceptable speed of propagation of information in the simulation. When variable-timestepping is allowed (which it is normally), the ​CFL number sets an upper-limit on the timestep that the code is allowed to take. Typically the ​CFL ranges between 0.3 and 0.5. Under no circumstances, however, should the ​CFL number ever be greater than 1.0 (this is built into bear.data as cflv(1), the maximum allowable ​CFL number.

The initial timestep is set in bear.data under dtv(1). Occasionally, this initial timestep will be such that the code may mistakenly assume a much-too-large timestep for the subsequent step, resulting in ​CFL numbers that may range from 1 to 1012 or greater. Since the maximum allowable ​CFL number, cflv(1) is 1, this may cause the simulation to stop at the very beginning of a run.

Solution:

There are two potential quick-and-dirty solutions to this problem: Changing cflv(2) or changing dtv(1). Remember that a smaller ​CFL forces a smaller timestep, which keeps the simulation from blowing up, but it does so at the cost of longer run-times.

Increasing or decreasing the initial timestep dtv(1) by a factor of 10 or 100 will in many cases fix this problem. If it does not, it's possible that the relationship between the initial timestep and the length of the simulation in computational time units or the physical time are disparate and need to be checked. If these relationships are acceptable, then there probably is a problem with how the environment is being initialized.