[yt-dev] Question regarding changeset 71c2bfaa3b5f in yt on ghostzone calculations

[Matthew Turk]

Hi Cameron,

On Thu, Mar 22, 2012 at 8:28 PM, Cameron Hummels
<chummels at 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 at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org