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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

David, Grid collection works as any other AMR3DData container. 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. -Matt On Mon, May 9, 2011 at 10:24 AM, David Collins 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 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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi David, On Mon, May 9, 2011 at 1:07 PM, David Collins 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 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 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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi Dave, On Tue, May 10, 2011 at 10:39 AM, David Collins wrote:

...

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?

Aha, that makes sense.  It works with HardWorking reader just fine, so maybe an error could be raised if lazy_reader is used with that kind of object.

I'll give a go at implementing that. As a brief aside, I kind of regret calling it 'lazy_reader' now. Back when that got put in -- something like four years ago? -- it was to distinguish from loading all the data at once and manipulating it in memory. I think the 'lazy' came from the idea of load-on-demand. Nowadays it's just an unfortunate artifact that has a fun side effect of being slightly confusing. :( -Matt

d.

...

Best,

Matt

...

Thanks! d.

...

-Matt

On Mon, May 9, 2011 at 10:24 AM, David Collins 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 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 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@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org