[yt-users] Problems with fields

Wed Oct 2 08:46:30 PDT 2013

I wanted to follow up on this thread.  First of all, thank you Sam, Nathan,
and Matt for your input.  You were correct on many levels: that the main
problem stemmed from using ValidateSpatial(1) on a 2D dataset, that the
'dx' field could not be plotted because of some assumptions made in the
PlotWindow interface (which have now been fixed), etc.  Thanks!

But I have some related questions regarding this.  My main reason for
asking the questions in the notebook is that I'm trying to create a more
complex derived field, shear, which I would like to work on both 2D and 3D
datasets.  It requires having 1 additional ghostzone on all sides in order
to work (at least for velocity fields).  I'm simply trying to scale the
field by dx*(2^GridLevel), and this is what led to the weirdness that I
distilled into the notebook I sent last week.  When I try to use the dx and
GridLevel fields as ValidateSpatial(1), I end up with the strange behavior
I demonstrated in the notebook (and which is fixed by removing it or going
to ValidateSpatial(0) ) , but I need to include that in order to have them
work compatibly with the Velocity fields which are ValidateSpatial(1).  Or
is there a way to designate ValidateSpatial(1) for some fields and
ValidateSpatial(0) for other fields?  I tried doing it as a list of
[ValidateSpatial(1), ValidateSpatial(0)] in the add_field call, but it
still gave me mismatch errors in indices when trying to combine the fields.
 Does anyone have any ideas as to how to match up these seemingly
incompatible field initializations under one roof?

I've put together another notebook which identifies some of the problems
I'm encountering on this front:

https://hub.yt-project.org/nb/4i8fdg

Thanks for all of the help, everyone!

Cameron

On Tue, Sep 24, 2013 at 8:41 AM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:

> The bug that prevented you from plotting the 'dx' field has been fixed:
>
>
> https://bitbucket.org/yt_analysis/yt/pull-request/607/allow-plotting-of-excluded-fields/diff
>
> Nathan
>
>
> On Monday, September 23, 2013, Sam Skillman 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)
>>
>>
>>
>>
>> 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
>
>

-- 
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20131002/9a07c983/attachment.htm>