[yt-dev] Definition of the Radius field

Fri Dec 21 19:06:34 PST 2012

I think a ValidatePeriodic field validation like what Matt suggested makes
the most sense, as it would then error out if someone throws it a
non-periodic dataset.

Sam

On Fri, Dec 21, 2012 at 3:19 PM, John ZuHone <jzuhone at gmail.com> wrote:

> Perhaps this should be a field parameter?
>
> John ZuHone
> Laboratory for High-Energy Astrophysics
> NASA/Goddard Space Flight Center
> 8800 Greenbelt Rd., Code 662
> Greenbelt, MD 20771
> (w) 301-286-2531
> (m) 773-758-0172
> jzuhone at gmail.com
> john.zuhone at nasa.gov
>
> On Dec 21, 2012, at 8:15 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
> > This is a discussion that began on yt-users but since I'm going to
> speculate about how to change the code, I'm replying over here on yt-dev.
> >
> > I see now that it's difficult to check for periodic boundary conditions
> in a code-independent way in the middle of a field definition.  There are a
> number of places where yt assumes periodic boundary conditions (mostly in
> plotting routines) but I don't see any places that programatically check
> the boundary conditions that the simulation was run with.  Am I missing
> something somewhere?
> >
> > I feel like this functionality should be there but I'm not sure what the
> best solution is.
> >
> > Just spitballing: perhaps there be something like pf.periodic which is
> True or False?  This would have to be defined in the individual code
> frontends by looking at runtime parameters.  It's not obvious to me that
> this will be easy to do for codes that don't have self-describing data
> formats.  Another issue is that a binary Periodic attribute won't be
> sufficient for simulations run with mixed boundary conditions.
> >
> > Does anyone else have any thoughts on this?  I don't want to cause a
> huge disruption but I'm strongly -1 on the way the Radius field is
> currently written since it quietly produces incorrect results on a large
> number of test problem-like datasets.  It won't be a problem in
> cosmological simulations so I worry that inexperienced users will tend to
> get bit by it.
> >
> > Cheers,
> >
> > Nathan
> >
> > On 12/21/12 4:26 PM, Geoffrey So wrote:
> >> I've seen and used something similar in my ellipsoids, where the domain
> width (DW) is used to calculate the shortest distance between two points
> due to periodic boundary condition.  So if you do not have a periodic box
> then that line (involving DW) should be changed.  This is part of the
> reason why my ellipsoid container is limited to periodic box only.
> >>
> >> I'm hoping to put in a flag to turn it off and on later, but if a flag
> is put in to turn it off maybe I'll imitate it for the ellipsoids, too.
> >>
> >> From
> >> G.S.
> >>
> >> On Fri, Dec 21, 2012 at 4:18 PM, Nathan Goldbaum <nathan12343 at gmail.com<mailto:
> nathan12343 at gmail.com>> wrote:
> >>
> >>    Hi all,
> >>
> >>    I encountered a bit of odd code deep in the field definition code
> >>    and I need some help to understand why it is the way it is.
> >>
> >>    The field I'm curious about is the Radius field (defined on line
> >>    796 of universal_fields.py):
> >>
> >>    def _Radius(field, data):
> >>        center = data.get_field_parameter("center")
> >>        DW = data.pf.domain_right_edge - data.pf.domain_left_edge
> >>        radius = np.zeros(data["x"].shape, dtype='float64')
> >>        for i, ax in enumerate('xyz'):
> >>            r = np.abs(data[ax] - center[i])
> >>            radius += np.minimum(r, np.abs(DW[i]-r))**2.0
> >>        np.sqrt(radius, radius)
> >>        return radius
> >>
> >>    In particular, I don't understand this line:
> >>
> >>    radius += np.minimum(r, np.abs(DW[i]-r))**2.0
> >>
> >>    Is this supposed to correct for some effect in periodic simulations?
> >>
> >>    The reason I bring this up is because it caused some very weird
> >>    behavior in a 1D FLASH simulation.  In this simulation, the domain
> >>    went from x = -.01 pc to x = +500 pc.  Since the middle of the
> >>    domain wasn't lined up with the 'center' of the simulation at x =
> >>    0, the offending line in the radius calculation led to an
> >>    incorrect calculation of the radius beyond x = 250 pc.  In that
> >>    case, I was able to fix it by changing the offending line to
> >>
> >>    radius += r**2.0
> >>
> >>    Before I issue a patch, I want to see why it's defined the way it
> >>    is currently and see if we can come up with a workaround.
> >>
> >>    Cheers,
> >>
> >>    Nathan
> >>    _______________________________________________
> >>    yt-users mailing list
> >>    yt-users at lists.spacepope.org <mailto: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
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20121221/a613f9c8/attachment.htm>