- changed status to open
- removed comment
Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin
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.
Keyword:
Comments (6)
-
reporter -
- removed comment
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.
-
reporter - removed comment
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.
-
- removed comment
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.
-
reporter - changed status to resolved
- removed comment
no restriction occurs for init_3_timelevels (completely different routine and evolution path).
I applied the patch.
-
reporter - edited description
- changed status to closed
- Log in to comment