delta_time when setting up ID with explicit time dependence

Issue #361 closed
Eloisa Bentivegna created an issue

In CallInitial, delta_time is used to calculate the time corresponding to the different timelevels (line 399 of Carpet/src/Initialise.cc). At this stage, though, delta_time is always equal to 1, leading to potentially very separated initial-data slices when using init_each_timelevel and an initial-data thorn that uses cctk_time explicitly. Should cctkGH->cctk_delta_time be used here instead?

Keyword:

Comments (20)

  1. Erik Schnetter
    • removed comment

    Yes, this needs to use cctk_delta_time and not delta_time.

    Line 326 in Evolve.cc contains similar code that also loops over time levels for the postregrid bin:

    cctkGH->cctk_time -= num_tl * (cctkGH->cctk_delta_time / cctkGH->cctk_timefac);

    This could serve as example.

  2. Erik Schnetter
    • removed comment

    At the moment there is no patch, and this is a potentially invasive change. I advise against.

  3. Roland Haas
    • removed comment
    1. 1098 touched on this since it affected the time stored on levels, but did not change delta_time. It seems as if one has to copy the

    for (int ml = 0; ml < mglevels; ++ ml) { assert (leveltimes.AT(ml).size() == 1); leveltimes.AT(ml).AT(0) = global_time; for (int rl = 0; rl < reflevels; ++ rl) { CCTK_REAL const dt = delta_time / timereffacts.AT(rl); for (int tl = 0; tl < tt->timelevels; ++ tl) { tt->set_time (ml, rl, tl, global_time - tl * dt); } } } from line 77 in Initialise also after BASEGRID is executed at line 238 of the same file. This is because Time schedules its functions in BaseGrid.

  4. Erik Schnetter
    • removed comment

    The effects of thorns Time and CartGrid3D which modify the delta_time and delta_space variables are taken into account in the function CallScheduledFunction. There is a comment that begins with "Manage the time step size."

  5. Roland Haas
    • removed comment

    I see. I had not realized that. Thank you. Does this mean this ticket can be closed?

  6. Erik Schnetter
    • removed comment

    We need a test case to ensure things work properly before we can close this. The test case should probably store cctk_time and cctk_delta_time in grid functions, and output these.

  7. Eloisa Bentivegna reporter
    • removed comment

    How about a test case using an existing initial-data thorn, and outputting all timelevels of a time-dependent exact solution? I'm producing a parameter file right now.

  8. Eloisa Bentivegna reporter
    • removed comment

    Here is a slightly tweaked version of the Kasner parfile that made it to the ET paper. Running it with the current trunk ET gives correct values, for instance, for the metric components. Is this a good test?

  9. Eloisa Bentivegna reporter
    • removed comment

    Attaching an AMR version of the previous, to show that delta_time is now also correct on all refinement levels.

  10. Eloisa Bentivegna reporter

    The added testsuites do not pass on one core, since the data in the repository was obtained on two cores and reflects the corresponding domain decomposition. Please append the lines:

    TEST kasner
    {
      NPROCS 2
    }
    
    TEST kasner_amr
    {
      NPROCS 2
    }
    

    to Carpet/Carpet/test/test.ccl.

  11. Log in to comment