Hello,
I have experienced a curious problem when trying to use
Time::timestep_method = "courant_speed"
with
Cactus::terminate = "time".
What happens is that, after the final time is reached, the timestep becomes negative, afterwards the code quickly crushes (my equations are not time-reversible and I guess that dt >= 0 is also assumed in many other parts of the code)...
The attached patch for the Time thorn fixes the problem, even tough I am not exactly sure on why the commented-out part of the code leads to the problem: it would seem to me that cctkGH->cctk_time should always be less then cctk_final_time when this routine is executed...
Do you have any idea of what is going on?
David
The commented out code ensures that you never move much beyond the final time, reducing the step size if necessary. However, this doesn't quit hit the final time, but moves a tiny bit beyond it. I don't see how this could cause a problem.
Are you using mesh refinement in these simulations? Carpet's time stepping algorithm doesn't support changing the time step size. (It is fine if you use unigrid.) If you do, this may explain your symptoms, because the different time levels on the different refinement levels would become seriously inconsistent.
-erik
On Thu, Mar 3, 2011 at 4:01 AM, David Radice david.radice@aei.mpg.de wrote:
Hello,
I have experienced a curious problem when trying to use
Time::timestep_method = "courant_speed"
with
Cactus::terminate = "time".
What happens is that, after the final time is reached, the timestep becomes negative, afterwards the code quickly crushes (my equations are not time-reversible and I guess that dt >= 0 is also assumed in many other parts of the code)...
The attached patch for the Time thorn fixes the problem, even tough I am not exactly sure on why the commented-out part of the code leads to the problem: it would seem to me that cctkGH->cctk_time should always be less then cctk_final_time when this routine is executed...
Do you have any idea of what is going on?
David
-- David Radice Max Planck Institute for Gravitational Physics Albert Einstein Institute Am Muehlenberg 1 D-14476 Potsdam Germany
Tel : +49 331 567 7242 Fax : +49 331 567 7499 Room : 1.64 E-Mail : david.radice@aei.mpg.de
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Erik,
thanks for the reply.
On Thu, 2011-03-03 at 09:55 -0500, Erik Schnetter wrote:
Are you using mesh refinement in these simulations? Carpet's time stepping algorithm doesn't support changing the time step size. (It is fine if you use unigrid.) If you do, this may explain your symptoms, because the different time levels on the different refinement levels would become seriously inconsistent.
I am using Carpet, but with unigrid. The timestepping is done with MoL, RK3.
This issue disappears either by using a terminate condition based on the number of iterations or by applying that patch. (I checked that courant_wave_speed > 0).
David
I think I see know what is going wrong. The commented-out code works fine the first time, but it overshoots slightly. Carpet then apparently does not exit the simulation for some reason. The next time, the commented out code reverses direction, since it tries to get back to the final time.
I am fine with the patch. Overshooting over the final time is not a bad thing, and is to be expected when one uses variable time steps.
On a side node, I have used RK4 with adaptive time stepping in the past (outside Cactus), and I also naively tried to reduce the time step size to exactly hit certain target times for output. This turned out to cost a lot of performance, since it increased the number of time steps and confused the automatic step size calculations. I have since come to the conclusion that having output (or having simulations finish) at irregular times is acceptable.
Do others want to comment on this?
-erik
On Thu, Mar 3, 2011 at 10:15 AM, David Radice david.radice@aei.mpg.de wrote:
Erik,
thanks for the reply.
On Thu, 2011-03-03 at 09:55 -0500, Erik Schnetter wrote:
Are you using mesh refinement in these simulations? Carpet's time stepping algorithm doesn't support changing the time step size. (It is fine if you use unigrid.) If you do, this may explain your symptoms, because the different time levels on the different refinement levels would become seriously inconsistent.
I am using Carpet, but with unigrid. The timestepping is done with MoL, RK3.
This issue disappears either by using a terminate condition based on the number of iterations or by applying that patch. (I checked that courant_wave_speed > 0).
David
-- David Radice Max Planck Institute for Gravitational Physics Albert Einstein Institute Am Muehlenberg 1 D-14476 Potsdam Germany
Tel : +49 331 567 7242 Fax : +49 331 567 7499 Room : 1.64 E-Mail : david.radice@aei.mpg.de
users@lists.einsteintoolkit.org
-
David Radice -
Erik Schnetter