move PARAMCHECK before WRAGH

Comments (5)

1. 

   Erik Schnetter

   • removed comment

   This may work. You would want to move "CallSetup" to before "CCTKi_ScheduleGHInit". Worth a try...

   • 2013-10-07T21:35:16+00:00
2. 

   Roland Haas reporter

   • removed comment

   Not sure I follow. I want to only change the order fo WRAGH and PARAMCHECK both of which are traversed from within CallSetup (lines 183 and 186):

   182      // Register coordinates
   183      ScheduleTraverse (where, "CCTK_WRAGH", cctkGH);
   184      
   185      // Check parameters
   186      ScheduleTraverse (where, "CCTK_PARAMCHECK", cctkGH);
   187    } END_MGLEVEL_LOOP;
   

   I have not tried this, but wouldn't moving WRAG before ScheduleGHInit by a bad idea?

   • 2013-10-07T22:18:41+00:00
3. 

   Erik Schnetter

   • removed comment

   WRAGH is supposed to be before PARAMCHECK, so that one can set up certain data structures that may be required for parameter checking later on.

   However, you are right that the grid structure should not be allocated before PARAMCHECK. Thus moving all the routines that handle the grid structure setup, schedule initialization, etc. should be called after PARAMCHECK. This may create some fall-out and/or may require some changes to schedule routines, but it should be possible.

   • 2013-10-08T07:05:09+00:00
4. 

   Roland Haas reporter

   • removed comment

   ok. This will require some rewriting of code inside of Carpet I think. Right now the docs for the time bins ion page D28 of the user guide) say:

   CCTK WRAGH This timebin is executed when all parameters are known, but before the driver
             thorn constructs the grid. It should only be used to set up information that is
            needed by the driver.
   CCTK PARAMCHECK This timebin is for thorns to check the validity of parameter combinations. This
                  bin is also executed before the grid hierarchy is made, so that routines scheduled
                 here only have access to the global grid size and the parameters.
   

   so no one in PARAMCHECK may expect access to grid functions and technically grid arrays and grid scalars are also not mentioned. Checking the various schedule.ccl there are routines scheduled in WRAGH (eg CarpetRegrid2_Initialise) that access grid scalars. So we will need to turn on grid arrays and grid scalars before WRAGH (and hope that those are "small" which I have at least one thorn for which this is not true since it allocates 3d distributed grid arrays). Probably best committed after the release.

   • 2013-10-08T11:06:56+00:00
5. 

   Erik Schnetter

   • removed comment

   Carpet does internally not distinguish between grid functions and grid arrays. There is a distinction between variables with global storage (defined in top-level statements in the scheduler) and variables with temporal storage (defined in schedule groups or scheduled routines). From this point of view, it would be cleaner to not allocate any storage before paramcheck.

   CarpetRegrid2 could run later, early in the basegrid bin.

   Instead of moving things from wragh to basegrid, we could introduce a new bin "basebasegrid" that is run before basegrid, but only in global mode. This may help move schedule entries around.

   • 2013-10-08T13:10:18+00:00
6. Log in to comment