Dissipation thorn schedules LOCAL routines after GLOBAL ones

Comments (10)

1. 

   Erik Schnetter

   • removed comment

   Modes must die. The sooner the better. There is no way to fix them.

   See also the discussion at <https://en.wikipedia.org/wiki/Mode_(computer_interface)>.

   Having said this, patches to avoid errors are always welcome, unless they are too complex.

   • 2012-06-18T21:14:15+00:00
2. 

   Ian Hinder

   • removed comment

   Do you have some ideas for how to replace modes with something better? I imagine this is related to the data-driven scheduler ideas.

   • 2012-06-19T02:28:00+00:00
3. 

   Erik Schnetter

   • removed comment

   Instead of modes, the schedule entry should specify which regions of grid functions a routine reads and writes. We were currently thinking of region such as "everywhere", "interior", or "boundary" -- extending this to "all components on this level", or "all levels" should do the trick.

   We may still need modes for internal routines e.g. in driver-related or multiblock-related thorns, but I hope to be able to avoid this in physics thorns.

   • 2012-06-20T10:15:18+00:00
4. 

   Roland Haas reporter

   • changed status to open
   • removed comment

   The attached two patches (one with code changes and a compressed one with changes to the test data to stay below the 250K attachment size limit) add special logic to schedule setup_eps_diss in global mode in poststep. The extra logic ensures that SYNC only happens on the levels that the local routine would run on rather than all levels. As far as I can tell this cannot be achieved with SYNC statements in schedule.ccl and requires direct interaction with Carpet and CCTK_SyncGroup().

   • 2012-07-07T19:20:49+00:00
5. 

   Erik Schnetter

   • changed status to open
   • removed comment

   Instead of replicating Carpet's logic, there could be a level-mode routine that does nothing except record on which levels it is called. A subsequent global loop-level mode routine could call CCTK_SyncGroup on these levels. Would this work (and be simpler than the current code?)

   If not, please apply the patch.

   • 2012-07-07T21:29:12+00:00
6. 

   Roland Haas reporter

   • removed comment

   Attached please find a patch (loose-interaction.patch) which accomplishes this. It no longer replicates Carpet's logic but at the price of introducing a second function and more #ifdefs. Which one is nicer depends on how crucial it is to keep user thorns ignorant of Carpets internal logic I guess. Both versions are fine with me (though I slightly prefer the first version since it does not require a static variable). Alternatively and since I know of several other thorns that could benefit from something like this, how about defining (yet another) aliased function to return "RunOnLevel(rl)" which returns `cctk_iteration%do_every == 0` or `(cctk_iteration-1)%do_every == 0` depending on whether we are in EVOL or not? Ie. an aliased routine that exposes Carpet's decision (but not the logic behind it) to the user code in a hopefully controlled manner?

   • 2012-07-07T22:45:07+00:00
7. 

   Erik Schnetter

   • removed comment

   Such an aliased function is a good idea. Presumably, even Carpet itself may benefit from using it...

   • 2012-07-08T10:04:23+00:00
8. 

   Roland Haas reporter

   • changed status to open
   • removed comment

   changed to re-opened to remind me (rhaas) to write the aliased function mentioned in comment:7

   • 2012-10-22T01:33:14+00:00
9. 

   Roland Haas reporter

   • changed status to resolved
   • removed comment

   This issue is fixed along with an issue in AHFinderDirect in #1880 I created a new ticket for the aliased functions proposed in here #1901

   • 2016-05-27T09:48:18+00:00
10. 

    Roland Haas reporter

    • edited description
    • changed status to closed

    • 2019-02-21T20:14:13+00:00
11. Log in to comment