[Yt-dev] halo profiler recentering bug-thing

Stephen Skory s at skory.us
Tue Apr 19 10:34:37 PDT 2011


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?

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)



More information about the yt-dev mailing list