[yt-users] Problems with fields

Matthew Turk matthewturk at gmail.com
Wed Oct 2 15:28:52 PDT 2013


On Wed, Oct 2, 2013 at 6:20 PM, Cameron Hummels <chummels at 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.

-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 at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>



More information about the yt-users mailing list