[yt-users] Nearest neighbours

[Elizabeth Tasker]

Hi Matt and Sam,

I just want to do a friends-of-friends scheme where I add cells to an 
ordered list if their properties (density, Potential field etc) satisfy 
my criteria.

Unfortunately, that does mean that I might walk completely off one grid, 
ghost zones and all, and onto another one, so I think what Matt suggests 
below only buys me a few extra steps.

Sam, your routine probably was what I was thinking of, but my question 
wasn't supposed to cause extra work! It was more a "does this exist and 
everyone is using it apart from me?" query. I'll keep with extracted 
grids and then if I run into issues or this later morphs into a useful 
analysis routine that people want to use or parallelise, perhaps we'll 
revisit the question of using trees.

Thanks again,

Elizabeth

Matthew Turk 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
>