- removed comment
delta_time when setting up ID with explicit time dependence
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)
-
-
- changed milestone to ET_2011_05
- removed comment
-
- removed comment
Erik: do you think we should change that before the ET release?
-
- removed comment
At the moment there is no patch, and this is a potentially invasive change. I advise against.
-
- removed version
- changed milestone to ET_2011_11
- removed comment
-
- removed milestone
- removed comment
The same argument holds this time - removing milestone.
-
- removed comment
- 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.
-
- 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."
-
- removed comment
I see. I had not realized that. Thank you. Does this mean this ticket can be closed?
-
- 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.
-
- removed comment
ping
-
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.
-
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?
-
reporter - removed comment
Attaching an AMR version of the previous, to show that delta_time is now also correct on all refinement levels.
-
- changed status to open
- removed comment
Thanks! Please apply.
-
- changed status to open
- removed comment
-
- changed status to resolved
- removed comment
Added test cases.
-
reporter - changed version to development version
- changed status to open
- changed milestone to ET_2012_11
- removed comment
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.
-
- changed status to resolved
- removed comment
Applied.
-
- edited description
- changed status to closed
- Log in to 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.