-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding members_only
option for redmapper catalogs
#317
Conversation
I guess this PR doesn't cover the matching itself? Because one galaxy in the CosmoDC2 table can show up multiple times in the members catalog (just so long as the total membership probability is <=1), and I think that this PR doesn't break that relationship. |
This PR is just removing the "clusters" table when doing the matching. The matching itself is not touched. However, the matching is in fact a left join, and right now protoDC2 is on the left. But according to what you said it seems that we should have put redmapper on the left? @erykoff |
I believe that is correct, that the redmapper members should be on the left. |
@erykoff thanks. Just made the change (moving redmapper catalog to the left for the composite catalog). Take a look? |
I guess the fact that it's a left join and which catalog is on the left is documented elsewhere in the code? |
@erykoff it's (kind of) documented here: https://github.com/yymao/generic-catalog-reader/blob/master/GCR/composite.py#L67 |
A redmapper catalog contains both members information and clusters information, and obviously they would have different number of rows (unless every cluster has only one member, but we don't live in that universe).
GCR by itself does not requires all columns have the same number of rows, and hence the redmapper reader work fine as it. A column of "members" table just have different number of rows from a column of "clusters" table.
However, when matching the redmapper catalog to the underlying protoDC2 catalog, the matched catalog can have only one single table, and in this case, it's the members table that is needed (i.e., each "member", not "cluster", in the redmapper catalog corresponds to a galaxy in the protoDC2 catalog).
Hence, this PR introduces a
members_only
option so that when the redmapper catalog is used as an "add-on", only the members part is matched to the protoDC2 catalog.This PR fixes #315.