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 thebinning_key
argument.For example, if you were binning subhalos by host halo mass, the
binning_key
argument would behalo_mvir_host_halo
, andhost_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
andhalo_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 thesubhalo_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 thegalaxy_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 ahalo_x
key in theinherited_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 themodel_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
andhost_halo_table
.Methods Documentation
- preprocess_subhalo_table(host_halo_table, subhalo_table)[source]¶
Method makes cuts and organizes the memory layout of the input
subhalo_table
andhost_halo_table
.The only subhalos that will be kept are those with a value in their
halo_hostid
column that matches an entry of thehalo_id
column of the inputhost_halo_table
. The returned subhalo table will be sorted according toself.subhalo_table_sorting_keys
. The returnedhost_halo_table
will be sorted by the first two entries ofsubhalo_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 thehalo_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, thehalo_upid
of a sub-subhalo may point to thehalo_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.