[Yt-dev] tree code for boundedness

[Britton Smith]

One thing I have noticed with the clump finder is that a lot of time is
spent calculating the boundness of objects that are simply a single clump
inside another single clump inside of another single clump.  This occurs
near the very end of the whole process, after the recursive contouring has
gone all the way up to the high level and is now stepping back down to
determine which objects are to be kept as bound sub-clumps of their
parents.  Two thoughts come to mind here.

The first is that, if a clump is found to be the sole child of a parent
clump, it is simply remerged into the larger parent.  No Russian-doll
fragmentation here, if you get my drift.  The point is that there is really
no reason the boundness of the clump should be checked if it has no other
siblings.  Either way, it will be merged back in with it's parent.

My second thought is somewhat related.  As the clump finder is stepping back
out, it is essentially checking boundness of a singly object that is getting
progressively large and larger.  If this is an N^2 / 2 process, a large
number of those cell combinations have already been done by the sub clump
just one step before.  If there was a way of storing that information, it
wouldn't have to be done over and over so many times.

Both of the above could help speed this up.  Does anybody have any thoughts
on this?

Britton

On Thu, Mar 3, 2011 at 8:35 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Stephen,
>
> Yeah, doing the full pairwise summation is pretty slow; the only
> instance of CUDA code in yt is actually a CUDA-fied version of this
> summation that I wrote for the Turk, Abel, O'Shea 2009 paper, because
> our clumps were composed of so many cells we had to speed up the
> binding energy calculation.  If you were to write a tree solver, that
> would be great, but it might require a bit of effort on your part to
> get the cell parentage correct.  One option would be to use the
> completely untested, completely unused Octree that I wrote, add all
> the cells to it, and then try to get the correct potential out of it.
> The problem there is that coarse cells that don't fully cover will
> need to have the non-included cells subtracted off.  But maybe you can
> figure out a way around this?
>
> -Matt
>
> On Thu, Mar 3, 2011 at 8:15 PM, Stephen Skory <stephenskory at yahoo.com>
> wrote:
> > Hi all,
> >
> > I've been working with the clump finder, and am becoming impatient with
> the gravitationally bound test calculation. I'm a very important person! Ok,
> sorry, I'm back to serious now. I'm wondering if we think that implementing
> some kind of tree code or pixelation of cells to lower resolution levels
> would be practical and accurate enough? It would make the double loop much
> smaller and quicker, and there could be a single user-controlled parameter
> that sets the desired accuracy. There are even parallel tree codes out there
> that we may be able to crib from.
> >
> > Any thoughts would be appreciated!
> >
> >
> > Stephen Skory
> > stephenskory at yahoo.com
> > http://stephenskory.com/
> > 510.621.3687 (google voice)
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110303/75510df3/attachment.htm>