[yt-dev] Definition of the Radius field

[John ZuHone]

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