halo profiler recentering bug-thing
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@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
Hi Stephen,
On Tue, Apr 19, 2011 at 1:34 PM, Stephen Skory 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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Matt,
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?
Here's the traceback when I decorate BinnedProfile1D (which is what I'm using): http://paste.enzotools.org/show/1585/ And here's if I decorate BinnedProfile1D.get_bins(): http://paste.enzotools.org/show/1586/ -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
Hi Stephen,
On Tue, Apr 19, 2011 at 2:25 PM, Stephen Skory wrote:
Matt,
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?
Here's the traceback when I decorate BinnedProfile1D (which is what I'm using):
http://paste.enzotools.org/show/1585/
And here's if I decorate BinnedProfile1D.get_bins():
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? -Matt
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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? -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
On Tue, Apr 19, 2011 at 3:22 PM, Stephen Skory 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
Matt,
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.
I think that this is a good solution because it may better match what observers do. Britton, I think that this should be on by default, what do you think? Otherwise, it should be a parameter to the halo profiler. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
Hi everyone,
Britton here. I tried changing the value of r_min to 3 x the smallest dx
and it didn't seem to fix the problem, which I am somewhat confused by.
However, I think setting end_collect to True is just fine. I'm for it.
Britton
On Tue, Apr 19, 2011 at 3:43 PM, Stephen Skory wrote:
Matt,
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.
I think that this is a good solution because it may better match what observers do. Britton, I think that this should be on by default, what do you think? Otherwise, it should be a parameter to the halo profiler.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
This problem has been around for a while, with or without yt. In the radial profiles I think it's obvious that two problems arise that you're seeing here. First is what was described earlier in the thread, which is that unless you include the position of the zone centers in the range of the radial criteria it gives NaNs. We talked in the past about taking fractional zone values etc as a fix (pre-yt). The second is if the inner bins are too narrow they sometimes exclude either all, or all but a few zone centers, which makes the profiles choppy. What observers do is bin the profiles based on the photon statistics (in the case of the X-ray), which can be approximated by some logarithmic binning typically. This can be calculated simply given the average surface brightness profiles. However, that isn't exactly analogous, as all objects are different as far as their surface brightness profiles. I'm also surprised about britton's fix (that it didn't work I mean). It seems to me that should work, unless the spherical shells for averaging outside that are just too narrow. Eric On Apr 19, 2011, at 10:44 PM, Britton Smith wrote:
Hi everyone,
Britton here. I tried changing the value of r_min to 3 x the smallest dx and it didn't seem to fix the problem, which I am somewhat confused by. However, I think setting end_collect to True is just fine. I'm for it.
Britton
On Tue, Apr 19, 2011 at 3:43 PM, Stephen Skory
wrote: Matt,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.
I think that this is a good solution because it may better match what observers do. Britton, I think that this should be on by default, what do you think? Otherwise, it should be a parameter to the halo profiler.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Eric Hallman Google Voice: (774) 469-0278 hallman13@gmail.com
participants (4)
-
Britton Smith
-
Eric Hallman
-
Matthew Turk
-
Stephen Skory