abacusorg / abacusutils

Python code to interface with halo catalogs and other Abacus N-body data products

Home Page:https://abacusutils.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

implement power spectrum tests against nbodykit

lgarrison opened this issue · comments

@boryanah added power spectrum computation routines in #65 (thanks!). We should add tests against nbodykit to the repo. Since #65 is closed, we can discuss and track progress here.

Responding to #65 (comment):

The code already looks fairly modular to me, but I agree the Pk stuff could go in its own file. And we could probably even make a new abacusnbody/clustering/ directory for the CF and Pk files, since they're in the hod dir right now but are useful beyond just HOD.

For the tests, you can just make test_power.py where the rest of the tests are. The mini sim has halos, particle subsamples, and particle slices; you can use any of these as the input data set.

test_power.py will look like:

from pathlib import Path

import pytest
from astropy.table import Table
import numpy as np

from common import check_close

curdir = Path(__file__).parent
refdir = curdir / 'ref_power'
EXAMPLE_SIM = curdir / 'Mini_N64_L32'
NBODYKIT_POWER = refdir / 'nbodykit_power.csv'

def test_power():
   '''Compare power spectrum against the saved nbodykit result
'''
    # TODO: this is all pseudo-ish code
    ref_power = Table.read(NBODYKIT_POWER)

    from abacusnbody.hod.power import compute_power

    pos = # load your dataset
    pk_paraks = { } # deltak, etc

    abacus_power = compute_power(pos, **pk_params)

    assert check_close(abacus_power['k'], ref_power['k'])
    for i in range(n_mubins):
         assert check_close(ref_power[i]['power'], abacus_power[i]['power'])

You can just run your nbodykit script locally and then save the result in a CSV file in the repo. That way the CI doesn't have to install/run nbodykit. But you can save it as tests/generate_nbodykit_power.py so someone else can run it in the future if needed.

I agree, it's probably worth matching the binnings between the codes. I usually find that checking the number of modes in each bin is the best way to confirm that the binnings are the same. In theory, the results should match very closely!

As you point out in the comments, there's opportunities for optimization/parallelization that could be done in the future, so it's important to get the tests in place before that work!

Resolved in pull request #68