[Users] Toward an Extensible Volume Integration Thorn

[Zach Etienne]

Thanks for taking a look, Frank!

Nice catch with the "SCHEDULE InitializeCounter before InitializeCounter".
After fixing this bug, there is no difference in the result; still get a
hang. That the scheduling infrastructure actually permitted this
gibberish should probably be a bug report by itself...

But regarding your explanation, I have enabled Carpet::veryverbose, and no
infinite loop is printed. In fact, it just hangs before printing anything
related to the WHILE loop. If I had seen an infinite loop or any output,
this could have conceivably been helpful in diagnosing the problem...

Thus I am hoping that the plans to make things simpler include proper
exception handling, so that weird scheduling hangs and inconsistencies (in
actual scheduling versus the schedule printout at the start of execution)
are a thing of the past.

Bottom line:
Based on your description of the problem, I believe I now have working
versions of ScheduleTester and my original volume integration thorn. Thanks
for your help; it really saved me a lot of trouble.

Regarding the volume integration thorn:
As promised, it is pretty easily extensible, and as such, I plan to extend
it significantly over the coming weeks, adding lots of useful volume
integrals (all optional and disabled by default). I would like to include
this thorn alongside IllinoisGRMHD in the next ET release; it will contain
a number of useful diagnostics that do not already exist within ET.

-Zach

*     *     *
Zachariah Etienne
Assistant Professor of Mathematics
West Virginia University

On Sun, May 24, 2015 at 12:55 AM, Frank Loeffler <knarf at cct.lsu.edu> wrote:

> On Sat, May 23, 2015 at 09:10:37PM -0400, Zach Etienne wrote:
> > Thanks for your tips. After many hours of looking into this problem, and
> > even trying (unsuccessfully) to use Carpet macros, I conclude that I am
> > being held back by a bug in Cactus scheduling.
>
> Yes and no. The Cactus scheduling is fine, but the interaction with the
> Carpet modes is often surprising, and so it is here.
>
> This is (please correct me), how the interaction between Cactus and
> Carpet works:
>
> Cactus -> Carpet: please schedule stuff in Analysis
> for all modes in Carpet (and levels and components if applicable):
>   Carpet -> Cactus: call all functions in Analysis
>   for all functions in Analysis:
>     Cactus -> Carpet: Call function
>     Carpet: if function should be called in current mode: call
>             otherwise: ignore
>
> Given this, can you see why your thorn hangs?
>
> You schedule the initialization of the while-variable in 'global'.
> 'global-early' comes before that, so Cactus gets the task to loop while
> 'counter' in global-early, on an uninitialized variable, and inside that
> loop nothing touches that variable, so the loop never stops.
>
> Yes, this is kind of backward, and feels a bit strange. And it is. We do
> have plans to make this simpler.
>
> What you have to do to make this work:
> - hold the loop variable at 0 whenever you don't want to loop,
>   especially: initialize it right at the start to 0 and make sure
>   it doesn't go below 0.
> ( also, but you already do this:
> - make sure you initialize the loop variable (to the number of loops) in
>   the same mode as the function that decrements it
> )
>
> Btw: probably not connected to this problem: I am surprised to see that
> "SCHEDULE InitializeCounter before InitializeCounter" actually works. Is
> there any reason for that? :)
>
> Frank
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150524/56349e15/attachment.html