[yt-dev] covering_grid and BCs

Matthew Turk matthewturk at gmail.com
Fri Apr 18 10:04:37 PDT 2014


On Fri, Apr 18, 2014 at 12:58 PM, Michael Zingale
<michael.zingale at stonybrook.edu> wrote:
> that fix looks ok to me, but at the same time, for this particular function,
> it is not clear to me you need to extend the domain at all.  (For the
> SmoothedCoveringGridBase, we do the same thing, and there I agree you would
> want this).

You're probably right.  The selection is multi-level; the top level is
the region, which generates integer coordinates and values, and the
next is where they get placed into the covering grid.  I believe I set
it to be this way so that we would over-select at the top level, and
then not at the lower level.

I'll issue a PR where I restrict the selection.

>
>
> On Fri, Apr 18, 2014 at 12:48 PM, Michael Zingale
> <michael.zingale at stonybrook.edu> wrote:
>>
>> thanks for the dims pointer -- I was doing a single-level, so I guess I
>> escaped that.
>>
>>
>> On Fri, Apr 18, 2014 at 12:45 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>>
>>> Hi Mike,
>>>
>>> On Fri, Apr 18, 2014 at 12:29 PM, Michael Zingale
>>> <michael.zingale at 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 at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi Mike,
>>> >>
>>> >> On Fri, Apr 18, 2014 at 12:02 PM, Michael Zingale
>>> >> <michael.zingale at 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 at stonybrook.edu
>>> >> > web: http://www.astro.sunysb.edu/mzingale
>>> >> >
>>> >> > _______________________________________________
>>> >> > 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
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Michael Zingale
>>> > Associate Professor
>>> >
>>> > Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>>> > 11794-3800
>>> > phone:  631-632-8225
>>> > e-mail: Michael.Zingale at stonybrook.edu
>>> > web: http://www.astro.sunysb.edu/mzingale
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>>
>>
>> --
>> Michael Zingale
>> Associate Professor
>>
>> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>> 11794-3800
>> phone:  631-632-8225
>> e-mail: Michael.Zingale at stonybrook.edu
>> web: http://www.astro.sunysb.edu/mzingale
>
>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
> 11794-3800
> phone:  631-632-8225
> e-mail: Michael.Zingale at stonybrook.edu
> web: http://www.astro.sunysb.edu/mzingale
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list