halomod/hmfcalc

Django web-application for calculating the halo mass function

halomod

halomod is a python application that provides a flexible and simple interface for dealing with the Halo Model of Dark Matter Halos, built on hmf.

It also has a full-feature web application at https://thehalomod.app -- check it out!

Full Documentation

Read the docs.

Features

• All the features of hmf (several transfer function models, 15+ HMF fitting functions, efficient caching etc.)
• Extended components for halo model:
  • 10+ halo bias models, plus scale-dependent bias from Tinker (2005).
  • 3+ basic concentration-mass-redshift relations, including the analytic Bullock (2001) model
  • Several plug-and-play halo-exclusion models (including ng-matched from Tinker+2005).
  • 5+ built-in HOD parametrisations.
  • Many built-in halo profiles, including NFW, generalised NFW, Hernquist etc.
  • Support for WDM models.
• All basic quantities such as 3D correlations and power spectra, and projected 2PCF.
• Several derived quantities (eg. effective bias, satellite fraction).
• All models/components specifically written to be easily extendable.
• Simple routine for populating a halo catalogue with galaxies via a HOD.
• CLI script for producing any quantity included.

Usage

halomod can be used interactively (for instance in ipython or a jupyter notebook) or in a script. To use interactively, in ipython do something like the following:

>>> from halomod import HaloModel
>>> hm = HaloModel()  # Construct the object
>>> help(hm)          # Lists many of the available quantities.
>>> galcorr = hm.corr_auto_tracer
>>> bias = hm.bias
>>> ...

All parameters to HaloModel have defaults so none need to be specified. There are quite a few that can be specified however. Check the docstring to see the details. Furthermore, as halomod extends the functionality of hmf, almost all parameters accepted by hmf.MassFunction() can be used (check its docstring).

To change the parameters (cosmological or otherwise), one should use the update() method, if a HaloModel() object already exists. For example

>>> hm.update(rmin=0.1,rmax=1.0,rnum=100) #update scale vector
>>> corr_2h = hm.corr_2h_auto_tracer #The 2-halo term of the galaxy correlation function

Since HaloModel is a sub-class of MassFunction, all the quantities associated with the hmf are also included, so for example

>>> mass_variance = hm.sigma
>>> mass_function = hm.dndm
>>> linear_power = hm.power

Any parameter which defines a model choice (eg. a bias model) is named <component>_model, so for example, the bias model is called bias_model. Every model has an associated parameter called <component>_params, which is a dictionary of parameters to that model. The available choices for this dictionary depend on the model chosen (so that the Sheth-Tormen HMF has a different set of parameters than does the Tinker+2008 model). Within the constructed object, the actual model is instantiated and saved as <component>, so that this object can be accessed, and several internal methods can be called. Some of these are exposed directly by the HaloModel class (eg. one can call hm.n_sat directly, which itself calls a method of the hm.hod component).

Using the CLI

You can also run halomod from the command-line. For basic usage, do:

halomod run --help

Configuration for the run can be specified on the CLI or via a TOML file (recommended). An example TOML file can be found in examples/example_run_config.toml. Any parameter specifiable in the TOML file can alternatively be specified on the commmand line after an isolated double-dash, eg.:

halomod run -- z=1.0 hmf_model='SMT01' bias_model='Tinker10'

Acknowledgments

Thanks to Florian Beutler, Chris Blake and David Palamara who have all contributed significantly to the ideas, implementation and testing of this code.

Some parts of the code have been adapted from, influenced by or tested against:

• chomp (https://github.com/JoeMcEwen/chomp)
• AUM (https://github.com/surhudm/aum)
• HMcode (https://github.com/alexander-mead/HMcode/)

Along with these, several other private codes have been compared to.

Attribution

Please cite

1. Murray, Power and Robotham (2013) and/or https://ascl.net/1412.006 (whichever is more appropriate)
2. Murray, Diemer and Chen (2020)

if you find this code useful in your research. Please also consider starring the GitHub repository.

hmfcalc's Issues

model parameter info

At the moment, there is no way to specify min/max values for model parameters. This should be set to provide better validation.

Output file units

The column identifiers in downloaded files don't retain the information that masses are in M/h and densities are (Mpc/h)^3

Upgrade to Python3

Because.

installation problems

Hi i was following the instructions to install. I was able to install pycamb as well numpy etc. when i tried to install hmf i ran into trouble. apparently there is a problem
with finding cosmolopy.perturbation

Downloading/unpacking hmf
Downloading hmf-1.1.9.tar.gz
Running setup.py egg_info for package hmf
Traceback (most recent call last):
File "", line 16, in
File "/private/var/folders/xz/79m2f5z95_xcwnqjr7xncy2r0000gn/T/pip-build-dspolyar/hmf/setup.py", line 2, in
from hmf.hmf import version
File "hmf/init.py", line 1, in
from hmf import Perturbations
File "hmf/hmf.py", line 20, in
import tools
File "hmf/tools.py", line 27, in
import cosmolopy.perturbation as pert
ImportError: No module named cosmolopy.perturbation
Complete output from command python setup.py egg_info:
Traceback (most recent call last):

File "", line 16, in

File "/private/var/folders/xz/79m2f5z95_xcwnqjr7xncy2r0000gn/T/pip-build-dspolyar/hmf/setup.py", line 2, in

from hmf.hmf import version

File "hmf/init.py", line 1, in

from hmf import Perturbations

File "hmf/hmf.py", line 20, in

import tools

File "hmf/tools.py", line 27, in

import cosmolopy.perturbation as pert

ImportError: No module named cosmolopy.perturbation

---

Cleaning up...
Command python setup.py egg_info failed with error code 1 in /private/var/folders/xz/79m2f5z95_xcwnqjr7xncy2r0000gn/T/pip-build-dspolyar/hmf
Storing complete log in /Users/dspolyar/.pip/pip.log

Initial values for model parameters

At the moment, if two models for the same component have parameters of the same name, their initial form value will be whatever gets loaded last. This could lead to very strange results when someone uses the not-last model and doesn't actively set the parameter. This could probably be fixed by namespacing them more tightly.

Default cosmology acts strangely

Something is wrong with the js which alters the cosmological parameters. Fix.

[11] appears twice in data output

Need to fix.

planck15

put Planck+15 as the new default

sensitivity to CAMB parameters for high-z and/or low mass halos

hmf results seem to be sensitive to some CAMB parameters, e.g., k_per_logint and kmax, whose defaults may not be suited to high redshifts and low halo masses.

I've included a short script that shows the issue, made using hmf version 3.0.3 and camb version 0.1.7. Also, if "p.set_matter_power" is called without arguments (or even its default arguments), the results change, implying that a default MassFunction instance is perhaps not equivalent to a MassFunction instance created with a default CAMBparams object?

Note that this should be recoverable with earlier versions of hmf that used pycamb, though be aware that the relevant parameters have since changed names (from transfer__k_per_logint and transfer__kmax), and were previously passed into MassFunction via transfer_params as a simple dictionary rather than a CAMBparams instance.

Here's the test script:

import camb
from hmf import MassFunction
from matplotlib import gridspec

gs = gridspec.GridSpec(2, 1, height_ratios=[2, 1])
ax0 = pl.subplot(gs[0])
ax1 = pl.subplot(gs[1])

p = camb.CAMBparams()
p.set_matter_power(kmax=100)   # sensitive to k_per_logint as well

# These are the defaults
#p.set_matter_power([0.0], kmax=1.2, k_per_logint=None, nonlinear=None,
#    accurate_massive_neutrino_transfers=False, silent=False)

mf1 = MassFunction(Mmin=6)
mf2 = MassFunction(Mmin=6, transfer_params={"camb_params":p})

colors = ['k', 'b', 'g', 'm']
for i, z in enumerate([0, 3, 6, 10]):
    mf1.update(z=z)
    mf2.update(z=z)

    ax0.loglog(mf1.m, mf1.ngtm, color=colors[i], ls='-', label=r'$z={}$'.format(z))
    ax0.loglog(mf2.m, mf2.ngtm, color=colors[i], ls='--', lw=3)

    ax1.semilogx(mf1.m, mf2.ngtm / mf1.ngtm, color=colors[i])

ax0.legend(loc='lower left', fontsize=12)
ax0.set_ylim(1e-12, 1e5)
ax0.set_ylabel('ngtm')
ax1.set_ylabel('new/default')
ax1.set_xlabel('mass')
ax0.set_xticklabels([])

Improve logging so that errors can actually be fixed

At this point, the logging is generally insufficient to actually fix anything, or know what the user is seeing. This should be fixed.

Upgrade to hmf 3

Also, because.

merge changes in hmf 3.1

hmf 3.1 has better project structure, and better halo definition

Range slider initial values

At the moment, the range slider(s) don't get initial values properly.