[yt-dev] covering_grid and BCs

Michael Zingale michael.zingale at stonybrook.edu
Fri Apr 18 09:58:39 PDT 2014


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).


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140418/1d721db7/attachment.html>


More information about the yt-dev mailing list