Difference between revisions of "April 12, 2019"
(Created page with "= April Updates = == Status of the Project == Alex and I have settled on an ideal way to deal with the photometric redshift uncertainties on the RedMaPPer (RM) cluster data....") |
|||
| Line 4: | Line 4: | ||
Alex and I have settled on an ideal way to deal with the photometric redshift uncertainties on the RedMaPPer (RM) cluster data. The plan is to divide everything into fairly small redshift slices, corresponding to around 30 Mpc. For each slice, I'll make a projected number density map with the CMASS galaxies. (They have very low redshift uncertainties so they are essentially guaranteed to truly exist in that slice.) For every RM cluster, the catalog provides not only the calculated mean photo-z but also the probability distribution of photo-z. Therefore, for each redshift slice, I'll take every RedMaPPer cluster that has any probability of being in that slice (including those whose mean photo-z falls in another slice), and run these through COOP to get the orientation vector for each cluster. For example, if a cluster's photo-z probability extends over the z=.2 to .21 slice, the z=.21 to .22 slice, and the z=.22 to .23 slice, I will run this cluster with the orientation map for each of those bins and get 3 orientations out. Finally, I'll write my own stacking code which, for a single redshift slice of 30Mpc, stacks all the clusters that could possibly exist somewhere in that slice, orients them with the imported COOP orientations, and weights each cluster by the probability that it exists in that slice. (That probability is the area under the photo-z curve within that slice). With this method, we can do oriented stacks for reasonably small redshift slices and fully account for the uncertainties in the photometric redshifts of clusters. | Alex and I have settled on an ideal way to deal with the photometric redshift uncertainties on the RedMaPPer (RM) cluster data. The plan is to divide everything into fairly small redshift slices, corresponding to around 30 Mpc. For each slice, I'll make a projected number density map with the CMASS galaxies. (They have very low redshift uncertainties so they are essentially guaranteed to truly exist in that slice.) For every RM cluster, the catalog provides not only the calculated mean photo-z but also the probability distribution of photo-z. Therefore, for each redshift slice, I'll take every RedMaPPer cluster that has any probability of being in that slice (including those whose mean photo-z falls in another slice), and run these through COOP to get the orientation vector for each cluster. For example, if a cluster's photo-z probability extends over the z=.2 to .21 slice, the z=.21 to .22 slice, and the z=.22 to .23 slice, I will run this cluster with the orientation map for each of those bins and get 3 orientations out. Finally, I'll write my own stacking code which, for a single redshift slice of 30Mpc, stacks all the clusters that could possibly exist somewhere in that slice, orients them with the imported COOP orientations, and weights each cluster by the probability that it exists in that slice. (That probability is the area under the photo-z curve within that slice). With this method, we can do oriented stacks for reasonably small redshift slices and fully account for the uncertainties in the photometric redshifts of clusters. | ||
| − | However, re-writing and re-organizing my code to do this will be a long enough task that I won't be able to do it by the end of 1501. For the rest of the 1501 time period, I'll simply take slices of 100 Mpc, make number density maps with all the CMASS galaxies in those slices, and assume that the RM clusters' photo-zs are accurate. | + | However, re-writing and re-organizing my code to do this will be a long enough task that I won't be able to do it by the end of 1501. For the rest of the 1501 time period, I'll simply take slices of 100 comoving Mpc, make number density maps with all the CMASS galaxies in those slices, and assume that the RM clusters' photo-zs are accurate. |
== Example Plots of CMASS Sample == | == Example Plots of CMASS Sample == | ||
Revision as of 18:15, 12 April 2019
April Updates
Status of the Project
Alex and I have settled on an ideal way to deal with the photometric redshift uncertainties on the RedMaPPer (RM) cluster data. The plan is to divide everything into fairly small redshift slices, corresponding to around 30 Mpc. For each slice, I'll make a projected number density map with the CMASS galaxies. (They have very low redshift uncertainties so they are essentially guaranteed to truly exist in that slice.) For every RM cluster, the catalog provides not only the calculated mean photo-z but also the probability distribution of photo-z. Therefore, for each redshift slice, I'll take every RedMaPPer cluster that has any probability of being in that slice (including those whose mean photo-z falls in another slice), and run these through COOP to get the orientation vector for each cluster. For example, if a cluster's photo-z probability extends over the z=.2 to .21 slice, the z=.21 to .22 slice, and the z=.22 to .23 slice, I will run this cluster with the orientation map for each of those bins and get 3 orientations out. Finally, I'll write my own stacking code which, for a single redshift slice of 30Mpc, stacks all the clusters that could possibly exist somewhere in that slice, orients them with the imported COOP orientations, and weights each cluster by the probability that it exists in that slice. (That probability is the area under the photo-z curve within that slice). With this method, we can do oriented stacks for reasonably small redshift slices and fully account for the uncertainties in the photometric redshifts of clusters.
However, re-writing and re-organizing my code to do this will be a long enough task that I won't be able to do it by the end of 1501. For the rest of the 1501 time period, I'll simply take slices of 100 comoving Mpc, make number density maps with all the CMASS galaxies in those slices, and assume that the RM clusters' photo-zs are accurate.