[yt-dev] Definition of the Radius field

[Matthew Turk]

Hi Nathan,

My drive-by, Friday night answer is to combine a three element boolean
periodicity attribute with fields that are conditionally made available
(through validators) to parameter files if periodicity is appropriate.

-Matt
On Dec 21, 2012 8:16 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<yt-users at lists.spacepope.org>
>> >
>>     http://lists.spacepope.org/**listinfo.cgi/yt-users-**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<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<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/9d21698b/attachment.htm>