red sequence colors (mean, scatter) as a function of redshift about descqa HOT 13 CLOSED

from descqa.

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.

from descqa.

looping in parties who might be interested: @rmandelb @evevkovacs @abensonca @katrinheitmann @j-dr

from descqa.

Should we consider adding matching DES filters for DC2 to remove that source of discrepancy?

from descqa.

@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.

from descqa.

Agreed - we should only add them if this is useful for validation.

from descqa.

@erykoff @j-dr - can you please return to this issue of red sequence color validation?

In particular, we need to converge on:

• an approach to validation in detail - what calculations need to be run? (I gather Eli may have run redmapper and done some plots comparing colors against DES using code external to DESCQA?)
• who is implementing this within DESCQA?
• what is the validation data? Can we use the DES data that Eli used in his plots?
• what is the validation criterion? We should be careful to make allowances for differences in bandpasses between DES and protoDC2.
• is this a required test?

Thanks!

from descqa.

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.

from descqa.

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.
In any event, it would be easy to run the redMaPPer training + measure richnesses on halo centers on the new proto2dc2 catalog which would give us all the info we need.

from descqa.

@j-dr -

I think this actually supersedes #40 for CL.

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 -

I think it should be fine to compare against DES data from year 1, I'll confirm this.

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?)

from descqa.

@j-dr @erykoff can you confirm if this test is also one that requires redMapper run?

from descqa.

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.

from descqa.

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?

from descqa.