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