[Yt-dev] halo profiler recentering bug-thing

[Matthew Turk]

On Tue, Apr 19, 2011 at 3:22 PM, Stephen Skory <s at skory.us> wrote:
> Matt,
>
>> Looks to me like r_min is set to  r_min = 2 *
>> self.pf.h.get_smallest_dx() * self.pf['mpc'], or thereabouts, from
>> line 355 in yt/analysis_modules/halo_profiler/multi_halo_profiler.py.
>> So it's grabbing a profile and setting the inner bin to that.  The
>> point on which it's centered is also not included, because you're
>> asking for a log-spaced profile, and the log of 0 is a NaN.
>>
>> So I guess the next question is, given these constraints, is it
>> behaving as you'd expect?
>
> I think that these 6 cells that are 2 * self.pf.h.get_smallest_dx() *
> self.pf['mpc'] - 1e-10 away perhaps should be included in the profile,
> and they're not. For all intents and purposes and numerical errors,
> the 6 cells are within that minimum radius, but they're not being
> included. So, either we make the minium halo profile radius larger
> such that we don't run into this error with zeroed inner bins, or we
> make the inner bin slightly smaller to account for numerical error.
> What do we all think?

Or you could turn on end_collect, which should be 100% fine for a
sphere whose limits are defined as some really, really small radius
and the radius of that sphere.  end_collect only becomes a problem
when your object is not pre-constraining your values.

Either way, I don't think that this point needs to be belabored; I
don't think this is a bug in the profilers, which from what I can tell
are behaving as requested.  :)

-Matt