added implementation for non-linear modeling (WIP)

[paulrogozenski]

Here is a WIP PR for interfacing non-linear modeling between firecrown and CCL, addressing issue #174 developed in parallel to PR 198 with input from @tilmantroester . In this implementation, many subclasses are utilized to inherit the attributes of parent classes used for linear modeling while allowing these subclasses to be distinguishable from linear modeling code. Of particular importance is the SourcePT subclass, which inherits the attributes of the Source class but adds two additional tracers to be used in non-linear modeling scenarios. Additionally, observable-specific sources inherit their parent class attributes, with name changes going from WeakLensing to WeakLensingPT and NumberCounts to NumberCountsPT. No changes to the likelihood functions are made and this implementation is backwards-compatible with previous implementations utilizing linear-only calculations.

In CCL, non-linear calculations return power spectra to be used in later calculations of angular power spectra with nuisance parameters, such as galaxy bias and intrinsic alignment, being implemented within the power spectrum. The power spectra are then used as an input parameter to calculate angular power spectra in then angular_cl function. Three tracers are then created in each SourcePT to retrieve the power spectrum information and to translate it to calculate angular power spectra within the current firecrown framework as follows:

pttracer: contains the tracer as defined in the non-linear code of CCL (pyccl/nl_pt/tracer.py) to compute the relevant power spectra
pt_tracer: contains the tracer as defined in the linear code of CCL (pyccl/tracer.py) to utilize the pt calculated power spectra when calculating angular power spectra
tracer: contains the tracer as defined in the linear code of CCL (pyccl/tracer.py) and contains information that is used only when calculating linear statistics (e.g. magnification bias).

This structure allows for an arbitrary number of linear parameters to be added to the calculation without needing to interfere with the perturbative calculations. The calculation performed in TwoPoint.py is then the linear combination of non-linear and linear effects squared. Caches are implemented in TwoPoint.py to prevent the costly re-calculation of perturbative power spectra, cls, and tracers. A PTCalculator needs to be defined to perform perturbative calculations in CCL, which is passes as an optional parameter to the TwoPoint function and stored for future use. Placeholder optional flags are also included in the TwoPoint function which will indicate whether to use a halo model to calculate the power spectra. This feature is not yet implemented and will return an error.

Attached is a plot showing the angular two-point correlation functions in real space as defined by the des_y1 likelihood with residuals plotted between a direct calculation and that performed in this new pipeline. The residuals indicate that numerical error is the dominant factor in the differences between the direct calculation and the proposed pipeline, being on the order of 1e-7. We include a zero pzshift, non-zero scale arguments, non-zero magnification bias, and non-zero non-linear galaxy bias and TATT parameters in this example.

As this is a WIP, there are superfluous print statements throughout the code which gauges hits to caches, times to calculate angular cls, and other sanity checks. A functioning example is located in firecrown/examples/des_y1_3x2pt/des_y1_simple_TATT.py.

[marcpaterno]

To make it easier for us to review your PR, please consult https://firecrown.readthedocs.io/en/latest/developer_installation.html#before-committing-code to see the set of tests and verifications that the CI system will run when a pull request is created.

Thanks.

[paulrogozenski]

Thank you for the reference. I ran the lines before committing code and the checks have now passed successfully.

[marcpaterno]

We have merged #198 and #232 into the master branch of the repository. After modifications for long-term maintainability, the result is now available as release 1.4.0 (currently on conda_forge).

One of the significant differences we see between your solution and the current solution is that you introduce additional types of sources (e.g. SourcePT) to handle what is done with conditional code in the current solution. We actually prefer your solution here and are likely to move the current code in this direction.

Another significant difference with the current solution is that it puts things like PTCalculators into the ModelingTools class, rather than using them directly in statistics. This helps make sure that the tools used by different parts of the system, e.g. by statistics, are consistent.

Please review this pull request and, if there is functionality that you would like to add to what is already in release 1.4.0, create a new branch and pull request to add that functionality.