[Einstein Toolkit] #594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- in b4429f4006e5 CallRestrict in Evolve.cc was changed such that (as was always the case in the git version), all restriction happens before the first POSTRESTRICT routine is scheduled.
This patch does so in CallRestrict in Initialise.cc as well. Is currently only triggered by WeylScal4 it seems (but would affect anything that does a SYNC in MoL_PseudeoEvolution(Boundaries)).
The git version of Carpet always did this it seems.
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by rhaas):
* status: new => review
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by eschnett):
When boundary conditions are applied, prolongation means that the fine grid depends on the next coarser grid. In other words, unless the refinement boundaries are really far apart from each other (which we cannot guarantee), then the coarse grid has to have boundary conditions applied before the fine grid.
I therefore suggest to reverse the refinement level loop to be the same as during evolution. Also, the finest level should not be skipped.
This patch should be applied before the release. There should also be a test case that goes with it -- RNS initial data with a few refined regions inside the star should do it, or the region near a single black hole, and a few steps of time evolution to test both postrestrictinitial and postrestrict.
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
I attach an updated patch.
Currently WeylScal4's teukolsky and teukolskyID serve as such since they were the ones that triggered the error in the first place.
Looking at the code, I have an extra question:
It seems as if Carpet calls Restrict on all refinement levels all the time. Would this mean that if one does initbase::init_3_timelelves it would restrict from the fine timelevel 1 (with 0 being the timelevel where all are aligned at t=0) to the coarse timelevel 1 as well? It should not do so I think since the past timelevels are not aligned in time and therefore restriction should not happen.
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by eschnett):
The do_every logic in Evolve.cc is supposed to prevent this. Restriction only occurs when times are aligned. This logic is not necessary in Initialise.cc.
init_3_timelevels initialises only one timelevel, then evolves forward and backward in time to fill the other two. I don't recall whether restriction occurs there, but if so, it is not via the routine CallRestrict in Initialise.cc.
I have not checked the patch in detail, but it seems correct. Please apply.
#594: Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: closed Priority: minor | Milestone: Component: Carpet | Version: Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by rhaas):
* status: review => closed * resolution: => fixed
Comment:
no restriction occurs for init_3_timelevels (completely different routine and evolution path).
I applied the patch.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit