<div dir="ltr">Interesting. When I replace data["GridLevel"] with data.Level, it works in cases where I'm using ValidateSpatial(0), but not in cases when ValidateSpatial(1) is called. Even in a simple test case this is true. So for instance this works:<div>
<br></div><div>def _testfield(field, data):</div><div> level = data.Level</div><div> return data.dds[0]*2.0**level</div><div>add_field("TestField", function=_testfield,</div><div> validators=[ValidateSpatial(0)])</div>
<div><br></div><div><br></div><div>But this does not:</div><div><br></div><div><div>def _testfield(field, data):</div><div> level = data.Level</div><div> return data.dds[0]*2.0**level</div><div>add_field("TestField", function=_testfield,</div>
<div> validators=[ValidateSpatial(1,["dx"])])</div></div><div><br></div><div>with the traceback pointing to line: "level = data.Level" stating that AMRSmoothedCoveringGrid object has no attribute 'Level'. This is weird because the same dataset works for the previous field call so clearly the AMRSmoothedCoveringGrid *does* have that attribute.</div>
<div><br></div><div>So I guess there is no way around this for 2D datasets, or at least, this 2D dataset? I'm out of ideas here.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 3:38 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Oct 2, 2013 at 6:28 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
> On Wed, Oct 2, 2013 at 6:20 PM, Cameron Hummels <<a href="mailto:chummels@gmail.com">chummels@gmail.com</a>> wrote:<br>
>> Hi Matt,<br>
>><br>
>> Thanks for the message and suggestions.<br>
>><br>
>>><br>
>>> Yes -- you need to strip off the extra zones before returning a field<br>
>>> from a ValidateSpatial(N) where N > 0. For instance, this means this<br>
>>> would be a bad definition:<br>
>>><br>
>>> @derived_field(name = "MyField1", validators=[ValidateSpatial(1)])<br>
>>> def _some_field(field, data):<br>
>>> return data["Density"]<br>
>>><br>
>>> but this would be a good one:<br>
>>><br>
>>> @derived_field(name = "MyField1", validators=[ValidateSpatial(1)])<br>
>>> def _some_field(field, data):<br>
>>> return data["Density"][1:-1,1:-1,1:-1]<br>
>>><br>
>><br>
>> I agree that this makes sense, but I actually mostly copied the shear field<br>
>> definition from the VorticitySquared field definition in the code, which did<br>
>> not observe this rule. In fact, neither does DivV. These fields return a<br>
>> field which is [x+2][y+2][z+2] in shape, which I found odd, but that is why<br>
>> I left it as it was in my code. Either way, when I make the correction to<br>
>> return a field of size [x][y][z], it doesn't seem to fix the problem,<br>
>> unfortunately. The error seems to occur prior to the field being returned,<br>
>> so I think that it may be an independent problem.<br>
><br>
> You're right, I was wrong -- the field needs to be Ngz*2 bigger in<br>
> each dimension.<br>
><br>
>><br>
>>><br>
>>> That's why "ShearMach" doesn't work, because the field is incorrectly<br>
>>> sized when it is returned, and why the error shows up the same for the<br>
>>> next item. I should note that what happens when your field definition<br>
>>> is wrapped in a ValidateSpatial is that *all* of the fields accessed<br>
>>> inside the field definition have the additional ghost zones.<br>
>><br>
>><br>
>> I don't understand this. How is my entire field definition wrapped in a<br>
>> ValidateSpatial? I only include ValidateSpatial in the validators when I<br>
>> add the field--it doesn't seem to me that it is wrapping the whole thing in<br>
>> any of my 3 field definitions, but maybe I'm just missing this. In my<br>
>> ShearMach3, I simply have a list of separate validators for different<br>
>> fields, one ValidateSpatial with 1 ghost zone for the velocity fields, and<br>
>> one ValidateSpatial with 0 ghost zones for the dx and GridLevel fields. I<br>
>> guess my use of whitespace makes it look like they are nested, but they are<br>
>> not.<br>
><br>
> Nothing, besides "dx", "dy" and "dz", will have varying shape inside<br>
> the field definition.<br>
><br>
> What ValidateSpatial *does* is receive how many ghost zones you need<br>
> as well as the fields you think you might want. If you ask for a<br>
> field you do not enumerate in that list, it too will have N+2*NGZ in<br>
> its shape, but it will be generated a second time. This is a hint to<br>
> yt so that it can consolidate IO, as generating ghost zones can be<br>
> expensive. Supplying multiple ValidateSpatial arguments will not vary<br>
> the behavior depending on the field.<br>
><br>
>><br>
>><br>
>>><br>
>>> The "data" variable like has a .Level attribute as well, but I do not<br>
>>> think you should rely on it.<br>
>>><br>
>> I'll look at this level attribute to see if this helps.<br>
>><br>
>><br>
>>><br>
>>> That being said, the usage of 2D data for ghost zones is mostly<br>
>>> unexplored. Do you have your data somewhere I can test on it?<br>
>><br>
>><br>
>> The dataset is up at <a href="http://www.astro.columbia.edu/~chummels/DD0100.tar.gz" target="_blank">http://www.astro.columbia.edu/~chummels/DD0100.tar.gz</a><br>
>> if you want to take a look at it. It's small and a quick download.<br>
>><br>
><br>
> Thank you, I will take a look.<br>
<br>
</div></div>The problem seems to be that the nested spatial fields -- which you<br>
are not responsible for, but is how yt generates "GridLevel" and "dx"<br>
-- are causing the issue. Try using "data.level" and "data.dds".<br>
<br>
Incidentally, it seems to be a combination of the nested spatial<br>
fields and the 2D dataset. In 3D, your definitions work for me.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> -Matt<br>
><br>
>> Thanks for the help with this!<br>
>><br>
>> Cameron<br>
>><br>
>> --<br>
>> Cameron Hummels<br>
>> Postdoctoral Researcher<br>
>> Steward Observatory<br>
>> University of Arizona<br>
>> <a href="http://chummels.org" target="_blank">http://chummels.org</a><br>
>><br>
>> _______________________________________________<br>
>> yt-users mailing list<br>
>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cameron Hummels<div>Postdoctoral Researcher</div><div>Steward Observatory</div><div>University of Arizona</div><div><a href="http://chummels.org" target="_blank">http://chummels.org</a></div>
</div>