[yt-users] possible bugs in analytical mass function code and halo profiler code

[Michael Kuhlen]

Ah, that's a good point about the re-centering. I see that in the yt
'stable' branch there's a 'use_density_center' option, although the
docs say "This is generally not needed." But I'm using the 'yt'
branch, and there 'use_density_center' has been replaced with a
'recenter' option. It looks like I have to pass a function that
performs the halo re-centering. What does this function have to look
like? Is there an example anywhere?

> All that aside, I think I agree with calculating the virial properties from the outside in, rather than the inside out.  I support that change being made to the code.  If you've already got it implemented, feel free to push it.

I just tried pushing this change, but apparently I don't have commit
permissions for yt. I think Matt set that up for me a while ago with
the same password as for Enzo, but that doesn't work for me now.

Cheers,

Mike

On Tue, May 24, 2011 at 1:20 PM, Britton Smith <brittonsmith at gmail.com> wrote:
> Hi Mike,
>
> I've found that the issue of overdensity being lower in the innermost bins
> can be resolved with a recentering of the sphere before profiling.  I
> believe that the current default is to use the location of maximum dark
> matter density as the center of the sphere.  Stephen has done a lot of work
> on this and has written some functionality to recenter profiles on the
> location of maximum baryon density, for example.  I'm not sure what the
> right answer is for how profiles should be centered.  As Stephen has found,
> it gets messier when a halo is undergoing a significant merger.
>
> All that aside, I think I agree with calculating the virial properties from
> the outside in, rather than the inside out.  I support that change being
> made to the code.  If you've already got it implemented, feel free to push
> it.
>
> Nice work!
>
> Britton
>
> On Tue, May 24, 2011 at 3:26 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi Mike,
>>
>> I'll leave the rest for Britton, Stephen, etc, but I can address your
>> final point.
>>
>> > 3) Lastly, one question about the radial profiles. I've noticed that
>> >   the 'CellVolume' field is rarely equal to 4.0/3.0 * pi *
>> >   ('RadiusMpc' * 3.09e24)**3. Typically 'CellVolume' is about 35 -
>> >   40% larger. Maybe this is because the grid cells partly "overshoot"
>> >   the edge of the sphere? But I'm surprised that this is a 35%
>> >   effect... This potentially affects the determination of the virial
>> >   radius.
>>
>> CellVolume is always calculated by summing up the values of the cells
>> that are included, which are determined by the AMRSphere object.
>> There are a couple potential weaknesses here, but they will be
>> consistent with the cells that have been included.  This is done in
>> two routines:
>>
>> yt/data_objects/object_finding_mixin.py line 162:
>> ObjectFindingMixin.find_sphere_grids
>> yt/data_objects/data_containers.py line 2936:
>> AMRSphereBase._get_cut_mask (also see _is_fully_enclosed just above)
>>
>> This uses the RadiusCode field, which is defined on line 746 of
>> yt/data_objects/universal_fields.py.
>>
>> The is_fully_contained (which you can verify is not causing the
>> problem inserting "return False" at the top of that routine and
>> checking again) routing determines whether or not the grid requires
>> additional masking.  The masking is done by comparing RadiusCode to
>> the radius of the sphere.  RadiusCode comes from the center of the
>> cells.  If you catch too many root grid cells, for instance, this may
>> result in an overestimate.  It's possible that this could be 30-40%,
>> if it's integrated over the entire sphere, catching cells here and
>> there on the exterior that contribute far too much.  (You could, at
>> best, be adding on an entire ~3/4 of a cell, and effectively extending
>> the radius by sqrt(3) dx.)  It's worth investigating if this is indeed
>> where the issue is coming from.
>>
>> That aside, the selection method is identical everywhere, so I do
>> believe that taking the sum of CellVolume is the correct method,
>> rather than using 4/3 pi r^3.
>>
>> -Matt
>>
>> >
>> >
>> > Thanks,
>> >
>> > Mike
>> >
>> >
>> > --
>> > *********************************************************************
>> > *                                                                   *
>> > *  Dr. Michael Kuhlen              Theoretical Astrophysics Center  *
>> > *  email: mqk at astro.berkeley.edu   UC Berkeley                      *
>> > *  cell phone: (831) 588-1468      601 Campbell Hall                *
>> > *  skype username: mikekuhlen      Berkeley, CA 94720               *
>> > *                                                                   *
>> > *********************************************************************
>> > _______________________________________________
>> > yt-users mailing list
>> > yt-users at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>



-- 
*********************************************************************
*                                                                   *
*  Dr. Michael Kuhlen              Theoretical Astrophysics Center  *
*  email: mqk at astro.berkeley.edu   UC Berkeley                      *
*  cell phone: (831) 588-1468      601 Campbell Hall                *
*  skype username: mikekuhlen      Berkeley, CA 94720               *
*                                                                   *
*********************************************************************