Hi Mike,

On Fri, Apr 18, 2014 at 12:29 PM, Michael Zingale
<michael.zingale@stonybrook.edu> wrote:
> The FFT script I posted yesterday does it
>
> http://paste.yt-project.org/show/4528/
>
> I do:
>
> cube = pf.covering_grid(max_level, left_edge=pf.domain_left_edge,
>                         dims=pf.domain_dimensions,
>                         fields=[irho, iu, iv, iw])
>

While this shouldn't impact it, the dims argument here is in terms of
the max_level argument; so if you're at level 0, it will be in terms
of level 0 dx, whereas if you're at level 1, it'll be at level 1 dx.
This should only make things better, not worse.

I think you're right, this is absolutely a bug.  I've replicated it here:

http://paste.yt-project.org/show/4537/

Looking it over, the problem is actually in the python code.  The
*region* selector, not the *covering grid*, is made to be "more
inclusive" so as to help out.  Now, the thing is, this actually breaks
for non-periodic regions ,rather than simply selecting correctly.  In
construction_data_containers.py I was able to fix it by changing line
483 or so to be:

        self._data_source = self.pf.region(self.center,
            self.left_edge - self.base_dds * self.pf.periodicity,
            self.right_edge + self.base_dds * self.pf.periodicity)

Does this look alright to you?

-Matt

> then if I don't hack:
>
> pf.periodicity = (True, True, True)
>
> before doing:
>
> rho = cube[irho].d
>
> I get the error.  I imagine any dataset would show this error if you hack
> one of the periodicity components to False before accessing the cube.
>
>
> On Fri, Apr 18, 2014 at 12:17 PM, Matthew Turk <matthewturk@gmail.com>
> wrote:
>>
>> Hi Mike,
>>
>> On Fri, Apr 18, 2014 at 12:02 PM, Michael Zingale
>> <michael.zingale@stonybrook.edu> wrote:
>> > If I create a covering_grid for a full domain that is not
>> > triply-periodic,
>> > the code will abort when I try to access the data in the covering grid
>> > with
>> > an error generated by selection_routines.pyx that is looking to make
>> > sure
>> > that the boundary conditions are supported.  I understand that this
>> > support
>> > is not yet in place, but I don't think that it should be an issue for a
>> > covering_grid.
>>
>> I agree, it should not.  Can you tell me how you're generating the
>> covering grid?  If it is set with the origin at domain_left_edge and
>> dimensions equal to the dimensions of the domain (at whatever
>> refinement level you've specified) this should not error.
>>
>> >
>> > The covering grid procedure itself should not ever need boundary
>> > conditions,
>> > if I understand what it intends to do.  If you are just sampling the
>> > coarse
>> > data (or averaging the overlying fine data) into your zone, there is no
>> > need
>> > to do any interpolation that would require BCs.  For the
>> > SmoothedCoveringGrid stuff, I understand that BCs should come into play.
>> > Am
>> > I missing something? or should this check on the BCs be considered a bug
>> > in
>> > this case?
>>
>> This sounds like a bug to me!
>>
>> >
>> > Mike
>> >
>> > --
>> > Michael Zingale
>> > Associate Professor
>> >
>> > Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>> > 11794-3800
>> > phone:  631-632-8225
>> > e-mail: Michael.Zingale@stonybrook.edu
>> > web: http://www.astro.sunysb.edu/mzingale
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev@lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
> 11794-3800
> phone:  631-632-8225
> e-mail: Michael.Zingale@stonybrook.edu
> web: http://www.astro.sunysb.edu/mzingale
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org