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?


On Thu, Mar 3, 2011 at 8:35 PM, Matthew Turk <> 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?


On Thu, Mar 3, 2011 at 8:15 PM, Stephen Skory <> 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
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
Yt-dev mailing list