[ET Trac] [Einstein Toolkit] #1906: CarpetRegrid2: possible off-by-one error when using regrid_every parameter
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Mon Jun 6 11:15:49 CDT 2016
#1906: CarpetRegrid2: possible off-by-one error when using regrid_every parameter
----------------------+-----------------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Resolution: | Keywords: CarpetRegrid2
----------------------+-----------------------------------------------------
Comment (by eschnett):
Yes, your interpretation of my AMR timeline is correct.
Currently, when CallRegrid is called during Evolve, cctk_iteration is
always of the form (i %N ==1), where i is the current iteration, and N is
the "iteration step size" of the current level. For example, if the
coarsest grid is evolved every 4 iterations, then cctk_iteration has the
values {1, 5, 9, 13, ...} when CallRegrid is called. Thus the expression
(cctk_iteration % regrid_every == 0) would never trigger.
I believe that you would find things easier to understand if iterations
were numbered starting at 0. Alas, they are numbered starting at 1. Thus
you can define a new counter cctk_iteration0, can always set it via
cctk_iteration0 = cctk_iteration - 1, and can then use it:
{{{
cctk_iteration0 % regrid_every == 0
}}}
This is correct for regridding.
Note that the second half of the coarse grid step occurs after both fine
grid steps have completed, and thus occurs at a later iteration (sic!).
This was necessary to ensure that cctk_iteration never jumps backwards,
which confused some thorns. This, however, does not concern regridding,
but it does concern output, as output occurs at the end of a time step.
(Regridding occurs in the beginning.)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1906#comment:3>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list