[yt-users] Problems with fields

[Matthew Turk]

On Tue, Sep 24, 2013 at 12:21 AM, Sam Skillman <samskillman at gmail.com> wrote:
> Hi Cameron,
>
> Just for completeness, Nathan and I were discussing in irc but I'll respond
> here my thoughts up until now. At least the first piece about dx is a bug:
>
> I think this comes from dx being an "excluded" field in a fixed resolution
> buffer, and when the SlicePlot goes to loop over all the data source fields,
> it gets explicitly ignored. Obviously this should not be the case if the
> user explicitly adds a slice of dx. This is a bug.  In
> yt/visualization/fixed_resolution.py you can see why dy works:
> _exclude_fields = ['pz','dpz','dx','x','y','z']
>
> For the rest of the issues, I think if you get rid of ValidateSpatial for
> everything that you have in the notebook, it runs fine. ValidateSpatial of
> more than 0 will mean you need to account for that and take the correct
> slices.  That said, in 2d I can't make sense of the shapes that come out of
> ValidateSpatial(1) for GridLevel. I don't know what is up with that.
>
> I'll also just say that either:
> sl.set_log(field, boolean)
> or
> pf.h; pf.field_info[field].take_log=False is easier than a derived field
> just to set the log.
>
> One last thing -- I'm not sure why the following code has 2 returns in the
> universal_fields.py.
>
>
> def _dy(field, data):
>     return data.dds[1] <--- note the return here. The rest should probably
> be removed. Not sure why it is even there.
>     return np.ones(data.ActiveDimensions, dtype='float64') * data.dds[1]
> add_field('dy_lin', function=_dy, display_field=False,
>           validators=[ValidateSpatial(0)], take_log=False)
>

I left in the old code after I added the short-circuit, in case we
ever needed to go back.  Note that this returns a scalar (since it's
validate spatial and so it should be identical everywhere) rather than
an array.

>
>
> Best,
> Sam
>
>
>
>
>
>
>
> On Mon, Sep 23, 2013 at 8:00 PM, Cameron Hummels <chummels at gmail.com> wrote:
>>
>> Hello fellow yt'ers:
>>
>> I'm having some issues with some fields that I don't think are behaving
>> the way they should be in yt.  I'm encountering a number of problems with a
>> simple 2D enzo dataset (x and y), so I put together a notebook demonstrating
>> my various issues.
>>
>> https://hub.yt-project.org/nb/727j2j
>>
>> To summarize the weirdness from the notebook:
>>
>> 1) The 'dx' field doesn't seem to be able to be displayed (i.e. when I try
>> to slice it), whereas the 'dy' field is fine.  'dz' even exists, but it's
>> just uniformly 0, as is expected from a 2D dataset.
>>
>> 2) When I try to produce a new field which is 2^GridLevel, I get weird
>> results (ignored levels and more).
>>
>> 3-5) I get strange behavior when trying to make a new field combining
>> GridLevel and 'dy', since GridLevel  has twice as many indices as any of the
>> spatial fields (in the z direction no less).  This results in some odd
>> behavior when I try to pair various subsets of GridLevel with 'dy'.
>>
>> Any clarification of these ideas is welcome.  The docs and source haven't
>> yet revealed what is going on here.  Thanks!
>>
>> Cameron
>>
>> --
>> Cameron Hummels
>> Postdoctoral Researcher
>> Steward Observatory
>> University of Arizona
>> http://chummels.org
>>
>> _______________________________________________
>> 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
>