[yt-users] Problems with fields

Cameron Hummels chummels at gmail.com
Wed Oct 2 15:20:50 PDT 2013


Hi Matt,

Thanks for the message and suggestions.


> Yes -- you need to strip off the extra zones before returning a field
> from a ValidateSpatial(N) where N > 0.  For instance, this means this
> would be a bad definition:
>
> @derived_field(name = "MyField1", validators=[ValidateSpatial(1)])
> def _some_field(field, data):
>     return data["Density"]
>
> but this would be a good one:
>
> @derived_field(name = "MyField1", validators=[ValidateSpatial(1)])
> def _some_field(field, data):
>     return data["Density"][1:-1,1:-1,1:-1]
>
>
I agree that this makes sense, but I actually mostly copied the shear field
definition from the VorticitySquared field definition in the code, which
did not observe this rule.  In fact, neither does DivV.  These fields
return a field which is [x+2][y+2][z+2] in shape, which I found odd, but
that is why I left it as it was in my code.  Either way, when I make the
correction to return a field of size [x][y][z], it doesn't seem to fix the
problem, unfortunately.  The error seems to occur prior to the field being
returned, so I think that it may be an independent problem.


> That's why "ShearMach" doesn't work, because the field is incorrectly
> sized when it is returned, and why the error shows up the same for the
> next item.  I should note that what happens when your field definition
> is wrapped in a ValidateSpatial is that *all* of the fields accessed
> inside the field definition have the additional ghost zones.
>

I don't understand this.  How is my entire field definition wrapped in a
ValidateSpatial?  I only include ValidateSpatial in the validators when I
add the field--it doesn't seem to me that it is wrapping the whole thing in
any of my 3 field definitions, but maybe I'm just missing this.  In my
ShearMach3, I simply have a list of separate validators for different
fields, one ValidateSpatial with 1 ghost zone for the velocity fields, and
one ValidateSpatial with 0 ghost zones for the dx and GridLevel fields.  I
guess my use of whitespace makes it look like they are nested, but they are
not.



> The "data" variable like has a .Level attribute as well, but I do not
> think you should rely on it.
>
> I'll look at this level attribute to see if this helps.



> That being said, the usage of 2D data for ghost zones is mostly
> unexplored.  Do you have your data somewhere I can test on it?
>

The dataset is up at
http://www.astro.columbia.edu/~chummels/DD0100.tar.gzif you want to
take a look at it.  It's small and a quick download.

Thanks for the help with this!

Cameron

-- 
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/b2d58081/attachment.htm>


More information about the yt-users mailing list