On Wed, Oct 2, 2013 at 6:28 PM, Matthew Turk <matthewturk@gmail.com> wrote:
> On Wed, Oct 2, 2013 at 6:20 PM, Cameron Hummels <chummels@gmail.com> wrote:
>> 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.
>
> You're right, I was wrong -- the field needs to be Ngz*2 bigger in
> each dimension.
>
>>
>>>
>>> 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.
>
> Nothing, besides "dx", "dy" and "dz", will have varying shape inside
> the field definition.
>
> What ValidateSpatial *does* is receive how many ghost zones you need
> as well as the fields you think you might want.  If you ask for a
> field you do not enumerate in that list, it too will have N+2*NGZ in
> its shape, but it will be generated a second time.  This is a hint to
> yt so that it can consolidate IO, as generating ghost zones can be
> expensive.  Supplying multiple ValidateSpatial arguments will not vary
> the behavior depending on the field.
>
>>
>>
>>>
>>> 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.gz
>> if you want to take a look at it.  It's small and a quick download.
>>
>
> Thank you, I will take a look.

The problem seems to be that the nested spatial fields -- which you
are not responsible for, but is how yt generates "GridLevel" and "dx"
-- are causing the issue.  Try using "data.level" and "data.dds".

Incidentally, it seems to be a combination of the nested spatial
fields and the 2D dataset.  In 3D, your definitions work for me.

-Matt

>
> -Matt
>
>> Thanks for the help with this!
>>
>> 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