LSSTDESC / DC2-analysis

General analysis tools for the DC2 Data Set.

Home Page:http://lsstdesc.org/DC2-analysis/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

question about possible issue with tutorial (ellipticity definition)

rmandelb opened this issue · comments

This question is about the FOF matching tutorial for which @yymao and @danielsf are the owners.

The very last plot is a comparison of the extragalactic catalog ellipticity and the object catalog ellipticity. However, I thought the two are defined differently, with the former using (1-q)/(1+q) and the latter using (1-q^2)/(1+q^2) definitions of shape. Is that correct, or has something been changed? (e.g., have shapes been converted internally within the catalog reader so the definitions are consistent?) I think some documentation of this point would be useful, regardless of the answer to that question, since this question of shape definitions has come up a few times before as people play with these catalogs.

Yes, the definition of ellipticity in the extragalactic catalog and that in the object catalog are different (the definitions you mentioned are correct).

Yes, we should update the tutorial to reflect that.

Does this make more sense? It still seems that ellipticity in object catalog is slightly larger.
image

Much better. And we don't expect this plot to perfectly lie on the 1:1 line because

  • For this shape measurement method, measurement error in the shapes due to noise in the images essentially (to a rough approximation) adds a Gaussian random number to e1 and another Gaussian random number to e2. If you compute |e|=sqrt(e1^2+e2^2) then it should be larger than the case without noise, especially for round-ish objects. (e.g., as a thought experiment, consider something with e1=e2=0 in the extragalactic catalog... then we make an image simulation with noise in it and measure |e| from the noisy image, so e1 and e2 will in general be nonzero which means |e| is always greater than the extragalactic catalog value of 0)

  • The re-Gaussianization method (used to produce the object catalogs) is not a perfectly unbiased estimator of shapes for multiple reasons. One is that, for interesting mathematical reasons, measurement error does not result in addition of a zero-mean Gaussian random number; it actually causes a bias.

Given these caveats, I'm happy with this plot as a visual demonstration of the approximate level of match we expect after fixing the inconsistent shape definitions.