[yt-users] Problems with fields

Wed Oct 2 16:06:53 PDT 2013

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[0]*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[0]*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.

So I guess there is no way around this for 2D datasets, or at least, this
2D dataset?  I'm out of ideas here.

On Wed, Oct 2, 2013 at 3:38 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> On Wed, Oct 2, 2013 at 6:28 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> > 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.
>
> 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 at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>

-- 
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20131002/9c94c011/attachment.html>