Prior estimation

[JaimeRZP]

Prior Estimation

Background

Currently RAIL has a rich variety of methods to generate p(z)’s for a given survey. Assuming a catalog of objects, RAIL produces these p(z)’s using two modules:

• Estimator: turns a distribution of object properties into a distribution of object photometric redshift
• Summarizer: turns a distribution of object photometric redshifts into a photometric distribution for the sample in the form of a QP file.

Projector aims to be a final module that reads the output of Summarizer and turns the measured p(z) process into photometric uncertainty models with associated priors. These products can later be passed on to Firecrown and CCL to generate theory vectors and perform cosmological inference.
Potential Scientific Impact
Projector will play the role of connecting RAIL to its downstream libraries within the DESC pipeline. Moreover, it will open the possibility for recently proposed analytical marginalization methods for photometric redshift uncertainties.

Design Overview

Currently, Projector is expected to be a library that hosts a series of Python objects called projectors. Projectors will operate in a static manner, performing all their computations upon initialization to ensure replicability within a larger pipeline. Moreover, projectors aim to be a file to file segment that minimizes cross-dependencies across the pipeline.

Projectors should take in the QP representation of the measured photo-z process and project into the space of a given photometric model in terms of a series of parameters. Since photo-z models are in essence parametric representations of a photo-z process, some of the most basic models (such as a moments based model) might already be encompassed within the current methods of QP. Thus, Projector will extensively depend on QP and possibly extend it.

Once the projection has been done, projectors will save their output to a file that can later be picked up by downstream pipelines. This output will take the form of two products:
Priors: a prescription to generate a prior distribution for the parameter of the photo-z model. We are currently in talks with the Firecrown team to ensure compatibility.
Photo-z model: photo-z models will be dynamic functions that take the form of:
f([z, pz], **args) → [z, pz]
Where the args the parameters sampled from the prior distribution generated by the projector class. We want to adhere to this form to ensure that the output is compatible with CCL’s tracers. For now we can host the models in their associated projector class but we might want to merge them into Firecrown later on.

Pros:

• File to file to minimize cross dependencies
• Static workflow that ensures replicability
• Will enable analytical inference methods in the future.

Cons:

• Summarizer sometimes only produces a point estimate of the sample photometric distribution. However, we are interested in saving large numbers of realizations of the process. We will have to ensure this is the case.
• Passing the photo-z models downstream could be challenging until they are properly integrated.

Alternative Designs

Tilman Toester started drafting a similar piece of code a while ago (see LSSTDESC/firecrown@master...qp_nz). The ideas seem rather similar to the ones proposed above with some key differences:
Tilman proposed creating a series of classes in Firecrown called TracerSystematics.
The QP files are passed directly to TracerSystematics which handle the projection onto the particular model upon initialization. This is equivalent to integrating the code described above inside Firecrown.
TracerSystematics also hosts the model method. This solves the issue of passing the model downstream
The priors are sampled from a unit hypercube regardless of the model. The class then defines a Jacobian that transforms the unit hypercube to the chosen prior.
The output is a Firecrown object called TracerArgs which contains the necessary information for CCL to create a tracer.
Pros:

• Solves the problem of passing the phot-z models downstream.
• Less libraries to track/moving pieces.
• No need to specify priors. All handled by the Jacobian.