Rlens metric about treecorr

[reikonakajima]

Hello Mike, ditto on this metric for the NGCorrelation(). I tried running NGCorrelation for a lens catalog with (ra, dec, r) and a source catalog with (ra, dec) expecting that metric=Rperp might work, but (as I found out) I guess it's not implemented (yet).

This feature would be useful for getting galaxy-galaxy lensing as a function of comoving distance.

Thanks!

[rmjarvis]

@tmcclintock made some suggestions about this here, but in the interest of keeping discussion of issues contained in one issue thread, I'm responding on this issue instead.

In particular, he proposes this geometry for the definition of Rlens.

I think L can be solved for in this figure via theta = the angle between a and b at Earth as follows:

tan(theta) = L/a
cos(theta) = (a^2+b^2-c^2)/(2ab)
(L/a)^2 = tan^2(theta) = sec^2(theta) - 1 = (1/cos(theta))^2 - 1
L^2 = a^2 * ( (2ab)^2 / (a^2+b^2-c^2)^2 - 1 )

So given a^2, b^2, c^2, this will require one sqrt.

However, I'm not sure that this is the right figure. Do we want L to be perpendicular to a? Or do we want it to form an isosceles triangle from a to b? i.e. a chord across a circle of radius a from the lens to the projection of the source.

Then the equation for L would be

L/2a = sin(theta/2) = sqrt(1-cos(theta))
L^2 = 4 a^2 * (1 - (a^2+b^2-c^2)/(2ab) )

Two sqrts now, but still not bad. But the question is, which result is the more scientifically appropriate one? Anyone have a preference?

[erozo]

Perpendicular to "a" please. a is the LOS to the lens, b is the LOS to the background galaxy. Rperp is the distance from the lens to the background galaxy.

[rmjarvis]

But at the location where L hits the line b, it's no longer the same distance from Earth. Wouldn't you prefer something that follows the great circle at a constant distance from Earth? I would have thought that would be the more relevant distance.

The two definitions are going to be indistinguishable for most applications where theta << 1. So this mostly just matters for > several degree separations where there will be a slight difference.

[tmcclintock]

So as a matter of fact we were incorrect, and we found the solution (before it was just mathematica being misleading). It is:

L^2 = a^2(b+c-a)(a+b-c)(a+c-b)(a+b+c)/(a^2+b^2+c^2)^2

I will implement this either tonight or tomorrow morning and issue a pull request at some point, once I figure out how to do the too small/too large distance checks.

[rmjarvis]

I think you mean (a^2+b^2-c^2)^2 in the denominator.

Just a numerical point to consider here, the typical case is that c << a,b, and also c ~= b-a, so the (a+c-b) term is going to be small. I think I have a better way to approach this that should be more accurate (i.e. not relying on the near cancellation of two largish values). But if you can go ahead and write up some unit tests for this (using trig, etc.) to check that the formulae are accurate, then I can slot in my alternate calculation and easily verify that it is also works.

[rmjarvis]

Also, please start your work from the master branch if possible. I've made some changes to how the Metrics are handled there compared to what was being done in 3.2.

In particular, I've separated the concept of the coordinates (what kind of coordinates are the positions) and metric (how is distance between coordinates defined). So Euclidean, Rperp and (now) Rlens are all valid metrics for ThreeD coordinates. Only Euclidean is valid for Flat coordinates. And I'm planning to add a new metric Arc which will do true great circle distances for Spherical coordinates (in addition to Euclidean which does chord distances).

I think this distinction is helpful to minimize the duplicated code that I had had for the Rperp metric. It duplicated a lot of the Euclidean stuff for ThreeD positions.

[tmcclintock]

I forked the master, but am I right in thinking that I only need to edit Bounds.h? It seems like the code for Rlens will be nearly identical to Rperp, such as the (what I think are) constructors and how you define the operators. Is this correct?

[rmjarvis]

You're still on the releases/3.2 branch. On master, the metric stuff is all in Metric.h.

I have the default branch set to releases/3.2, since that's the latest stable version of TreeCorr. So if people are cloning to get a copy, that's the one they should use. But new development should (usually) be done on master, which will eventually become the next release (and move over to releases/3.3 in this case).

git status should tell you what branch you are on. (At least I think forked repos keep the same branch names...) Then git checkout master should switch to master. Use that for the starting point for your changes.

Then when you are ready to PR, make sure you are requesting to merge that into the master branch here, not releases/3.2, which will be the default.

[tmcclintock]

Ah ok. Perfect. I'll let you know when I'm ready.

[reikonakajima]

Hi -- thanks for implementing this option. I have a few questions from your discussions above:

the typical case is that c << a,b,

I'm confused by this statement; it doesn't seem to match the description given in the diagram. Am I missing something?

L^2 = a^2(b+c-a)(a+b-c)(a+c-b)(a+b+c)/(a^2+b^2+c^2)^2

I'm assuming this equation corresponds to the diagram. Is this Rperp or Rlens? What's the difference between the two? I think the Arc metric corresponds to the chord that Mike mentions, so I'm a bit confused.

[rmjarvis]

the typical case is that c << a,b,

My point is that the opening angle, theta, is typically in arcmin, so sin(theta) and tan(theta) are << 1. You're right that if the source is at a much higher redshift than the lens, c could nonetheless be significant compared to a,b. But it will still be the case that b ~= a+c. So the (a+c-b) term is small and, if done naively, can end up with much lower numerical precision than you might want.

I have a different approach (using a x b) that should be more accurate.

Is this Rperp or Rlens?

L is Rlens in Tom's equation. And in mine above that. Rperp is defined as c^2 - (b-a)^2 using the same diagram.

I think the Arc metric corresponds to the chord that Mike mentions,

No. Arc doesn't exist yet. But it will be a great circle distance, rather than a chord distance. The distinction doesn't matter much for smallish angles, but at large separations, people might want to use the actual great circles for their distance. cf. the discussion on issue #39.

[erozo]

The two definitions are going to be indistinguishable for most applications where theta << 1. So this mostly just matters for > several degree separations where there will be a slight difference.

Hmmmm... I guess it's not inconceivable that this will be come important. We're talking 2% corrections for 100 Mpc at z0.2. Using the chord distance can probably bring this down a bit by canceling out the first term (haven't worked it out, but sounds right).

So I guess my answer is I don't really care right now, but switching to Mike's suggestion could in principle become relevant in the future. I will gladly take either definition of Rlens for now.

[rmjarvis]

@tmcclintock Not sure if you've had a chance to try to code this up yet, but I figured it was probably easier for me to do it, so I went ahead and implemented it on branch #41. I think it's all working, but the unit test is pretty simple. It would be nice to have something more sophisticated there if you have some ideas for that. (e.g. Erika found a serious bug in the Rperp metric when she first started using that.) Or at least if you could try it out on real data to see if things look sensible, that would be helpful.

[tmcclintock]

I did not have a chance to look at it since Friday, but I will try to do a run on real data and report back. Thanks a bunch!

[reikonakajima]

Another question:

L^2 = a^2(b+c-a)(a+b-c)(a+c-b)(a+b+c)/(a^2+b^2-c^2)^2

Are the a, b, and c's (comoving) distances?

For galaxy-galaxy lensing, typically we don't have redshift information for the source galaxies -- usually a comoving distance to the lens would suffice. Is there a metric available to calculate the R_lens (i.e., scaled to angular separation to the source galaxy * angular diameter distance) in this way, where we don't need the comoving distance to the source galaxy?

[rmjarvis]

All the distances are physical distances. The code doesn't know anything about cosmology, so it doesn't know what comoving would mean.

However, you raise a good point that the metric is independent of the distance to the source. Normally I require cross-correlations to be between catalogs with the same type of coordinates, but in this case it's fine to only give ra, dec for the sources. You don't need to know the distances. (In the code, this is called 'spherical' coords vs '3d' when you do know the distance.)

In any case, I enabled using 3d coords for cat1, but spherical coords for cat2 when using the Rlens metric.

[reikonakajima]

I enabled using 3d coords for cat1, but spherical coords for cat2 when using the Rlens metric.

Great, thanks. (sorry to be dense, but the Rlens metric would still work with the cat2 being spherical? I guess what I don't understand is the a,b,c designation.)

[rmjarvis]

the Rlens metric would still work with the cat2 being spherical?

Yes.

[rmjarvis]

@tmcclintock @erozo Have you guys been using this? I was going to cut a release version soon probably, and I was wondering if you had noticed any issues with the Rlens metric that I should address before making it official.

[rmjarvis]

I just fixed a number of errors with the Rlens metric, so if you've been trying anything out with this yet, please grab the current version of the master branch. I think it's working now.

Turns out there were a number of places where there was an implicit assumption of the Euclidean metric. Or at least that some things worked as they do in the Euclidean metric, but which can work differently in the Rlens metric. Thanks to Eric Baxter for pointing out the errors he was getting.