Cristina Galoppo Director Médica

Phoenix is a self-consistent, open-box integrated stellar population model of an homogenous spherical elliptical galaxy. It tracks the lifecycles of stars over small mass ranges formed at the same time, calculating the indices such stars would produce from SSP data and luminosity-weighting them to give the expected integrated spectra for comparison to one or more observed galaxies. The model can be used in two different ways. First, a ‘single run’ can be used, to make comparisons with one observed galaxy, with the user setting the free parameters. Second, the entire set of free parameters can be systematically worked through by the code to produce a large number of different models to which the observational galaxy can be compared simultaneously i.e. parameter space can be searched to find the best-fit model. The user selects “single” or “search” when the model is run; either option runs the same model but the output report formats are different. The structure of the model is given in figure 11 below, and further details of the main subroutines are given in section 4.3 and outputs in section 4.4. The full code is presented in Appendix B.

4.1.2 Outline of the Phoenix model

The Phoenix code is written in Fortran 90/95, and uses the subroutines written by the present author for the GCE model as outlined in Chapter 2 for planetary nebulae options and T04 SSPs. Data sources for the model, which can be selected by the user where there is a choice, are given in table 11. Modified and simplified versions of the GCE’s data-reading subroutines were also incorporated into this new model. The remainder of the Phoenix model is entirely new and independent.

This model uses the following structure of galactic evolution:

dMstar /dt = SFR – E (14)

dMgas /dt = -SFR + E + f (15)

Where

SFR = the star formation rate, given by the Schmidt (1959) equation (equation 6) E= mass ejected by stars as gas due to supernova or planetary nebula events f = gas flowing into (+) or out of (-) the galaxy

Free parameters in the Phoenix model: 1 Initial mass of galaxy, in M

2 Overall duration of the galaxy lifetime, in Gyrs

3 Constant C in the Schmidt (1959) equation with Kennicutt (1989) index SFR=Cρ1.3 where ρ = density of gas in galaxy

4 Proportion of initial gas forming Population III stars

5 Time in Gyrs after start of galaxy of the galactic wind OR multiple of stellar mass expelled as galactic wind (gas loading)

6 Rate of gas inflow, in M

/Gyr

7 If applicable: time in Gyrs after start of galaxy when gas inflow starts 8 If applicable: duration of gas inflow in Gyrs.

Table 11: Free parameters in the Phoenix model.

Parameters (table 11) can either be set by the user, or the model can run several times, with the model varying these parameters systematically in each run. The Phoenix model uses a number of data sources from the literature. In some instances, there is a choice which the user can make before running the model.

Process/information required Data source

SNIa ejecta • Nomoto et al. (1984)

SNII yields (adjusted to ejecta)/ejecta (large stars up to 40 M

)

• Woosley and Weaver (1995) (ejecta) • Maeder (1992) (yields)

SNII yields (adjusted to ejecta) (massive stars over 40 M
)

• Meynet and Maeder (2002) Planetary nebulae yields (adjusted to

ejecta)

• Renzini and Voli (1981)

• Van den Hoek and Groenewegen (1997)

• Gavilán et al. (2005)

SNIa rates • Timmes et al. (1995)

• Scannapieco and Bildsten (2005)

Gas inflow composition • Primordial

• Same as current gas composition • Solar

• Twice solar

Isochrones • Bertelli et al. (1994)

Initial Mass Function • Salpeter (1955)

Single run selected: Output results to screen and file for graph plotting

Searching run selected: Output results to file for comparison to all sample galaxies

Subroutine ZERO to initialise arrays, Subroutine GETVALS and GETOBS for user-selected data and galaxy, Subroutine READIN to read all source data

Ask the user whether they wish to run the single or searching version of the code.

Searching run: overwrite parameters from GETVALS with those of the next model

Single run

Initialise the model

W o rk t h ro u g h e a c h ti m e s te p f o r th e g iv e n l if e o f th e g a la x y W o rk t h ro u g h e a c h c o m b in a ti o n o f m o d e l p a ra m e te rs

Evolve the galaxy for one timestep: subroutine EVOLVE

Calculate the synthetic indices for this timesep: subroutine MAKEINDICES

Figure 11: Overview of Phoenix model.

4.1.3 Brief comparison of Phoenix and GCE

As noted in Chapter 1, integrated evolutionary population synthesis models may work on a “top-down” approach, in that they attempt to fit existing SSPs to the observed data, or a “bottom-up” approach of tracking the formation of a modelled galaxy and assessing whether the indices it would produce match the observed data or not. The Phoenix and GCE models both follow a “bottom-up” approach.

As with the GCE, the Phoenix model is only ‘chemical’ insofar as it keeps a track of ejecta to give the overall metallicity, and, where required, a value for [ /Fe],

which in turn selects the appropriate SSP. Neither model builds up the indices from the component elements. The main differences between these two models is that Phoenix, as well as taking note of the issues raised in Chapter 3, tracks the lifetimes of individual stars, enabling the model to use isochrones to calculate the luminosity of each mass bin (and hence enable luminosity-weighting of the indices). The other differences are summarised in table 13.

GCE Model Phoenix

Individual stars modelled? No Yes

Isochrones used to calculate the luminosity weighting?

No Yes

Number of free parameters/number of parameters searched

12/4 8/8

Galaxy volume varies with mass? No Yes

Number of evolutionary processes leading to SNIa

1 2

Single-run and “stepping” runs from same model?

Partially: separate codes are run but call same set of subroutines.

Yes

Options for planetary nebula Was 1, updated to 3 by present author

3

Options for SSPs Was 2, one of

which used corrupted data, updated to 3 by current author 3, including clearing corruption in V99 data Non-solar abundance corrections to SSPs

options

TB95 (only solar) K05 incorporated as an option

None

Radial ranges modelled Yes, but not

accurately: not updated if mass, volume or density are altered No; simple open box model

Chemical composition of inflow Primordial, same as current galaxy or solar Primordial, same as current galaxy, solar or 2 x solar Table 13: Comparison of the GCE and Phoenix models.

4.1.4 Checks built into the model

To check whether the ‘range exceeded’ errors discussed section 3.3 occur, warnings are written into the model. These appeared on screen during testing and have since been diverted to an output file, ‘warnings.out’. This allows the user to view each instance where the data required by the model is not available and the nearest value has been used instead. The impact on the final output can then be evaluated in its proper context. It is important to note that results from Phoenix reported in this thesis as successful did not generate any warnings.

Limitations in ejecta data from the literature are an inherent problem with this type of model; by giving a range of options for the yield/ejecta data, the importance (or otherwise) of these limitations can be assessed. For example, the results using each of the three options for planetary nebulae yields do not vary much, despite the different approaches used in each of the models of RV81, vdH&G97 and G05. Limitations in yield/ejecta data are discussed in more detail below (4.2.13).

The model runs self-consistency checks to verify how much, if any, is “lost” due to Fortran precision limitations (2.3.2), and makes corrections by adding rounding values to the largest component (for example, if the gas is mostly hydrogen, then the calculated adjustment is made to hydrogen), and self- consistency checks are also output to the results file. Consequently, there will be a slight alteration to the overall proportions held as hydrogen/helium/metals, or held as gas/stars (etc) but these are not significant and should not affect the overall results produced.

As the code was written, each section was tested in isolation. For some parts of the code, this was done by overwriting parameters, running that section of the code and then verifying the output against the source data (for example, fixing the model’s metallicity to test that the correct data is picked up from the table). For other parts, the output was compared to values separately computed with a calculator or on spreadsheets.

4.2 ASSUMPTIONS, SIMPLIFICATIONS AND LIMITATIONS IN THE