[yt-users] Issues with code_length versus physical lengths for positions in x, y, z space

[Devin Silvia]

Hmm.  Yes.  It does look like the the factor is, indeed, 1/h.

So, basically, the HaloCatalog object has an issue with it's
calculation of code_length positions, it would seem.  At least for a
Rockstar halo catalog.  I'm a bit confused how this is being corrected
for when doing sp.center/data_ds.domain_width though.

On Mon, Apr 20, 2015 at 1:22 PM, John Wise <jwise at physics.gatech.edu> wrote:
> Hi Devin,
>
> 1.4 is awfully close to 1/h.  I bet there's a missing factor of 1/h in the
> Rockstar interface since Rockstar calculates almost everything (mass,
> lengths, positions) with inverse-h.
>
> John
>
>
> On 04/20/2015 01:12 PM, Devin Silvia wrote:
>>
>> Hi all,
>>
>> I've been trying to do some data analysis of an Enzo dataset to
>> extract information about volumes contained with the virial radius of
>> rockstar identified halos.
>>
>> As a test, I've identified the most massive halo and created sphere at
>> that halo position using a bit of code that looks like this:
>>
>> sp = data_ds.sphere([most_massive.quantities['particle_position_x'],
>>                       most_massive.quantities['particle_position_y'],
>>                       most_massive.quantities['particle_position_z']],
>>                      most_massive.quantities['virial_radius'])
>>
>> Then, when I actually try to use the sphere to analyze data or make
>> plots, it seems like there is something screwy going on with the
>> position information, which you can see if you look at the
>> calculations done here:
>>
>> http://paste.yt-project.org/show/5522/
>>
>> When you look at the "center" based on a calculation of the positions
>> with respect to the domain, you get a different center than the one
>> that just comes of sp.center in "code_length".  Specifically, the
>> "code_length" center values all seem to be off from the actual
>> position of the halo by a factor of 1.4:
>>
>> In [98]: sp.center.in_units("kpc")/data_ds.domain_width.in_units("kpc")
>> / sp.center.d
>> Out[98]: YTArray([ 1.40845077,  1.40845077,  1.40845077]) (dimensionless)
>>
>> I'm not sure where this factor is coming from, but it seems to be
>> buried in some sort of unit conversion step somewhere.
>>
>> Thanks,
>> Devin
>>
>
> --
> John Wise
> Assistant Professor of Physics
> Center for Relativistic Astrophysics, Georgia Tech
> http://cosmo.gatech.edu
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org



-- 
Devin W. Silvia
NSF Astronomy and Astrophysics Postdoctoral Fellow
Department of Physics and Astronomy
Michigan State University
www.devinsilvia.com
_______________________________________________
yt-users mailing list
yt-users at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org