NG doesn't work as expected in simulation box with x, y, z

[jingssrs]

I tried to apply NG correlation to simulation box of 1Gpc/h, shear G is on the x-y plane. I added a very large value (10000Gpc/h, also tried 100Gpc/h) to the z positions of all the data points to make z axis the line-of-sight direction. But I found that TreeCorr NG doesn't provide the expected signal for each NG pair. I realized later that it is because for each NG pair, TreeCorr always calculate the position angle (saying G relative to the line connecting the two points, N and G) on a spherical plane. While, in my case, what I really want is the position angle on x-y plane. If my above understanding and claim is correct, I think it would be helpful to point this out in the document somewhere, or it would be great that this can be improved in TreeCorr.

[rmjarvis]

If you give it x,y,z, I don't think TreeCorr calculates the positions on a "spherical plane" (whatever that means); it just uses the direct 3-D distance between two points. Which isn't what you want, it sounds like, but I don't think this is an error in TreeCorr.

I think there are two possible ways to get what you want. First, you can just not give TreeCorr the z direction when you make the Catalog. Then the distances will be in the x-y plane, which I think is what you are asking for.

Alternatively, you can use either the Rperp or Rlens metric with the full 3-d positions to get the perpendicular direction, either of which should also be very close to what you seem to want if the z values are all very large.

The metric distances are described here.

[jingssrs]

The distance calculation is pretty fine, since my z is very large, and I used Rperp. It's the position angle for calculating gammaT, that I believe TreeCorr is calculating sth like this: theta2 = 90coord.degrees - c2[j].angleBetween(c1[i], north_pole) expm2theta2 = np.cos(2theta2) - 1j np.sin(2theta2) gT = (g12[j] + 1j g22[j]) expm2theta2

But I really want is: expmialpha = (xdist - 1jydist) / dist_xy gT = (g12[i] + 1jg22[i]) * expmialpha**2

please find my simple test code here https://github.com/jingssrs/treecorr_test.git

Please let me know if my understanding for treecorr is wrong. Also, I wrote a simple code which works fine for my purpose of calculation in simulation box for now (but it's not as efficient as treecorr). But still I want to verify my understanding and let you know.

[rmjarvis]

Ah, I see. You're trying to define the shears is a non-standard way. The convention that TreeCorr uses for shears in a 3D space (and 2D spherical) is relative to the local north direction. For any particular galaxy, if you align your orientation of the galaxy image so that North is up and West is right, then +g1 is horizontal (i.e. E-W direction), -g1 is vertical (N-S), +g2 is the / diagonal (NW-SE), and -g2 is the \ diagonal (NE-SW).

This is a very standard convention used by most current WL surveys. (Including DES, LSST, and HSC at least.) In (x,y,z) coordinates, the north pole direction is at x=y=0, z=1 (or arbitrarily positive really). If you want your shears to be defined such that +g1 is in the x direction and -g1 is in the y direction, you should rename your axes when you pass them to TreeCorr. Swap y and z when you pass them to the Catalog. Then the large z becomes a large y, which puts your cube a large distance away on the celestial equator, rather than towards the north pole direction. And TreeCorr's convention will be equivalent to using x,z coordinates for the shear (which are your original x,y).

[rmjarvis]

This convention doesn't seem to be well documented in the TreeCorr docs currently, so I should add a page describing this better.

[jingssrs]

Thank you, swapping y and z works (when original z is added with a large constant). I think it should be helpful to have the convention of shear definition documented somewhere.

[rmjarvis]

See the new doc page here: https://rmjarvis.github.io/TreeCorr/_build/html/shear.html#shear-conventions

[jingssrs]

Thank you so much. It's really helpful.