[Users] scheduling and SCALAR variable

Sat Sep 19 12:17:31 CDT 2015

How do the modes affect the scheduling?

I scheduling my thorn to be run after the QLM thorn, because I need access
to the spin components calculated by the QLM thorn..

If I schedule everything in my thorn in *global-early*, I get around the
problems of not being able to output correctly..

but now, the thorn runs *before* the QLM thorn, even though the schedule
tree indicates differently.. which means I don't have access to the
variables from the QLM thorn, because they haven't been calculated at the
time my thorn does its calculations..

how is this happening?

best wishes,

Vassili

On Sat, Sep 19, 2015 at 5:40 PM, Vassilios Mewes <vassilios.mewes at uv.es>
wrote:

> Sorry for the late reply, was (and am) still testing around...
>
> Here is the schedule tree for my thorn:
>
>       disk_analysis::Disk_Analysis_Setup_LoopCounter: [global]
>       while (Disk_Analysis::nradii_LoopCounter)
>         GROUP DISK_ANALYSE: Disk_analysis main loop
>           disk_analysis::Disk_Analysis_Decrement_LoopCounter: [global]
>           disk_analysis::Disk_Analysis_calculate_J_gridpoint_shell:
> [global] [loop-local]
>           disk_analysis::Disk_Analysis_reduce_J_total_shell: [global]
>           disk_analysis::Disk_Analysis_calculate_angles_shell: [global]
>       end while
>       disk_analysis::Disk_Analysis_extraction_plane: [global]
>       GROUP DISK_GLOBAL_QUANTITIES:
>         disk_analysis::Disk_Analysis_set_global_quantities: [global]
> [loop-local]
>         disk_analysis::Disk_Analysis_reduce_global_quantities: [global]
>         disk_analysis::Disk_Analysis_set_global_specific_quantities:
> [global] [loop-local]
>
> The problem is the following:
>
> I want to calculate some quantities in the function
> *disk_analysis::Disk_Analysis_set_global_specific_quantities*, these will
> be grid functions that I want to output (in 1D and 3D)
>
> however, the calculation depends on
> *disk_analysis::Disk_Analysis_extraction_plane*, where I decide if I need
> to rotate the coordinate system in which I later want to calculate the grid
> functions... it basically calculates and stores a rotation matrix, as well
> as an integer switch that later tells us if we need to rotate..
>
> now, when scheduling
> *disk_analysis::Disk_Analysis_set_global_specific_quantities* as global
> loop-local, the values obtained in
> *disk_analysis::Disk_Analysis_extraction_plane* (which i store as SCALARS
> and have assigned storage for) are the correct ones, however, I cannot
> output the grid functions calculated, which I guess is due to this response
> from Roland in the mailing list earlier this year:
>
> *On Tue, Jun 2, 2015 at 1:46 PM, Roland Haas <rhaas at aei.mpg.de
> <http://aei.mpg.de>> wrote:*
>
> *> Hello all,*
> *>*
> *> > If you are scheduling everything in GLOBAL (which is the same as*
> *> > GLOBAL-LATE in ANALYSIS) then your OUTPUT will be incorrect since
> OUTPUT*
> *> > is happening in LEVEL mode thus refinement level 3 is output before
> the*
> *> > GLOBAL routine (which runs along with level 0) is executed.*
> *> Oha, obvious not the right statement. GLOBAL-LATE will happen last but*
> *> this happens to be the highest refinement level. Still the effect is
> the*
> *> same OUTPUT happens before GLOBAL-LATE for all but one refinement level*
> *> (that refinement level being the finest one).*
> *>*
> *> This can be seen in Carpet's Evolve.cc file in the CallAnalysis
> routine.*
> *>*
> *> Yours,*
> *> Roland*
>
> now, if i want correct output, i can use either local mode or global-early
> loop-local mode..
>
> then however, the values of the rotation matrix and the integer switch of
> actually using it are not correct, because the routine seems to be called
> now not in the order indicated by the schedule tree, but rather before the
> values have been set...
>
> so: when using *global loop-local *in
> *disk_analysis::Disk_Analysis_set_global_specific_quantities*, the grid
> functions are not output correctly (only in the innermost refinement level)
>
> and when using *local* or *global-early loop-local *the function
> *disk_analysis::Disk_Analysis_set_global_specific_quantities *cannot
> access the data calculated by
> *disk_analysis::Disk_Analysis_extraction_plane..*
>
> is there an obvious way around this? ie getting the correct scheduling for
> both being able to use the values in the function AND outputting the
> calculated grid functions correctly??
>
> best wishes,
>
> Vassili
>
> On Fri, Sep 18, 2015 at 3:17 PM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
>
>> On Fri, Sep 18, 2015 at 12:53:33PM +0200, Vassilios Mewes wrote:
>> > I have a scalar variable, which contains the elements of a rotation
>> matrix
>> > that rotates the z-axis into a given vector...
>> >
>> > I want to calculate some quantities (that are grid functions) in
>> > coordinates that have been rotated by this matrix...
>> >
>> > I run into the following problem:
>> >
>> > when scheduling the calculation of the quantities in local mode, the
>> > function doesn't seem to have access to the rotation matrix elements...
>>
>> You should have access to scalars in any mode. What happens when you try?
>>
>> > when scheduling the calculation in global, loop-local mode, I can't
>> output
>> > the data at the grid points (the output gives 1.96808407167164e+243 at
>> each
>> > point for every refinement level apart from the innermost, where the
>> values
>> > are output correctly)
>>
>> It is difficult to see what is going on without the actual scheduling
>> statements, and in general more information. Could you please post at
>> least the declaration of both scalar and GFs from interface.ccl, and the
>> corresponding SCHEDULE entries in schedule.ccl? Also, I assume you do
>> have storage enabled for both? Also useful might be the output of the
>> schedule tree. You get that by default, but also when running with the
>> -S option (that aborts the run after the tree has been printed).
>>
>> Frank
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150919/b7f9fe8e/attachment.html 