[yt-dev] Make DomainSubsets a subclass of YTSelectionContainer?

Douglas Harvey Rudd drudd at uchicago.edu
Wed Apr 17 13:53:31 PDT 2013


> 
> 1) This will happen inside a chunked iteration if at all possible,
> which reduces the search space for particles considerably

I agree, and was assuming this also, although it's a weak constraint 
(the ratio of particles to octs in any given region is probably constant 
for dark matter, but will vary widely for stars).

> 2) We will utilize the existing octree infrastructure (i.e.,
> OctContainer and its subclasses) to identify the octs to which
> particles belong
> 

Okay, then we should consider how to translate an arbitrary collection
of leaf-octs into the OctContainer.  

> I think this should make it fast enough, as we'll be searching within
> a chunk, which should already be relatively small.  But we can
> certainly adjust this later.
> 

Right, I'm all in favor of getting something that works first, and worry 
about optimization once it becomes necessary, provided we don't 
prevent a scheme from running, albeit slowly.  As long as we always 
operate on chunks, that shouldn't be an issue.

Doug

>> 
>> Do the deposition routines already use some organization scheme (oct tree, say) to
>> match particles to grids?
>> 
>> Doug
>> 
>> 
>> On Apr 17, 2013, at 3:24 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Today in IRC, Chris and I went back and forth on the particle
>>> deposition stuff in advance of the meeting next week.  My task right
>>> now is to come up with spatial field chunking for Octs in a consistent
>>> way; of course I'll write this up into the extant YTEP, which will
>>> allow for feedback particularly from ARTIO, ART and RAMSES folks, but
>>> as a quick first pass I was wondering what everyone thought of:
>>> 
>>> 1) Unifying DomainSubsets into a single object with subclasses
>>> 2) Making that new base class a subclass, itself, of YTSelectionContainer
>>> 
>>> This would mean that this new base class would be very similar to the
>>> GridPatch object -- which it already is -- and would implement, most
>>> crucially, the __getitem__ accessor pattern.  This would return a
>>> 2x2x2xNoct field.
>>> 
>>> [+-][01]?  Specifically, Doug, Chris, and SamL?
>>> 
>>> Sidenote: I discovered that we will not have to rewrite spatial fields
>>> that currently work for grids; my understanding of the numpy
>>> broadcasting system was not complete, and I didn't realize that this
>>> script does *exactly what I want it to.
>>> 
>>> http://paste.yt-project.org/show/3391/
>>> 
>>> This means that our Oct spatial fields will be (2+NGZ*2, 2+NGZ*2,
>>> 2+NGZ*2, NOCT) shaped.
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> 
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org




More information about the yt-dev mailing list