This PR introduces the following overhaul to the phase_space_models sub-package:

• Complete restructuring of the internal organization of halotools.empirical_models.phase_space_models. All user-facing functions maintain backwards compatibility. In this PR there are no changes to the API or behavior of existing classes or functions, just internal refactoring to facilitate future extensions.
• There are two new classes, halotools.empirical_models.BiasedNFWPhaseSpace and halotools.empirical_models.SFRBiasedNFWPhaseSpace that allow model galaxies to have biased NFW concentrations and jeans solutions. CC @johannesulf for this particular new feature.

The behavior of BiasedNFWPhaseSpace and SFRBiasedNFWPhaseSpace is summarized in the docstrings. The summary below is included mostly for posterity. Since the behavior of halotools.empirical_models.NFWPhaseSpace has not changed, Halotools end-users do not need to know anything about this internal refactoring.

Overview of internal refactoring

In previous Halotools versions, there was a complicated chain of multiple inheritance that made it needlessly complicated to extend the behavior of existing classes. This has been largely refactored away. There was short-term motivation for this change: to make it easier to include (and test) the new BiasedNFWPhaseSpace and SFRBiasedNFWPhaseSpace classes. These changes should make it simpler and more naturally compartmentalized to add new models in the future.

• The empirical_models.phase_space_models package has now been split into two sub-packages, analytic_models and subhalo_based_models.

phase_space_models/analytic_models
phase_space_models/subhalo_based_models

The analytic_models and subhalo_based_models directories share no common code, as they implement functions and algorithms that bear no relation to each other. The subhalo_based_models sub-package is unchanged from v0.4.

• The new analytic_models sub-package is organized as follows:

analytic_models/monte_carlo_helpers.py
analytic_models/profile_model_template.py
analytic_models/halo_boundary_functions.py

analytic_models/centrals/
analytic_models/centrals/trivial_phase_space.py

analytic_models/satellites/
analytic_models/satellites/nfw
analytic_models/satellites/nfw/nfw_phase_space.py
analytic_models/satellites/nfw/biased_nfw_phase_space.py
analytic_models/satellites/nfw/sfr_biased_nfw_phase_space.py

analytic_models/satellites/nfw/conc_mass
analytic_models/satellites/nfw/conc_mass/dutton_maccio14.py
analytic_models/satellites/nfw/conc_mass/direct_from_halo_catalog.py
...
analytic_models/satellites/nfw/kernels
analytic_models/satellites/nfw/kernels/mass_profile.py
analytic_models/satellites/nfw/kernels/unbiased_isotropic_velocity.py
...

All non-trivial mathematical operations are now carried out in stand-alone kernels modules requiring only Numpy and Scipy. With the newly refactored code, the user-facing objects such as NFWPhaseSpace are now largely state-managers that simply call the stand-alone Numpy kernels in a manner consistent with the state of the attributes of the instance, e.g., nfw_model.cosmology and nfw_model.redshift. Most of Halotools v0.5 is now built based on this design principle.

Overview of old and obsolete structure

This PR replaces the old structure, summarized here for posterity:

phase_space_models/nfw_phase_space.py
phase_space_models/trivial_phase_space.py

phase_space_models/profile_models
phase_space_models/profile_models/profile_model_template.py
phase_space_models/profile_models/nfw_profile.py
phase_space_models/profile_models/conc_mass_models.py

phase_space_models/velocity_models/
phase_space_models/velocity_models/isotropic_jeans_model_template.py
phase_space_models/velocity_models/nfw_isotropic_jeans.py

• The NFWPhaseSpace class no longer multiply subclasses from an unseen ConcMass class defined in the conc_mass_models.py module. Instead, the constructor of NFWPhaseSpace accepts a conc_mass_model argument storing a user-defined callable function, or a nickname for one implemented in Halotools.

• The NFWPhaseSpace class no longer multiply subclasses from an unseen NFWIsotropicJeans class defined in isotropic_jeans_model_template.py. Instead, NFWPhaseSpace implements its own new methods governing the velocity modeling (again, implemented by simply calling the externally-defined NFW jeans velocity kernels with the appropriate arguments).

• To model the mass density and velocity profiles, the kernels of all non-trivial NFW calculations are carried out in small, stand-alone modules with only Numpy and Scipy dependencies. This design choice has several advantages:

  1. It makes it easier for others to hack Halotools and cannibalize it for parts.
  2. It makes unit-testing simpler, because the input to the Numpy kernels are just plain arrays passed as positional arguments, not requiring an elaborate state preparation.
  3. It minimizes side effects caused by "hidden" class attributes storing some possibly forgotten, previously-assigned state

The big picture of this refactoring is to keep with the general design direction in v0.5 to minimize class inheritance and treat classes as essentially state managers, rather than objects that perform involved calculations.