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:

Thanks for all of the help, everyone!

Cameron

On Tue, Sep 24, 2013 at 8:41 AM, Nathan Goldbaum <nathan12343@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@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@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

--
Cameron Hummels

Postdoctoral Researcher

Steward Observatory

University of Arizona

http://chummels.org