[yt-users] Nearest neighbours

[Sam Skillman]

Hi Elizabeth,

Preface: Matt's idea of a covering grid is probably easier than what I'm
proposing.  I just saw his email come in.

I think you might be able to use the AMRKDTree for this operation.  At some
point I wrote a locate_cell function (that may not be in the repo but I'm
happy to find it), that you could then use to search for the 26 neighbors by
modifying the current cell position by combinations of it's dx and the
smallest dx in the dataset.  Let me know if you want to try something like
this, and I can dig around in the next day or so.

Sam

On Tue, Sep 13, 2011 at 5:10 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Elizabeth,
>
> If you request ghost zones you can do this.  In particular, requested
> unsmoothed ghost zones will ensure no interpolation occurs.  You can
> do this either by yourself, grid by grid with
> grid_obj.retrieve_ghost_zones(...) or you can use ValidateSpatial in a
> field definition.
>
> It might help if you shared what kind of operation you want to do once
> you have the 26.  If you have the index of a cell, you can just
> access:
>
> grid[field][index_i+1, index_j+1, index_k+1]
>
> and do the +/- and 0/1 modifications.
>
> -Matt
>
> On Tue, Sep 13, 2011 at 5:04 PM, Elizabeth Tasker <taskere at mcmaster.ca>
> wrote:
> > Hi Stephen,
> >
> > Honestly, I was just hoping there was some magically pre-programmed way
> to
> > grab the 26 most refined neighbours of a cell, regardless of which grid
> they
> > were on or level that happened to be. Mapping to an extracted region is
> no
> > hassle, I was just checking there wasn't a smart, quick way of doing this
> > already.
> >
> > Thanks for the info!
> >
> > Elizabeth
> >
> >
> >
> > Stephen Skory wrote:
> >>
> >> Elizabeth,
> >>
> >>
> >>>
> >>> So ... how hard are we talking? :)
> >>>
> >>
> >> The thing is, in all honesty the kdtree we're using in yt (in
> >> parallelHF and in a few other places) is not very convenient. It's
> >> written in fortran, so the array orderings are backwards from the rest
> >> of python (which is C based). It's also confusing to use, it has a
> >> weird wrapper to access the functions that isn't very easy to
> >> understand. The only reason we're using it is in my tests I found this
> >> kdtree implementation to be significantly faster than the alternatives
> >> out there.
> >>
> >> Perhaps if I knew a bit more about what you wanted to do I could help
> >> you come up with a solution that avoids the kdtree. Are you interested
> >> in only the nearest 6 touching cells to a cell? Or do you want to look
> >> at the edges and the corners? Farther out? Do you care about
> >> periodicity? You mentioned looking at grids of coarser resolution, do
> >> you still think you'd like to have neighbor cells returned from a
> >> lower resolution grid?
> >>
> >>
> >
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20110913/9ce45e75/attachment.html>