[yt-users] bug in ortho_ray and derived fields?

[Matthew Turk]

Hi Michael,

I believe I have identified the problem, and it was twofold.  One
issue was that the path-parameter (in an ortho-ray, this would be x,
y, or z, but in a non-ortho ray it would be t) was not being
pre-pended to the list of fields being collected.  The other issue was
in how the derived fields work.

Because often derived fields will make use of a number of other fields
-- in your case this was density and x-velocity, for instance -- the
derived field machinery checks to do two things.  The first is that if
at all possible, generate the field inside the data object, rather
than generating it inside the grids and then re-selecting the cells
that go to the data object.  The other is that any fields that are
created in the intermediate steps inside the data object are deleted.
This causes a bit of a problem if two different nested iterators
iterate over the same list; in this case, it was the fields_to_get
list, which was being changed by one iterator at a higher stack level
and still being iterated over at a lower stack level.

I've changed this in r1694 in trunk.  Tonight I'll see what I can do
about backporting things to 1.6, but I believe that we're almost at
our set of features for 1.7, so it might not happen.

Thanks very much for the heads up on this!

-Matt

On Fri, Apr 16, 2010 at 4:47 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Michael,
>
>> I see that all the fields, including the derived ones, are there and are
>> accessible, but for some reason they don't show up as defined keys until
>> I access them. Is that by design? If so, how do I iterate over the
>> fields? Before I was doing something like this:
>
> Yup, it's by design -- it loads on demand.
>
>> But that won't work now.
>
> You can access the full list of fields as:
>
> pf.h.field_list # fields in the files
> pf.h.derived_field_list # fields it thinks it can make
>
>> Actually I'm not explicitly setting what kind of data object to use. I
>> simply did a 'pf = load(filename)' and it decided to go with
>> EnzoHierarchy1D. How would I enforce a 3D data object, and why would
>> that be better?
>
> Oh, I meant a 3D data object like a region, sphere, etc etc.
>
>> Note that all of this is with the trunk (development) version. With the
>> stable version, I couldn't get 1D simulation data to work at all.
>> pf.h.find_max("Density") gave this error:
>>
>>  File "/home/mqk/yt/src/yt-1.6/yt/lagos/BaseDataTypes.py", line 1664,
>> in _get_data_from_grid
>>    return grid[field][pointI].ravel()
>> IndexError: index (1) out of range (0<=index<0) in dimension 2
>
> Ah, yes.  I think I forgot to backport a fix.  I will take a look at
> this shortly.  Thanks for the heads up!
>
> -Matt
>