Order of restriction and calls to POSTRESTRICTINITIAL in Initial timebin

Comments (6)

1. 

   Roland Haas reporter

   • changed status to open
   • removed comment

   • 2011-09-29T20:15:11+00:00
2. 

   Erik Schnetter

   • 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.

   • 2011-09-29T20:45:00+00:00
3. 

   Roland Haas 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.

   • 2011-09-30T10:41:47+00:00
4. 

   Erik Schnetter

   • 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.

   • 2011-09-30T11:24:39+00:00
5. 

   Roland Haas reporter

   • changed status to resolved
   • removed comment

   no restriction occurs for init_3_timelevels (completely different routine and evolution path).

   I applied the patch.

   • 2011-09-30T11:51:13+00:00
6. 

   Roland Haas reporter

   • edited description
   • changed status to closed

   • 2019-02-21T19:56:30+00:00
7. Log in to comment