<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 11/19/2025 8:24 AM, Erik Schnetter
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:C98218AB-873C-4B74-8378-91B0BBAAAAD1@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Miguel
      <div><br>
      </div>
      <div>If I recall correctly, Ian Hinder studied convergence of
        black hole simulations with subcycling in time in great detail.
        The Einstein Toolkit gallery example for GW150914 contains the
        respective distilled knowledge. <a
          href="https://einsteintoolkit.org/gallery/bbh/index.html"
          moz-do-not-send="true" class="moz-txt-link-freetext">https://einsteintoolkit.org/gallery/bbh/index.html</a></div>
      <div><br>
      </div>
      <div>Some important details that I recall:</div>
      <div>- You can regrid only when the fine and coarse grids are
        aligned</div>
      <div>- You cannot use time interpolation at all. You need to use
        enough buffer zones for all the RK substeps for all the fine
        timesteps for each coarse time step. With 3 ghost zones and RK4
        you need 21 buffer zones.</div>
    </blockquote>
    <p>Does no time interpolation mean no dense output? That didn't
      exist when Ian did these tests, right?</p>
    <p>--Steve</p>
    <blockquote type="cite"
      cite="mid:C98218AB-873C-4B74-8378-91B0BBAAAAD1@gmail.com">
      <div><br>
      </div>
      <div>You likely do not need to evolve for a long time to see loss
        of convergence. It might suffice to run for just a few time
        steps (a few coarse grid steps) and study convergence of one of
        the evolved variables (e.g. the lapse) in great detail over a
        wide range of resolutions. For this you do not need a large
        domain, nor do you need many refinement levels, nor do you need
        many grid points. For example, studying convergence near the
        point (1,0,0) requires probably about 100^3 points for each
        resolution in a two-level setup.</div>
      <div><br>
      </div>
      <div>-erik</div>
      <div>
        <div><br>
          <blockquote type="cite">
            <div>On Nov 19, 2025, at 06:17, Miguel Zilhão
              <a class="moz-txt-link-rfc2396E" href="mailto:mzilhao@ua.pt"><mzilhao@ua.pt></a> wrote:</div>
            <br class="Apple-interchange-newline">
            <div>
              <div>hi all,<br>
                <br>
                we've recently added the option to compute the Gauss
                constraint in the ProcaEvolve thorn
(<a class="moz-txt-link-freetext" href="https://bitbucket.org/canuda/proca/src/experimental_miguel/ProcaEvolve/">https://bitbucket.org/canuda/proca/src/experimental_miguel/ProcaEvolve/</a>)
                and we were surprised to see that, even for very small
                evolutions of a simple (unperturbed) charged black hole,
                this constraint violation does not converge. of course
                everything is converging just fine at t=0, but once the
                evolution starts, convergence is lost really quickly.<br>
                <br>
                after experimenting with different things, i think i've
                narrowed the issue down to the subcycling in time. i've
                attached some plots as well as the corresponding
                parameter files. these plots are not convergence tests,
                it's just what i'm observing with and without subcycling
                in time (everything else is the same as you can see from
                the parfiles).<br>
                <br>
                these are evolutions for a single charged BH, with
                Q=0.2.<br>
                in one of the parfiles
                (LeanBSSN_RN_Q0.2_nosubcycl_hf40_202509.par) all
                timelevels update at the same rate with<br>
                <br>
                 Carpet::time_refinement_factors         = "[1, 1, 1, 1,
                1, 1, 1]"<br>
                <br>
                for the other parfile
                (LeanBSSN_RN_Q0.2_hf40_202509.par), all timelevels
                update at the same rate *except* the two inner ones. for
                the "base" grid functions, i see no noticeable
                difference insofar as i've checked, but for the Gauss
                constraint violation the results are very different as
                you can see from the plots attached:<br>
                <br>
                - in the gc_x_RN_nosubcycl.pdf plot, everything looks
                fine<br>
                - in the gc_x_RN_subcycl.pdf case, notice how a lot of
                noise propagates from the two inner refinements levels
                -- the ones that updated more frequently than the rest.<br>
                <br>
                the problem is that this noise is not contained in the
                buffer region (if it was, we'd be fine), but propagates
                out, contaminates the rest of the grid, and totally
                ruins any convergence study.<br>
                <br>
                actually a similar thing also happens for the
                hamiltonian constraint -- plots also attached
                (hc_x_RN_nosubcycl.pdf, hc_x_RN_subcycl.pdf) -- but in
                this case the effect is smaller and it doesn't spoil
                convergence studies.<br>
                <br>
                so i was wondering whether this is at all expected
                and/or if there are some parameters or setting that we
                may have overlooked?<br>
                <br>
                thanks,<br>
                Miguel<br>
                <span id="cid:92DFAFB6-EDB3-4029-8728-50E51869B26D"><hc_x_RN_nosubcycl.pdf></span><span
                  id="cid:062F0206-DFC1-44BA-8D72-27C6CD3EF536"><hc_x_RN_subcycl.pdf></span><span
                  id="cid:70993915-AD0C-4CA1-B8E8-F88A7238B9E4"><gc_x_RN_subcycl.pdf></span><span
                  id="cid:4EBEAD50-F7EF-46CA-8754-AB628BAAB97F"><gc_x_RN_nosubcycl.pdf></span><span
                  id="cid:BC1A76B1-C685-422F-BD18-1013DC270A46"><LeanBSSN_RN_Q0.2_hf40_202509.par></span><span
                  id="cid:B7783A9F-ED10-4193-BD53-3F1416B4AC29"><LeanBSSN_RN_Q0.2_nosubcycl_hf40_202509.par></span>_______________________________________________<br>
                Users mailing list<br>
                <a class="moz-txt-link-abbreviated" href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
                <a class="moz-txt-link-freetext" href="http://lists.einsteintoolkit.org/mailman/listinfo/users">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a>
<a class="moz-txt-link-freetext" href="http://lists.einsteintoolkit.org/mailman/listinfo/users">http://lists.einsteintoolkit.org/mailman/listinfo/users</a>
</pre>
    </blockquote>
  </body>
</html>