SubhaloPhaseSpace

class halotools.empirical_models.SubhaloPhaseSpace(gal_type, host_haloprop_bins, inherited_subhalo_props_dict={'halo_id': ('halo_id', 'i8'), 'halo_mpeak': ('halo_mpeak', 'f8'), 'halo_vx': ('vx', 'f8'), 'halo_vy': ('vy', 'f8'), 'halo_vz': ('vz', 'f8'), 'halo_x': ('x', 'f8'), 'halo_y': ('y', 'f8'), 'halo_z': ('z', 'f8')}, binning_key='halo_mvir_host_halo', intra_halo_sorting_key='halo_mpeak', reverse_intra_halo_order=True, **kwargs)[source]

Bases: object

Class using subhalo information to model the phase space of satellite galaxies.

For a demonstration of typical usage, see the Tutorial on Modeling HOD Satellites Using Subhalo Positions.

Parameters:
gal_typestring

Name of the modeled galaxy population, e.g, ‘satellites’.

host_haloprop_binsarray_like

Array used to bin subhalos into groups of a similar property, e.g., host halo mass. The host_haloprop_bins argument defines the bin edges. The user must also provide the column name storing the property that should be binned. This column name should be provided with the binning_key argument.

For example, if you were binning subhalos by host halo mass, the binning_key argument would be halo_mvir_host_halo, and host_haloprop_bins could be np.logspace(10, 15, 15).

The purpose of host_haloprop_bins is to address the possibility that the desired number of satellites in a halo may exceed the number of subhalos in the halo. In such a case, randomly selected subhalos from the same bin are chosen.

binning_keystring, optional

Column name defining how the input subhalos will be grouped together by some host halo property such as virial mass. Default is halo_mvir_host_halo.

intra_halo_sorting_keystring, optional

Column name defining how the subhalos will be sorted within each host halo. Subhalos appearing first are preferentially selected as satellites. Default is halo_mpeak. This argument should be used together with reverse_intra_halo_order.

reverse_intra_halo_orderbool, optional

If set to True, subhalos with larger values of the intra_halo_sorting_key will be the first in each halo to be assigned galaxies. If False, preferential assignment goes to subhalos with smaller values. Default is True, for compatibility with the more typical properties such as halo_mpeak and halo_vpeak.

inherited_subhalo_props_dictdict, optional

Python dictionary determining which properties the modeled galaxies will inherit from their corresponding subhalo. Each key of the inherited_subhalo_props_dict dictionary gives the name of a column in the subhalo_table that you wish to inherit. The value bound to each key is a tuple of two strings. The first string specifies the name you would like to give the inherited property in the galaxy_table. The second string specifies the data type of the column, e.g., ‘f4’ or ‘i8’. For example, suppose you wish to treat the x-position of the subhalo as the x-position of your satellite galaxy. Then you would have a halo_x key in the inherited_subhalo_props_dict dictionary, and the two-element tuple bound to it would be (‘x’, ‘f4’).

Default value is set by the default_inherited_subhalo_props_dict variable in the model_defaults module.

Methods Summary

inherit_subhalo_properties([seed])

preprocess_subhalo_table(host_halo_table, ...)

Method makes cuts and organizes the memory layout of the input subhalo_table and host_halo_table.

Methods Documentation

inherit_subhalo_properties(seed=None, **kwargs)[source]
preprocess_subhalo_table(host_halo_table, subhalo_table)[source]

Method makes cuts and organizes the memory layout of the input subhalo_table and host_halo_table.

The only subhalos that will be kept are those with a value in their halo_hostid column that matches an entry of the halo_id column of the input host_halo_table. The returned subhalo table will be sorted according to self.subhalo_table_sorting_keys. The returned host_halo_table will be sorted by the first two entries of subhalo_table_sorting_keys.

Parameters:
host_halo_table = table
subhalo_table = table
Returns:
processed_subhalo_tabletable

Astropy Table of subhalos with a matching host_halo, sorted according to self.subhalo_table_sorting_keys.

Notes

The requirement of having a matching host halo is the basis of the algorithm, and this is implemented by requiring that each subhalo’s halo_hostid column has a matching value in the halo_id column of the input. The reason that such subhalos could exist at all is if they are part of a larger system that is just merging into a still larger host halo. In such a case, the halo_upid of a sub-subhalo may point to the halo_id of a subhalo that has just fallen into a larger host, so that the center of the sub-subhalo has not quite passed within the virial radius of its ultimate host. These subhalos are very rare, and are thrown out to make bookkeeping simpler.