j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Tue, Apr 19, 2011 at 3:22 PM, Stephen Skory email@example.com wrote:
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. :)