Hi Cameron,

On Thu, Mar 22, 2012 at 8:28 PM, Cameron Hummels chummels@astro.columbia.edu wrote:

Hey everyone (but specifically John Wise),

I just pulled to the newest version of yt, and I got significantly different behavior from some old scripts of mine which use yt than I did prior to the pull.  I bisected the changesets to the one making the big difference for me, and it was your commit: 71c2bfaa3b5f from late January.

Specifically, I'm doing some off axis projections which use the volume rendering interface and ghost zones.  I homogenize my volume, then take a snapshot of the interior.  When I do this with my old code, it takes about 20 seconds to partition and homogenize the volume, but now it takes over 10 minutes to partition the volume (I actually kill it at 10 minutes), and it uses so much memory that all of my other programs grind to a halt on a relatively big memory machine.

I was wondering if you (or anyone else on the list) encountered any problems in volume rendering with ghost zones since this changeset (i.e. the last two months), or if you can think of any obvious reasons why there would be such a slow down?  I know you're out of town right now, but I figured I'd send this to the list anyway to see if anyone else had experienced slowdowns. Thanks for the help!

Thanks for the bug report. There has been a lot of churn in the covering grids lately, as we try to stick to something faster, but occasionally identify corner cases along the way. In late January, John W, John Z and I thought we'd identified a patch that worked for everybody (both well-behaved and non-well-behaved AMR) and committed it. It looks like that's not working here.

What yt wants to do when generating ghost zones is to find the minimum level that full covers a region (plus one additional buffer zone in each direction *at that coarsest resolution) and then interpolate downward, filling with new zones as necessary. In the older version of yt, the process always started at level 0. In the newer version, we try to identify the lowest level that full contains the region *and* the buffer zones at that level.

I don't know exactly what is going on with your dataset that is causing it to enter into what I suspect is an infinite loop. Filling ghost zones without requiring that all grids fill their own simultaneously presents some tricky challenges. I'm coming to think the code might just as well be thrown out and we start over, not using the smoothed covering grid at all but instead a special boundary filling method, where the regions to fill are a lot smaller.

Anyway, if we were to continue on the idea of having a cascading fill, I guess we need to rethink the strategy for it. It already sort-of looks like this, but perhaps touching it up would fix the issues:

1) Iterate backwards from desired level to 0, determining if grids on that level can fill the requested region + 1 buffer zone *at that level's resolution* (i.e., the volume must be at a minimum 3x3 dimensions) 2) Fill, interpolate to the next level (at which point it must be a minimum of 4x4, as we only care about our central zone being interpolated plus one buffer at this level)

Now iterate on item 2. I am sure there is an easier or better way, particularly if we are attempting only to fill boundary conditions. In well-behaved AMR, the boundary condition issue becomes easier as you don't have jumps of greater than one level of refinement in the boundaries -- in practice this means you can look to the parent, or a neighboring parent, to get the necessary zones. Here we can't make those assumptions.

Any ideas, Cameron or John or anybody?

-Matt

Cameron

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org