Skip to content
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

Closed
2 of 4 tasks
yymao opened this issue Dec 7, 2017 · 13 comments · Fixed by #101
Closed
2 of 4 tasks

red sequence colors (mean, scatter) as a function of redshift #41

yymao opened this issue Dec 7, 2017 · 13 comments · Fixed by #101

Comments

@yymao
Copy link
Member

yymao commented Dec 7, 2017

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

  • code to reduce mock data
  • code that works within DESCQA framework
  • validation data
  • validation criteria
@erykoff
Copy link

erykoff commented Dec 7, 2017

pdc2_des_imz_scatter
pdc2_des_imz_mean
pdc2_des_rmi_scatter
pdc2_des_rmi_mean
pdc2_des_gmr_scatter
pdc2_des_gmr_mean

@erykoff
Copy link

erykoff commented Dec 7, 2017

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.

@yymao
Copy link
Member Author

yymao commented Dec 7, 2017

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

@abensonca
Copy link

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

@evevkovacs
Copy link
Contributor

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

@abensonca
Copy link

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

@rmandelb
Copy link

rmandelb commented Feb 1, 2018

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

This was referenced Feb 1, 2018
@j-dr
Copy link
Contributor

j-dr commented Feb 1, 2018

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.

@erykoff
Copy link

erykoff commented Feb 1, 2018

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.

@rmandelb
Copy link

rmandelb commented Feb 2, 2018

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

@yymao
Copy link
Member Author

yymao commented Feb 14, 2018

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

@j-dr
Copy link
Contributor

j-dr commented Feb 14, 2018

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.

@evevkovacs
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants