Hello,
I am wondering if yt hop can do what enzohop used to do, namely
provide a list of particle IDs associated with each halo. Correctly
stated I think is that it provided for each particle ID, the halo it
was in (if any). The default for yt hop is just to provide the halo
list apparently, with various bulk properties.
Thanks for any help...
Dr. Eric J. Hallman
NSF Astronomy and Astrophysics Postdoctoral Fellow
Center for Astrophysics and Space Astronomy
University of Colorado at Boulder
hallman (at) casa.colorado.edu
office(s): (303) 735-0129 / (303) 492-7484
http://solo.colorado.edu/~hallman/

Hi Florian,
There isn't yet a mechanism for this. You can add it, if you like, in
the file yt/raven/Callbacks.py file, by modifying the edgecolors
argument to the PolyCollection call inside the GridBoundaryCallback
definition; you might be able to scale it using the plot.cmap
attribute, but I'm not sure on that. If I get a chance, I'll try to
take a look at adding it myself this weekend.
Also, it might be a bit easier (if you're on 1.5 or above) to use this
notation for adding this callback:
p = pc.add_slice("Density", 1)
p.modify["grids"]()
which is a bit terser. :) You can see what callbacks are available
by doing: "print p.modify.keys()"
-Matt
On Tue, Aug 18, 2009 at 9:15 AM, Florian
Pajnik<fpajnik(a)physik.uni-wuerzburg.de> wrote:
> Hallo Matt !
>
> I use
> p = pc.add_slice("Density", 1) ; p.add_callback(GridBoundaryCallback())
> to plot the gridstructure. Is there a way so that the grids a coloured
> according to their refinement level ?
> Thank's a lot,
>
> Florian
>
>

Hi all,
I have the following problem, when I compare the results of a merger
tree created using fastBuildMerge.py for the most massive halo at z=0,
with the output of running hop manually, I get the following
discrepancy:
#part x y z
fastBuildMerge 33809 0.492 0.495 0.485
Hop(yt)manually 50931 0.5019 0.4981 0.4902
old enzohop 43815 0.5019 0.4981 0.4902
Visual inspection of slices show, that the last two positions are
correct. So I wonder why the merger_tree gives wrong values even though
it is calling the same Hop routine. I need the positions of the parent
halos for profiling, and a difference of 0.01 in position corresponds to
1.28 Mpc which is a lot for a galaxy cluster, and would spoil the
analysis.
The difference in mass between the first two is strange as well. Did
anybody encounter the same problem and/or knows where it is coming from?
Thanks!
Jean-Claude