-
Notifications
You must be signed in to change notification settings - Fork 30
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
red sequence colors (mean, scatter) as a function of redshift #41
Comments
Many of the differences are due to different filters, and also due to noise in the training from the small volume. But I'm not sure how much. |
looping in parties who might be interested: @rmandelb @evevkovacs @abensonca @katrinheitmann @j-dr |
Should we consider adding matching DES filters for DC2 to remove that source of discrepancy? |
@abensonca So that would be an additional 8 filters to calculate. I think it would depend on how many WGs would be interested in DES magnitudes, and whether we need them for validation. |
Agreed - we should only add them if this is useful for validation. |
@erykoff @j-dr - can you please return to this issue of red sequence color validation? In particular, we need to converge on:
Thanks! |
I think this actually supersedes #40 for CL. It's going to be a lot of extra work to write a test for this that isn't just comparing the red-sequence as inferred from redmapper to either DES or SDSS if @erykoff thinks that we can't use the DES data. Unless there are strong objections, I think we should go with the redmapper-centric test. I already have some code to make these comparisons that I can implement in DESCQA. The most important aspect to validate here is the scatter in the red-sequence, since this will largely set the redmapper photo-z errors. This has the added benefit of being relatively insensitive to bandpass. The exact shape of the mean red-sequence is not as important, since redmapper self-calibrates. @erykoff should chime in if he thinks otherwise though. |
I think it should be fine to compare against DES data from year 1, I'll confirm this. As @j-dr says the most important thing is the scatter in the red sequence, and secondarily to this the slope in the color-redshift relation. (If it's flat, it doesn't matter how tight the scatter is, you can't measure redshifts). The overall color doesn't matter, nor do the exact positions of the filter transmissions. The requirements depend on the redshift range: g-r for z<~0.5, r-i and i-z for the full redshift range. I'm not sure what the best way to quantify agreement in scatter is: within 1-2%? Or a percentage offset (of a scatter)? Any thoughts would be welcome. |
@j-dr -
That's fine, but other groups still want #40 so we can't drop it (sadly). I will, however, try to remember not to bother you in that one! @erykoff -
Thanks for checking. I think the approach we should take will depend on the answer to this; do you think you'll know by mid-next week? That would enable implementation on hack day. (might one of you be interested in doing that?) |
Yes, it does. Redmapper is already run on the current version of protodc2, but it will need to be run again once the updated protodc2 is made available. |
What's the status on providing a mask to allow users/test-developers to select the redmapper galaxies? Do you still think that it is worthwhile making this mask as a way for people to access the sample? |
@erykoff have made some plots on red sequence colors (mean, scatter) as a function of redshift for protoDC2 and compared them with DES data.
@erykoff, can you share your plots here, and then we can continue to make a validation test from what you have done?
The text was updated successfully, but these errors were encountered: