<div dir="ltr">Hi Matt,<div><br></div><div>There isn't currently an easy way to share boundary conditions.  However, I think we could attempt to address this with a few easy-ish changes. I can think of three ways, and there may be more.</div>

<div><br></div><div>1) Provide tools for neighbor location + communication</div><div>Here we would use the structure of the tree to quickly identify which processor owns the neighboring region and send across whatever is needed.  This is fairly straightforward since the tree is built out to the point where domain decomp is done, so this is super fast to just traverse to find the owner.  Once known, request a a boundary layer.  This would probably require coming up with some sort of data object that acts as a boundary layer.  I guess this could actually be an AMR2DData object that gets filled out, sent over, but that might be overkill?</div>

<div><br></div><div>2) Build the full tree on all procs, but only only own the data for a subset.  </div><div>I think the AMRKDTree build may be fast enough at this point to just build the entire thing on each processor, then later decide which nodes to populate with data.  This could be done by just setting a buffer around the initial parallel decomp.  </div>

<div><br></div><div>3) Build the tree once up until the point where you have Nprocs leafs.  Then build a second tree that has left and right edges that are buffered around the original tree decomp.  This would be much like option 2, but necessary if the tree build time became dominant.</div>

<div><br></div><div>I think option 2 and 3 would probably be the easiest, though I think it would be a neat to set up communication between nodes through option 1. </div><div><br></div><div>I'd be happy to sprint on this sometime if you'd like.</div>

<div><br></div><div>Sam</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 26, 2013 at 12:29 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, especially Sam,<br>
<br>
Is there a good way to share boundary conditions between nodes of the<br>
kD-tree?  I'm particularly interested in either speeding up vertex<br>
value generation or storing an additional layer of values that<br>
correspond to (expensive to compute) values on other processors, for<br>
the purposes of the contour finder.<br>
<br>
Basically, I think we can parallelize the contour finder in yt-3.0 PR<br>
120 if we can share boundary conditions between processors.  But, I'm<br>
not sure how to do that.  Alternately, if we could double-count<br>
boundary nodes between processors, that would work as well.  For<br>
instance, if processors 1 has a tile that borders a tile from<br>
processor 4, that tile would be "owned" by 4 but would be replicated<br>
on 1.<br>
<br>
Any ideas?<br>
<br>
-Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div>