[yt-users] Best way to load in halos?

[Christine Simpson]

Hi Stephen,

I didn't mean to butt into your discussion with Matt, sorry.  I don't
want to make more work for you and I totally understand if this
suggestion doesn't fit in with your vision of the yt halo routines.

I will say, however, that I actually have somewhat of the opposite
opinion on the issue that you raise.  To me the radius is an arbitrarily
calculated value and the mass that the halo finder returns is what is
more fundamental.  Of course, yt can't know the particles that an
external halo finder identified as belonging to a halo unless that
information is provided, but I would argue that having a 'radius'
doesn't give you that information either.  

It's been a while since I've looked into the halo finding and handling
routines in yt, so it is very likely that my information is outdated (I
apologize if this is the case), but I recall that the default for the
halo 'radius' was the radius of the furthest group particle.  For a halo
finder like hop that can return very irregular halos, this makes little
physical sense in my opinion.  I believe there was at one time an option
to use what the docs called the 'r200' radius, but it was defined
relative to the mean density of the universe.  I guess it is okay to
define it this way, but it is rather non-standard (I would define it
relative to the critical density of the universe).  Either way, this
radius is defined by the mass of the halo (and the redshift).  I
understand that cosmology is messy, but I think it is better to use that
radius than the distance of the furthest particle, which could be quite
arbitrary in many respects.

I guess I would just say that for me, I'd rather know what total mass
the halo finder identified and then work from there (i.e. define a
radius and then a sphere object).  I can see that others may have other
opinions and halo finders that may operate in other ways.  I guess my
one piece of advice would be to try to make routines as general as
possible.  I sometimes feel in yt that there is an unnecessary degree of
specialization.  Of course, I love yt and I say this from a place of
sincere appreciation for the package and its developers.

Christine

On Mon, 2012-07-09 at 16:23 -0600, Stephen Skory wrote:
> Christine,
> 
> > A suggestion, if it isn't too much trouble.  Could you add a column for
> > mass?
> 
> Actually, just as I sent my last reply I thought a bit harder, and I
> realized that this raises a prickly issue. Let me explain.
> 
> When you run a halo finder in yt, and save your results with .dump(),
> you can use LoadHaloes() to recover carbon-copies of what you had
> before. Any operation you ran on the halos before .dump() will give
> you the same answer with them loaded later on. This is because with
> .dump() everything that makes up the halos, in particular the full
> particle assignments, is saved to disk.
> 
> However, with this text loading method, we don't know anything about
> what particles are in the halo when the halo finder was run. This
> means that all we can do (and it's what I'm doing in this new method)
> is simply define the halo as a sphere centered on a point. If I ask
> for particle information from this halo, it will use the sphere.
> Typically, halos found by halo finders are not spheres.
> 
> Now, if we read in mass from a text file as you suggest, what mass is
> this? If it's the mass of the particles as the halo finder you used
> calculated, what does that mean in yt? It can't reproduce this mass on
> its own, and this mass doesn't correspond to anything yt knows about,
> namely, a nondescript sphere.
> 
> I'll have to think about this some more, but the TL;DR is that
> specifying a mass like this from a text file introduces some
> ambiguity.
> 
> I'm still open to other column suggestions.
>