Giter VIP home page Giter VIP logo

n5k's Introduction

N5K: Non-local No-Nonsense Non-Limber Numerical Knockout

First round instructions

Skip this if you've already submitted an entry. The deadline for these was almost 1 year ago anyway!! Go to "Second round". In this challenge, you are asked to compute a set of power spectra for a 3x2pt (cosmic shear, galaxy-galaxy lensing, and galaxy clustering) analysis without the use of the Limber approximation.

The challenge entries will be evaluated on the basis of accuracy, speed, and integrability with the Core Cosmology Library (CCL). CCL is python (with some heavy-lifting done in C under the hood); a code which is in python or has a python wrapper will satisfy the integrability criteria. Given this, the code which can accomplish the challenge task fastest and within the accuracy requirements of an LSST Y10 cosmological analysis will win the challenge. The winning code will be incorporated for use as the non-Limber integration tool for CCL.

All entrants will have the opportunity to be an author on the resulting paper, which will describe the challenge, compare the different methods, detail the results, and discuss lessons learned.

How to enter

The challenge asks you to compute the angular spectra required for a 3x2pt analysis setup similar to the LSST Y10 scenario in the LSST DESC Science Requirements Document v1. The 'input' folder of this repo contains some required inputs for this calculation:

For the purposes of the challenge, we ignore intrinsic alignments, redshift-space distortions, and magnification. The kernels are thus number counts and cosmic shear only.

calculator_base.py contains a base class N5KCalculatorBase. Write a subclass of N5KCalculatorBase which contains methods setup() (to set up your nonlimber calculation), run run() (to run it) and teardown() (to clean up any dirt you've created). Only the run() method will be timed (but don't be cheeky!). calculator_ccl.py contains an example of what this would look like doing the calculation using CCL's current (Limber) calculation tools. If you need to modify the challenge machinery (e.g. the base class itself or other provided files), you must make a separate pull request to do this (i.e. don't do it in your challenge entry pull request).

Specifically, the non-Limber integral to be computed for each element of the angular power spectrum is,for clustering:

for cosmic shear:

and for galaxy-galaxy lensing (assuming quantities labeled with '1' are associated with shear and '2' with number counts):

where K is in each case the kernel for the appropriate tracer (as provided in input/kernels_fullwidth.npz) and is the non-linear matter power spectrum. You should assume that .

Make a pull request to this repository which includes your new subclass as well as a script which creates the conda or virtualenv environment in which your entry can run. Remember, if you need to modify the provided common code, like the base class, make a separate PR!

If you choose to use given dN/dz's instead of the precomputed full kernels, it is your responsibility to ensure other required cosmological factors are correctly computed using the parameters defined in the base class.

Second round instructions

All entries have now been merged into master, with slight modifications (none to the base code) to help us run all entries on the same scripts. We have run 3 tests:

  1. Compute time as a function of number of OpenMP cores.
  2. Compute time as a function of number of bins.
  3. Goodness of fit (Delta chi^2) as a function of bin width.

Besides these, we want to quantify:

  1. Time as a function of goodness of fit for the following target Delta chi^2s on ell<200: (0.2, 0.7, 1.2, 1.7).

You have privately received our first results regarding tests 1, 2, and 3 above. For this we used the run_timer.sh, run_timer_nbins.sh and run_benchmarks.sh scripts respectively, which themselves use the configuration files conf/conf_<entry>.yml. These were run on an interactive node on Cori.

For this last round we'd like to ask you to:

  • Give us instructions (if needed) for how to optimize the results of tests 1-3 above. For this, you may tell us on slack, make modifications to the code in a PR, or send us new configuration files.
  • Send us configuration files/settings for test 4.

Note that, as we mentioned originally, parallelization is not a priority for this, so do not worry if the results of test 1 are underwhelming for your code. Still, it'd be good if you can tell us which part of the code are parallelized, which ones could be parallelized but aren't, and which ones can't be parallelized.

Deadline

The deadline for this second round is February 4th, 2022 (17:00 PST).

FAQ

Can I participate if I am not a member of DESC?

Yes, you can, and you can be an author on the paper (we have a special exemption from the Publication Policy for this challenge).

We request that all non-DESC entrants agree to abide by the DESC Code of Conduct throughout their participation in the challenge (as DESC entrants are also expected to do).

What is the accuracy level I should be aiming for?

The required accuracy level will be calculated as that which introduces a spurious which is less than 1 for an LSST Y10 3x2pt analysis as defined in the SRD, computed using a Gaussian covariance matrix. The precise tolerable error for a representative set of will be posted before the challenge deadline for comparison but is not yet available.

Can I precompute some stuff and put that calculation in my setup() method?

The thing we care about is how long it takes at each step in a sampling process. So you should put in your run() method anything that would need to be rerun at each step in e.g. an MCMC chain. Precomputations which are independent of the parameters that would get varied in that process can go in setup().

How many cores will the calculation be run on for timing?

The thing we care about is being able to do this calculation at each step in a parameter inference sampling process. This usually means a single core for a single theory calculation, of which the Non-Limber integration forms one step. So assume a single core.

Can I assume the availability of GPUs?

If you can convince us that your GPU method can be easily integrated with the rest of the DESC parameter inference pipeline and can be run on GPU resources that DESC will definitely have access to, go for it. Otherwise, no.

n5k's People

Contributors

c-d-leonard avatar damonge avatar schoeneberg avatar tilmantroester avatar xfangcosmo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

n5k's Issues

Clarification on kernels and bias

Just to confirm, the bias is NOT included in the kernels right? I was naively expecting it was, and that the problem was literally to solve the integral from the README:
image
but from a quick test, looks like I need to include the bias for the clustering probe if I want to match CCL.
Can the organizers confirm?

Because I cheated and looked at what @tilmantroester was up to, it looks like he made the same assumption and is not loading the bias.

Bessel functions of high order

Both GSL and boost seem to struggle with Bessel functions of high order (ell>200 or so). GSL is a bit more verbose and gives underflow errors, while boost quietly ignores that issue unless one sets the policy to explicitly throw errors on under/overflows. Since the current setup requests ells up to 2000, this might be a common problem.

Has anyone compared GSL or boost against asymptotic forms (e.g., https://dlmf.nist.gov/10.57)?

Number of modes calculation

I have a questions about these lines in calculator_base:

    def get_ells(self):
        return np.unique(np.geomspace(2, 2000, 128).astype(int)).astype(float)

    def get_dlog_ell(self):
        return np.log(2000/2)/128

Is the second function consistent with the first? If the first function just returned np.geomspace(2, 2000, 128) it would be close (but should be /127 instead of /128?)

However, with the rounding to the nearest integer, values of dlog_ell are non-uniform and quite a bit larger at low ell:

ells = np.unique(np.geomspace(2, 2000, 128).astype(int)).astype(float)
dlog_ell = np.gradient(ells)/ells
plt.plot(ells, dlog_ell, 'r.')
plt.axhline(np.log(2000/2)/127)

dlog_ell

Since dlog_ell is used to calculate the number of modes per ell, which feeds directly into the final chisq calculation, are we perhaps downweighting ell < 10 too much?

Analysis wrap up

This issue is just a to-do list of what we need to do to wrap up the analysis of the challenge:

  • Run fiducial runtime and signal to noise tests, get agreement between 2-3 people.
  • Run test of scaling of time vs number of auto- and cross-corrs, get agreement between 2 people.
  • Run test of scaling of time vs required delta chi^2, get agreement between 2 people (prereq still needed: accuracy settings from Levin and FKEM entries.)
  • Finalise benchmarks for quarter and half bin width.
  • Run test of scaling of accuracy vs bin width, get agreement between 2 people.
  • Run test of scaling of time vs number of cores / nodes (parallelisability test).
  • Figure out why Tassia is getting a different Levin runtime from Danielle / David.
  • Iterate with entry authors for any last tweaks following the results of these tests.
  • Finishing writing up draft.

CCL version?

Using the main branch of N5K and the latest CCL from conda-forge, example_benchmark.py fails with:

Traceback (most recent call last):
  File "example_benchmark.py", line 18, in <module>
    cal_lm.setup()
  File "/Users/david/Cosmo/DESC/N5K/N5K/n5k/calculator_ccl.py", line 14, in setup
    self.cosmo = ccl.CosmologyCalculator(Omega_c=par['Omega_m']-par['Omega_b'],
AttributeError: module 'pyccl' has no attribute 'CosmologyCalculator'

I guess I need to install CCL from source to pickup the new CCL calculator mode? I don't see instructions for that here but should python setup.py install work?

Artefacts in benchmark Cls

This is to discuss some potential artefacts in the benchmark Cls. This applies to the clustering auto-correlations, especially at high redshift.

  1. At large ell (~ell>1000), the benchmark Cls don't seem to agree with the Limber approximation:
    cl_gg_9-9
    This is Cl_gg 9-9; in blue: CCL Limber; orange: independent non-Limber/Limber implementation by @rreischke.
    In this case, the region of ell > 1000 contributes ~25% to the SNR, so can't just be ignored.

  2. ell = 2 looks weird:
    cl_gg_9-9_abs
    Again Cl_gg, 9-9. The ell = 2 mode contributes about 40% to the SNR.

Policy on interpolation in ell and Limber fallback

What is the policy on not calculating the non-Limber integral?

For example

  • Interpolating between a lower number of multipoles than those requested
  • Using Limber approximation based on heuristics, such as ell or overlap of kernels
  • etc

Basically, would CCL decide where to use the non-Limber code for non-Limber calculations or is it the job of the non-Limber code to make the decision of whether to use the exact calculation or some approximation?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.