Tuesday, August 20, 2013

Galacticus v0.9.2 Released

We're happy to announce the release of Galacticus v0.9.2. As usual, you can get Galacticus direct from our repo at BitBucket, just use:

hg clone -u v0.9.2 https://abensonca@bitbucket.org/abensonca/galacticus

to grab v0.9.2, or you can download a source tarball. v0.9.2 becomes the stable version (supported and will receive bug fixes), v0.9.1 becomes deprecated (no longer supported and will not receive bug fixes) and development moves to v0.9.3.

In addition to the usual complement of bug fixes and minor improvements, this release sees a complete re-write of Galacticus' internal representation of galaxies and their halos. While this has no visible consequences for running Galacticus models, it makes the code much cleaner and greatly simplifies the process of adding new components to galaxies. Components are now specified by a domain specific language - essentially a simple description of the components properties. Galacticus' build system then takes care of generating classes and associated functions for the new component and all of its properties. This saves ~30,000 lines of code which would otherwise have to be written by hand!

In addition to this, there are a few other additions and improvements worth mentioning.

New components

We've added a component which tracks the statistics of recent halo mergers, and another which tracks averages of quantities (currently star formation rates) between successive outputs. Additionally, the merging statistics component now also reports the original depth of each halo in the structure formation hierarchy.


We now make use of nested parallelism to speed up various calculations, including the integration of stellar population SEDs, tabulations of stellar recycling rates and metal yields, and numerical solution to the excursion set problem.

Stellar luminosities

An implementation of the Charlot & Fall (2000) model for dust extinction is now available.

The framework for postprocessing of stellar spectra has been made much more flexible, allowing for different chains of postprocessing filters to be applied to each luminosity computed. This allows, for example, calculation of a luminosity after absorption by the IGM, and the same luminosity after absorption by the IGM but including only light emitted in the past 100Myr for example.

New filters have been added, including a Lyman continuum, HST ACS and WFC3, Herschel SPIRE, Spitzer IRAC, UKIRT J & H, and CCAT SWCam and LWCam filters.


We've updated to interface with the latest versions of Cloudy (13.02) and FSPS (2.4).


The survey output module now supports output of angular diameter distances, angular positions, and distance modulus.

The rotation curve and velocity dispersion of galaxies can be output at arbitrary radii (defined as absolute radii, multiples of galaxy scale lengths, or radii enclosing a specified fraction of mass or light).


We've added support for dark energy cosmologies with equation of state w(a) = w0 + w1 a (1-a).

Internal calculations of the density, enclosed mass, etc. at any point in a galaxy now fully account for adiabatic contraction of the dark matter profile. This allows the  "Cole2000" merger remnant size calculation to be fully consistent with what Cole et al. (2000) actually do.

Critical overdensity for halo collapse and halo virial density contrast can now be computed using the Kitayama & Suto (1996) fitting formula. This is less accurate than a numerical solution, but also faster.

A simple cooling radius model which assumes and isothermal density profile and cooling rate proportional to density squared has been added. This allows for an analytic calculation of cooling radius (so can be useful for fast models).

Tree building

We've added a new merger tree constructor, "fullySpecified", in which the full specification of a merger tree (including all properties of components) is read from an XML document. This is extremely useful for setting up idealized test calculations.

Reading of merger trees from file (usually N-body merger trees) now supports the full complexity of possible tree configurations, including handling of halos which never existed as isolated halos, processing of "forests" of connected merger trees, subhalos which jump between branches of the tree, and subhalos which escape their halo to become isolated halos once again.

Grasil interaction

Grasil is now downloaded as needed, and an analysis module allows calculation of the luminosity under any specified filter to be computed from Grasil spectra.

What to expect in Galacticus v0.9.3

Along with many under-the-hood improvements, and a few minor physics and interface improvements (more realistic hot halo profiles, better handling of subhalo merger times in N-body trees, ability to read merger trees in the IRATE format), v0.9.3 will also introduce tools to construct mock images of galaxy samples from Galacticus, and a complete framework for deriving detailed and accurate constraints on Galacticus model parameters from observed datasets.

Tuesday, May 14, 2013

Support for dark energy cosmologies added to Galacticus

Galacticus has recently (v0.9.2 revision 1809:c3577bea7b39) added support for more general dark energy cosmologies. It's always supported dark energy in the form of a cosmological constant, but since we don't know what dark energy is, it's useful to be able to explore more general equations of state.

Specifically, Galacticus can now compute models in which the equation of state of dark energy has the form:

w(a) = w0+w1a(1-a)

where a is the cosmological expansion factor, and w0 and w1 are adjustable parameters ("darkEnergyEquationOfStateW0" and "darkEnergyEquationOfStateW1" in a Galacticus parameter file).

The effects of dark energy are accounted for in computing the expansion history of the universe, the critical overdensity for collapse of spherical perturbations, and the density contrast of virialized dark matter halos (see the nice review by Percival 2005 for details).

To add dark energy to a model, simply add the following to an input file:




The present day density in dark energy is still set by the usual Omega_DE parameter.

The effects of the dark energy equation of state are small, but noticeable. This figure shows the stellar mass function of galaxies at z=0.07 for three different dark energy models1. For the highest mass galaxies there are small differences as the dark energy equation of state is varied.

1 The model isn't a perfect match to the data (from Li & White 2009). I'm working on that......

Tuesday, February 5, 2013

Rotation Curves

With the latest updates to Galacticus it's now possible to output rotation curves for all galaxies in a model, including the effects of adiabatic contraction on the dark matter profile. This will allow more realistic comparison with measures of the dynamical properties of observed galaxies - such as the Tully-Fisher relation - which are often measured at a specific radius (e.g. 2.2 times the disk radius).

To output rotation curve data, add the following to a Galacticus parameter file:



The first option tells Galacticus to output rotation curves. The second parameter specifies which contributions to the should be counted rotation curve and at what radii. These specifiers break down as follows:


radiusType specifies which radius in the galaxy we're referring to. In the above we specified that radii will be given in units of the disk radius. We could have also used, diskHalfMassRadius, spheroidRadius, spheroidHalfMassRadius, darkMatterScaleRadius, virialRadius, or just radius (which implies radii are given in units of Mpc). The actual radius at which the rotation curve will be output is given by the radius value.

componentType specifies which components of the galaxy+halo should be counted. Currently allowed values are all, disk, spheroid, hotHalo, darkHalo, and blackHole.

massType specifies which types of mass should be counted. Currently allowed values are all, dark, baryonic, galactic, gaseous, stellar, and blackHole.

The loading? option should be either loaded or unloaded, and specifies whether the effect of baryonic loading (i.e. adiabatic contraction) should be included in the calculation of the rotation curve.

Using these specifiers you can request rotation curves at any radius, and get the contribution from any subset of galaxy or halo components. In the above example, we requested the rotation curve at 2.2 times the disk radius, and asked for the contribution from all components. In the first entry we requested the baryonic contribution to the rotation curve, including adiabatic contraction. In the second and third entries we requested the dark matter contribution to the rotation curve, first with and then without the effects of adiabatic contraction.

By outputting at many different radii, you can build up a full rotation curve. For example, here's the result for a roughly L* galaxy at z=0, plotted using scripts/plotting/plotRotationCurve.pl

It shows quite nicely how the rotation curve stays relatively flat out to large radii, and how this results from the interplay of disk and (adiabatically contracted) dark matter contributions.

Saturday, January 19, 2013

Dust Absorption and Emission Spectra with Grasil

Galacticus can compute the spectrum of light emitted by stars in each model galaxy, and the resulting magnitude in any band. But, this spectrum accounts for absorption by dust in only a very simplistic way, and makes no accounting for re-emission of light from dust grains.

But, by coupling Galacticus with the Grasil code it's possible to compute  spectra of galaxies with a detailed model of dust extinction and re-emission, including the effects of a distribution of dust grain types and sizes, fluctuating grain temperatures, emission from polycyclic aromatic hydrocarbons (PAHs), and radio emission from supernova remnants.

We've recently made it much easier to perform these Galacticus+Grasil calculations in v0.9.2 of Galacticus, and added a short tutorial to the Galacticus documentation explaining how to do this.

Briefly, just add:


to the Galacticus parameter file. This causes Galacticus to store the entire star formation history of each galaxy, as a function of time and metallicity. (The tutorial explains how to tune the details of how star formation histories are stored.) These star formation histories are used by Grasil to compute the emission arising from stellar populations of different ages.

Then, using Galacticus' standard analysis package, simply load the Galacticus::Grasil module and ask for a property such as "grasilFlux850microns", to get the flux (in Janskys) at any wavelength. An example code snippet to do this looks like:

use Galacticus::HDF5;
use Galacticus::Grasil;

my $galacticus;
$galacticus->{'file' } = "galacticus.hdf5";
$galacticus->{'store'} = 0;
$galacticus->{'tree' } = "all";
&HDF5::Get_Parameters        ($galacticus                         );
&HDF5::Select_Output         ($galacticus, 2.0                    );
&HDF5::Get_Datasets_Available($galacticus                         );
&HDF5::Get_Dataset           ($galacticus,['grasilFlux850microns']);

print $galacticus->{'dataSets'}->{'grasilFlux850microns'}."\n";

When this code is run, Grasil will be run (and automatically downloaded if necessary) on each galaxy. Where possible (i.e. if you have many cores available), multiple copies of Grasil will be run simultaneously. The full SED as a function of wavelength and inclination will be stored to the Galacticus model file for future use (which is convenient as Grasil models typically take tens of seconds to run), and the requested flux computed and returned.

Once SEDs have been computed in this way they can be extracted and examined. A simple plotting script (scripts/plotting/plotGrasilSpectrum.pl) is provided which makes plots like this:

which nicely shows the attenuated stellar emission at short wavelengths, PAH emission in the ~10um region, thermal emission from dust at ~100um and synchrotron emission above 1mm.

Thursday, January 10, 2013

Enhanced N-body Merger Tree Handling

In addition to generating its own merger trees, Galacticus can read trees from file and process them to populate each tree with galaxies. Typically, these merger trees have been extracted from an N-body simulation.

The original implementation of processing such trees in Galacticus had some limitations - which were necessary to make the trees fit with certain assumptions made in the way in which Galacticus processes trees as it creates and evolves galaxies. This processing modified the structure of trees and so could affect the resulting physical properties of galaxies.

We've just finished some improvements to v0.9.2 of Galacticus which remove these assumptions and allow N-body trees to be handled without the need to modify them in any way1.

The original, simplified trees always looked something like this:

Subhalos (orange circles) were supported, but once a halo became a subhalo, it had to stay a subhalo forever. Also, subhalos could never move between branches of the tree (or between different trees). Furthermore, there was no way for a subhalo to exist unless it had, at some point, a non-subhalo (i.e. isolated halo; green circles) progenitor.

This last point is now fixed, allowing tree configurations such as this:

in which a node begins its life as a subhalo, having never had a progenitor2.

The second improvement was to allow "branch jumps", in which a subhalo jumps to another branch as shown below:
This can happen if the subhalo becomes unbound from its host (or, perhaps, was never bound), leaves the host and travels to a new host.

The final improvement was to allow subhalos to become isolated halos once again, as in the following tree:

Obviously, these are highly simplified trees - trees extracted from typical N-body simulations often have ~100,000 nodes and much more complicated structure.

It's worth stating briefly Galacticus' philosophy regarding merger trees read from file. Galacticus assumes that the trees are "correct" - that is, whatever the nodes in the tree do, it should be treated as real, physical behavior3. This means that if you put garbage in, you'll get garbage out! Therefore, the input merger trees should be as realistic as possible - typically this means processing them to remove numerical artifacts as much as is possible. This approach seems to be the only reasonable one - Galacticus doesn't know enough about the simulation, halo finding, or merger tree construction algorithms used to create a particular set of trees to intelligently figure out if the trees are physically reasonable. That's left as a task for whoever builds the trees.

Technically, these improvements involved modifying Galacticus to allow arbitrary numbers of "events" to be attached to each node of the merger tree. An event object simply specifies the time at which the event occurs, a paired node involved in the event, and a function to handle the event when it occurs. This allows the evolution of nodes in merger trees to be "locked" until any dependent events have occurred - even if those events occur in other merger trees. Currently, two types of event are handled. The first type are "branch jumps", in which a subhalo jumps from one host halo to another. The second event type is "subhalo promotion" in which a subhalo stops being a subhalo and becomes an isolated halo.

1 The new code has been tested by running on the entire set of trees from the Millennium Simulation which contain a total of 800 million halos. These contain a lot of edge cases and halos doing things you wouldn't expect - Galacticus now handles all of these cases robustly. If you try running Galacticus on trees from some other simulation and find problems - let us know!

2 Such an "initial subhalo" won't do anything interesting at present - it has no way to accrete gas and so can't form a galaxy. That could change in future though, and, in any case, the presence of the subhalo is important as it may interact gravitationally with other subhalos and galaxies.

3 Some modification of the tree is possible within Galacticus. For example, you can tell Galacticus to prune branches of the tree below a mass threshold (if you think that the trees are not reliable below that mass scale for example).