Non-limber integration support in angular c_ell calculation.#505
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #505 +/- ##
=======================================
Coverage 100.0% 100.0%
=======================================
Files 50 50
Lines 4680 4775 +95
Branches 516 532 +16
=======================================
+ Hits 4680 4775 +95
🚀 New features to boost your workflow:
|
|
@marcpaterno or @vitenti can you give me quick comments on this? This seems to be quite a small change (and important for DESC). Let me know if I am missing something I should still develop. |
| np.array(ells), | ||
| p_of_k_a=p_of_k_a, | ||
| l_limber=l_limber, | ||
| p_of_k_a_lin=p_of_k_a_lin, |
There was a problem hiding this comment.
Should we always use the linear matter power spectrum (delta_matter:delta_matter) here, regardless of the tracers involved?
There was a problem hiding this comment.
Yes, I believe so. This is also how it is implemented in CCL. From the CCL documentation, this is only used with PT tracers, which need the linear matter power as input. The tracer specific calculations are encoded in the tracer objects.
There was a problem hiding this comment.
There could in principle be corner cases (e.g. non-Limber for tSZ or something) where that might not be true but I wouldn't worry about this at this point. If necessary, there could be a calculate_lin_pk function for such cases but I can't think of a realistic use case now.
| self.cluster_abundance = cluster_abundance | ||
| self.cluster_deltasigma = cluster_deltasigma | ||
| self.ccl_factory = CCLFactory() if ccl_factory is None else ccl_factory | ||
| self.non_limber_max_ell = non_limber_max_ell |
There was a problem hiding this comment.
Implementing it this way gives us a global value for non_limber_max_ell here. Is that always the case, or are there situations where non_limber_max_ell should vary depending on the tracer combination?
There was a problem hiding this comment.
While different tracer combinations might have different sensitivity to the limber approximation, I think it is safe to have this ell-limit extend to the whole two-point correlation the user requests. The method should be fast enough that this should not be a problem. If we find such a roadblock in the future, we can think of changing this but I think it's unlikely.
There was a problem hiding this comment.
Well... if possible, in the future, it would be useful to support turning limber to some of the tracers. While we do want non-limber for something like clustering (both spec and potentially photo) it may not be that important for the weak lensing tracers... But for now, just being able to get this option would be increadible!
There was a problem hiding this comment.
(But: we need to check that if what I said about WL and non-limber is true...)
Support for ClIntegrationOptions serialization and tests.
|
Hello @chrgeorgiou, @arthurmloureiro and @tilmantroester, I’ve expanded the integration options to better cover the relevant CCL API. I also moved the integration control from ModelingTools to TwoPointFactory, which I believe offers more flexibility while remaining straightforward to use. You can find the updated documentation here: Let me know if you agree with this direction. |
Organizing fixtures.
…to non_limber_support
marcpaterno
left a comment
marcpaterno
left a comment
There was a problem hiding this comment.
@chrgeorgiou I've looked through this PR and it seems good to me. Since @vitenti has made some significant additions, please verify that it still satisfies your needs.
…n of conda-incubator/setup-miniconda@v3).
5 participants
Description
Adds support for non-limber integration for angular power spectra in the two-point correlation.
Fixes #504
Type of change
Checklist:
The following checklist will make sure that you are following the code style and
guidelines of the project as described in the
contributing page.
bash pre-commit-checkand fixed any issues