Getting back to "getting the halo", I have a dumb thought. I was thinking since the maximum radius is known, YT can extract the particles/fields in the sphere and call that a new halo, but you can also do a halo finding in that sphere and just take the biggest halo as the halo that was meant by the center and max radius right? But this of course requires you to know how the original haloes were generated (specifically which halo finder it used), and if an matching method exists in YT.... Come to think of it, if you know the original halo finding method and it exists in YT, you can just run the halo finder in YT and use .dump() to save the info, the only reason not to do that is to save computation time, but those are cheap nowadays.<br>
<br><div>From</div><div>G.S.</div><div><br><div class="gmail_quote">On Mon, Jul 9, 2012 at 5:52 PM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br><br>The radius, even if somewhat arbitrary is a very useful quantity to have on hand for a halo. With the halo profiler, for example, the halo radius is used to determine the maximum radius out to which radial profiling should be done. Without that, there's no good way to decide how far out radial profiles should be taking. Setting a constant value is generally not a good idea, since it can vary a lot from situation to situation. With the halo profiler, you can then calculate virial mass and radius in a way that also includes the baryons, something that the halo finder cannot do. In conclusion, I strongly support reading in a radius from a halo catalog.<span class="HOEnZb"><font color="#888888"><br>
<br>Britton</font></span><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Mon, Jul 9, 2012 at 7:06 PM, Christine Simpson <span dir="ltr"><<a href="mailto:csimpson@astro.columbia.edu" target="_blank">csimpson@astro.columbia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Stephen,<br>
<br>
I didn't mean to butt into your discussion with Matt, sorry. I don't<br>
want to make more work for you and I totally understand if this<br>
suggestion doesn't fit in with your vision of the yt halo routines.<br>
<br>
I will say, however, that I actually have somewhat of the opposite<br>
opinion on the issue that you raise. To me the radius is an arbitrarily<br>
calculated value and the mass that the halo finder returns is what is<br>
more fundamental. Of course, yt can't know the particles that an<br>
external halo finder identified as belonging to a halo unless that<br>
information is provided, but I would argue that having a 'radius'<br>
doesn't give you that information either.<br>
<br>
It's been a while since I've looked into the halo finding and handling<br>
routines in yt, so it is very likely that my information is outdated (I<br>
apologize if this is the case), but I recall that the default for the<br>
halo 'radius' was the radius of the furthest group particle. For a halo<br>
finder like hop that can return very irregular halos, this makes little<br>
physical sense in my opinion. I believe there was at one time an option<br>
to use what the docs called the 'r200' radius, but it was defined<br>
relative to the mean density of the universe. I guess it is okay to<br>
define it this way, but it is rather non-standard (I would define it<br>
relative to the critical density of the universe). Either way, this<br>
radius is defined by the mass of the halo (and the redshift). I<br>
understand that cosmology is messy, but I think it is better to use that<br>
radius than the distance of the furthest particle, which could be quite<br>
arbitrary in many respects.<br>
<br>
I guess I would just say that for me, I'd rather know what total mass<br>
the halo finder identified and then work from there (i.e. define a<br>
radius and then a sphere object). I can see that others may have other<br>
opinions and halo finders that may operate in other ways. I guess my<br>
one piece of advice would be to try to make routines as general as<br>
possible. I sometimes feel in yt that there is an unnecessary degree of<br>
specialization. Of course, I love yt and I say this from a place of<br>
sincere appreciation for the package and its developers.<br>
<span><font color="#888888"><br>
Christine<br>
</font></span><div><div><br>
On Mon, 2012-07-09 at 16:23 -0600, Stephen Skory wrote:<br>
> Christine,<br>
><br>
> > A suggestion, if it isn't too much trouble. Could you add a column for<br>
> > mass?<br>
><br>
> Actually, just as I sent my last reply I thought a bit harder, and I<br>
> realized that this raises a prickly issue. Let me explain.<br>
><br>
> When you run a halo finder in yt, and save your results with .dump(),<br>
> you can use LoadHaloes() to recover carbon-copies of what you had<br>
> before. Any operation you ran on the halos before .dump() will give<br>
> you the same answer with them loaded later on. This is because with<br>
> .dump() everything that makes up the halos, in particular the full<br>
> particle assignments, is saved to disk.<br>
><br>
> However, with this text loading method, we don't know anything about<br>
> what particles are in the halo when the halo finder was run. This<br>
> means that all we can do (and it's what I'm doing in this new method)<br>
> is simply define the halo as a sphere centered on a point. If I ask<br>
> for particle information from this halo, it will use the sphere.<br>
> Typically, halos found by halo finders are not spheres.<br>
><br>
> Now, if we read in mass from a text file as you suggest, what mass is<br>
> this? If it's the mass of the particles as the halo finder you used<br>
> calculated, what does that mean in yt? It can't reproduce this mass on<br>
> its own, and this mass doesn't correspond to anything yt knows about,<br>
> namely, a nondescript sphere.<br>
><br>
> I'll have to think about this some more, but the TL;DR is that<br>
> specifying a mass like this from a text file introduces some<br>
> ambiguity.<br>
><br>
> I'm still open to other column suggestions.<br>
><br>
<br>
<br>
</div></div><div><div>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br></div>