[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