[yt-users] Profiles, root grid

Matthew Turk matthewturk at gmail.com
Mon May 9 16:15:47 PDT 2011 

Hi David,

On Mon, May 9, 2011 at 1:07 PM, David Collins <dcollins at physics.ucsd.edu> wrote:
>> In reference to the __getitem__ issue, it can be challenging to debug
>> this sort of thing remotely without the line that causes the error and
>> a traceback.
>
> Sorry about that.  I wanted to do a little more digging before sending
> out an actual request for help. (good for my yt knowledge)

Totally fair!  :)

> Since I
> have a workaround, this is now not very high priority, but it seems
> like a bug so I thought I'd see if I could fix it.  I fixed one bug,
> but then got stuck:
>
> The problem I had was trying to do a profile on a covering grid using
> the lazy reader, but the real problem comes from a derived quantity on
> a covering grid with the lazy_reader=True, as in
>
> cg = pf.h.covering_grid(0,left,resolution)
> cg.quantities['Extrema']('Density')
>
> Initially this throws a key error, "can't find key 'D'".  I sorted
> this one out, but then got stuck.  Both problems stem from the same
> _get_data_from_grid call on the covering grid.
>
> When the derived quantity __call__ grabs data from the data source, it
> does it (eventually) through a call to
> AMRCoveringGridBase._get_data_from_grid (data_containers lin 3302),
> which has the line:
>
> g_fields = [grid[field] for field in fields]
>
> which needs an ensure_list around fields so it doesn't try to iterate
> over a string (which is why they key error on 'D').  I'm comfortable
> checking in this change.

This is definitely a reasonable thing to do -- _get_data_from_grid
should have an ensure_list in it.  I don't quite know why it's getting
directly called without being funneled through _Extrema, though, which
contains an ensure_list call.  If you get a chance to post a
traceback, this would be an interesting forensic study.  (Well, maybe
"interesting" is overplaying it a bit.)

>
> My next question is the general behavior of this function, which I'm
> not comfortable changing:  Instead of
> AMRCoveringGridBase._get_data_from_grid returning a data object, as
> the name would imply, it returns an integer.  Is this what's supposed
> to happen?  The string also causes problems with the derived quantity,
> since several places expect an array.  This is the code in question:
>
>    def _get_data_from_grid(self, grid, fields):
>        ll = int(grid.Level == self.level)
>        ref_ratio = self.pf.refine_by**(self.level - grid.Level)
>        g_fields = [grid[field] for field in ensure_list(fields)]
>        c_fields = [self[field] for field in ensure_list(fields)]
>        count = FillRegion(ref_ratio,
>            grid.get_global_startindex(), self.global_startindex,
>            c_fields, g_fields,
>            self.ActiveDimensions, grid.ActiveDimensions,
>            grid.child_mask, self.domain_width, ll, 0)
>        return count
>
> The full test and trace are here, wherein you can see the error that
> data[field] has returned a number, not a numpy array.
>
>>>> cg = b.h.covering_grid(0,[0.0]*3,[256]*3)
>>>> cg.quantities['Extrema']('Density')
>
> Parsing Hierarchy100%
> ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> Time: 00:00:00
> Warning: divide by zero encountered in divide
> Warning: divide by zero encountered in divide
> Searching grids for values 100%
> ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> Time: 00:00:01
> Traceback (most recent call last):
>  File "tmp.py", line 18, in <module>
>    cg.quantities['Extrema']('Density')
>  File "/Users/dccollins/local/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 92, in __call__
>    return self._call_func_lazy(args, kwargs)
>  File "/Users/dccollins/local/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 100, in _call_func_lazy
>    rv = self.func(GridChildMaskWrapper(g, self._data_source), *args, **kwargs)
>  File "/Users/dccollins/local/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 544, in _Extrema
>    if data[field].size < 1:
> AttributeError: 'int' object has no attribute 'size'

Of course you are correct, it is not returning quite the data one expects.

The covering grid is a bit special, in that it is not *quite* a data
container.  It can't be evaluated lazily, as you have seen.  This is
because it's designed to actually fill in a grid, which it then
returns to you -- sometimes with cells from the grids it contains
being included multiple times, as necessary.  I'm not sure we can get
around this, but I think that the grid collection might work?  Any
ideas?

Best,

Matt

>
> Thanks!
> d.
>
>>
>> -Matt
>>
>> On Mon, May 9, 2011 at 10:24 AM, David Collins
>> <dcollins at physics.ucsd.edu> wrote:
>>> Hey, Matt--
>>>
>>> I found that if I do "lazy_reader = False" the covering grid works
>>> fine.  It looks like somewhere the field string in one of the
>>> __getitem__  calls is being treated like a list.
>>>
>>> I'm interested in using this with some derivative quantities, can I
>>> just send 'DivV' to the grid collection in your example, or will I
>>> have to let it know that it should grab ghost zones?
>>>
>>> d.
>>>
>>> On Mon, May 9, 2011 at 10:57 AM, Matthew Turk <matthewturk at gmail.com> wrote:
>>>> Hi David,
>>>>
>>>> Try a grid_collection:
>>>>
>>>> gc = pf.h.grid_collection([0.5,0.5,0.5], [pf.h.grids[0]])
>>>>
>>>> Note that it still requires a 'center'.  Also, this object is not
>>>> supposed to do any child masking, so if you find that it does, let me
>>>> know.
>>>>
>>>> -Matt
>>>>
>>>> On Mon, May 9, 2011 at 9:43 AM, david collins <antpuncher at gmail.com> wrote:
>>>>> Hi there--
>>>>>
>>>>> I'd like to add a profile object using only the root grid.  I
>>>>> typically do something like this:
>>>>>
>>>>> pc.add_profile_object(region,fields, weight=weight)
>>>>>
>>>>> Is there a way to restrict this to only root grid tiles?  I've tried
>>>>> using a covering grid, but that's throwing some key error (that I'm
>>>>> looking into presently, I'll have more info if/as I sort it out)
>>>>>
>>>>> Thanks,
>>>>> d.
>>>>>
>>>>> --
>>>>> Sent from my computer.
>>>>> _______________________________________________
>>>>> yt-users mailing list
>>>>> yt-users at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>
>>>
>>>
>>> --
>>> Sent from my computer.
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
>
>
> --
> Sent from my computer.
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>

More information about the yt-users mailing list