[Yt-dev] halo profiler recentering bug-thing

Matthew Turk matthewturk at gmail.com
Tue Apr 19 10:44:36 PDT 2011


Hi Stephen,

On Tue, Apr 19, 2011 at 1:34 PM, Stephen Skory <s at skory.us> wrote:
> Hi all,
>
> This morning and yesterday I spent some time trying to diagnose an
> issue with the halo profiles when using a recentering function. In
> summary, with a recentering fuction, a large majority of the profiles
> generated would have zero- and nan-valued inner-most bins for all the
> fields except for radius. I believe Britton saw this as well. I think
> I have tracked down the proximate cause, but I don't know quite what
> it means or the best solution. Sorry to those of you who I am going to
> patronize with some descriptions below.
>
> In data_objects/profiles.py, in the function _get_bins() (all of this
> is for 1D profiles), the radius of each cell is found in relation to
> the center of the sphere, and then a dict of arrays of which cells
> belong in which radial bin is built. This dict is then used to pull
> out values from fields to make the profiles. I'm finding that with
> recentering, for the profiles with zeroed first bins, there are no
> cells being put into the inner-most bin. Furthermore, I'm finding that
> in all* these cases there are exactly 6 cells that are within 1e-10 of
> the inner-most bin edge, and are being excluded from binning. If these
> cells were included, the inner-most bin would not be empty.
>
> It seems to me that this problem may be a numerical and geometric one,
> but I can't quite convince myself of this. What do all of you think?

6 cells sounds like the faces.  If you place a sphere at the center of
a cell, exclude the zero-radius cell and then go outwards exactly one
dx, only the cell and the six cells on its faces will be collected.

I believe that there's some place that sets a default sphere or bin
size to be the dx of the center cell, but I have no idea which
machinery you are moving through to get to this point in the profile.
Could you decorate the __init__ method of BinnedProfile2D with
@print_tb (defined in yt/funcs.py) and then send at least one
representative traceback, so we can look at each part of the stack and
examine the neighbroing code?

Thanks for tracking this down, Stephen.

-Matt

>
> In a somewhat related question, the parameter "end_collect" controls
> whether or not bins that fall outside of the min/max of the profile
> range are included in the binning. The halo profiler currently uses
> the default, which turns "end_collect" off, so cells outside the
> min/max are thrown away. It seems to me that we may want to make
> including all cells inside the minimum radius default as part of the
> inner-most bin. This would instantly solve the problem above, but I
> don't know if this is correct. It may even match how observers do
> things with their finite beam widths.
>
> Thanks for your comments!
>
> (* "all" means I have yet to find a counter-example. The universe is
> very large, however.)
>
> --
> Stephen Skory
> s at skory.us
> http://stephenskory.com/
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list