> So, for a test program like this
>
> use BlockDist;
> config var n = 5;
>
> const ProblemSpace = {1..n, 1..n},
> BlockSpace = ProblemSpace dmapped Block(boundingBox=ProblemSpace);
>
> coforall loc in Locales do
> on loc{
> var myInds = BlockSpace._value.locDoms[here.id].myBlock;
>
> writeln("locale: ", here.id, " myInds: ", myInds);
> }
>
> compiler says:
> myInds.chpl:13: error: unresolved access of '[domain(2,int(64),false)]
> LocBlockDom(2,int(64),false)' by '[int(64)]'
Oh, right -- I see my oversight. The issue is that the Block()
distribution reshapes the Locales array as a 2D array and the locDoms[]
array is over that 2D array, so you'd need to know the locale's position
in that 2D array. The variation on this would be to do the following
(which should be truly nD, and which I actually compiled since I'm not
running off to lunch anymore):
coforall locid in BlockSpace.dist._value.targetLocDom do
on BlockSpace.dist._value.targetLocales[locid] {
var myInds = BlockSpace._value.locDoms[locid].myBlock;
writeln("locale: ", here.id, " myInds: ", myInds);
}
This essentially peeks under the covers in the distribution to ask how
it's storing the locales domain (targetLocDom) and array (targetLocales).
As with the previous approach, it should be considered a hacky workaround
until a more formal interface is in-place.
Speaking of which, let me see if I can dig up that work from the
internship...
-Brad
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
