[yt-dev] covering_grid and BCs

Matthew Turk matthewturk at gmail.com
Fri Apr 18 10:07:20 PDT 2014


Hi Mike,

Actually, on second thought, it occurs to me why I did it this way.
This ensures that we select at least one root cell outside of the
bounds of the object, which is important if we're selecting starting
at offsets from the root grid dx's in unrefined regions.  I'll just
bifurcate and floor/ceil at the domain for non-periodic datasets.

-Matt

On Fri, Apr 18, 2014 at 1:04 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> 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