On Wed, Oct 2, 2013 at 7:06 PM, Cameron Hummels email@example.com wrote:
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:
def _testfield(field, data): level = data.Level return data.dds*2.0**level add_field("TestField", function=_testfield, validators=[ValidateSpatial(0)])
But this does not:
def _testfield(field, data): level = data.Level return data.dds*2.0**level add_field("TestField", function=_testfield, validators=[ValidateSpatial(1,["dx"])])
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.
data.level works, but data.Level does not.
So I guess there is no way around this for 2D datasets, or at least, this 2D dataset? I'm out of ideas here.
This script produces three identical, nice-looking plots for me:
It is based on your notebook.
The problem is almost certainly the combination of the following things:
* GridLevel (which is ValidateSpatial(0)) * dx (which as I mentioned previously in IRC usually is used with a "just_one" call inside a ValidateSpatial field) * 2D data * Asking for ghost zones
What appears to be going on is that some logic in how the size of the grids is calculated is causing wraparound along the (false) third dimension that is added for 2D data, which escalates once you throw in nested ValidateSpatial fields. I don't know why you want to use either VS=0 or VS=1 interchangeably; these are not necessarily meant to do the same thing. My suggestion would be that if you want to use the fields "dx" and "GridLevel" that you instead manually strip off the z-axis edges of those particular fields if dimensionality < 2.