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

Britton Smith brittonsmith at gmail.com
Tue May 24 13:20:16 PDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20110524/e0168c48/attachment.htm>


More information about the yt-users mailing list