R AMSES code modifications

Code snippets of our RAMSESpatches are found in the appendix. We will briefly discuss the new

modules and the modifications of existing modules. Stellar model database

The modulegeneva_models(Code ListingC.2) contains the tabulated mass loss and26_{Al data of}

Ekström et al. (2012) as well as feedback energiescomputed as explained in Sect.2.7.3 andSN

data as described in Sect.2.7.4. Moreover, it provides a routine to convert all feedback data to the units used in the simulation, an output routine and a routine for linear interpolation in the feedback tables which can also add up feedback for several stars.

Feedback region and mask

However, the subroutine read_driver(lines 56-213) in the moduledriver (Code ListingC.1) can also read in stellar feedback from an ASCII table and convert it to code units. This is used for example for the Voss et al. (2009) population synthesis models. The subroutine read_sn(lines 214-291) in this module reads tabulated SNdata. The allocated driver arrays can be deallocated with the subroutinesremove_driver(lines 292-309) andremove_sn(lines 310-324). This mod- ule also comes with a routine for linear interpolation of the read-in tables (interpolate_driver, lines 325-376). The subroutineadd_SN(lines 377-403) searches forSNexplosions occurring dur- ing the present time-step and returns the mass and energy feedback.

5.2 Implementation of mass, momentum and energy feedback 93 We now need to find the region into which the stellar feedback will be injected. This will be done with a mask: We define an array that tells us, how much of the cell’s volume lies inside the

feedback region: 0.0 for cells fully outside thefeedback region, 1.0 for cells fully contained in the region and a number between 0.0 and 1.0 for cells partly inside. For the latter case we use the fraction of randomly generated positions in the cell that lie inside thefeedback region. For 1D or 2D we also have a subroutine which calculates the volume fractions analytically.

To flag the feedback region, the subroutine allocate_driver_mask (Code Listing C.1, lines 404-588) uses theFORTRANderived data typedriver_mask(lines 38-51). This object contains the number of cells along thefeedback regionradius (plus one), the cell size, the actual volume of thefeedback regionfound via Monte-Carlo which slightly differs from 4πr3

3 and an n-dimensional

mask for a volume containing the feedback regionplus approximately one cell in each direction. The size of the boundary layer is not exactly one cell in each direction, since the center of the

feedback regiondoes not have to be aligned with the grid. Of course, placing thefeedback region

center asymmetrically on the grid does not sound like a wise choice for a star in a homogeneous cloud. However, the idea behind this implementation is that at some point our simulations will contain multiple stars, represented by thefeedback regions, which will have proper motions. The routine now allocates the array driver1 of such objects with as many entries as grid lev- els and fills it with data. The module contains two functions that read data from this object:

get_driver_volume(lines 589-598) can read the actual volume and get_driver_mask(lines 599-655) can look up how much a given cell overlaps with the feedback region. Since RAM- SESalways loops over the grids byvector sweeps, the subroutinedriver_weights_fixed(lines

671-726) does this look up for a whole array of dimension(1:ngrid). Before RAMSES exits,

driver1has to be deallocated. This is done by the subroutinedeallocate_driver_mask(lines 656-670). For moving feedback regions, it might be advantageous to find cells belonging to the

feedback regionon the fly. This can be done with subroutinedriver_weights(lines 727-857). If the stellar feedback is inserted as kinetic energy, the subroutinedriver_vector(lines 858-981) finds radial vectors. Finally subroutineprint_xyz(lines 982-1061) helps to find out in which cell the code encounters a problem. The module also contains a routine with analytic weights for 2D simulations.

Calls to the feedback routines

These two new modules now have to be called by RAMSES. The feedback parameters are stored

in amr_parameters.f90 (Code Listing C.3). These parameters can be set in the namelist and are read-in by read_params.f90 and read_hydro_params.f90 (Code Listing C.4 and C.5). The mass and energy injection of the star(s) are taken into account if the run time parameter

nstars in the namelist(an example is shown in Code Listing C.27) is larger than zero. In this case, the code will add the newly emitted mass (total mass and radioactive tracers) and the internal energy (unresolved kinetic wind energy, radiation pressure) to the density resp. energy in thefeed- back region. The size and location of this feedback regionare set using the run time parameters

r_driver,x_driver, y_driverandz_driverin thenamelist. The feedback data is loaded in

init_time.f90(Code ListingC.6). If the run-time parameterifgenevais set to.true. in the

namelist, the model grid, the stellar masses and the star formation times in the run-time parameters

genevayear, mstarsandtstarsare used. Otherwise the code searches for tabulated feedback data. The data file names are stored infile_driver (default: wind.dat) andfile_sn(default: sn.dat). After every time step, courant_fine.f90 (Code ListingC.7) calls the feedback inter-

polation routine. It also uses the weights of the mask to identifyfeedback regions. Moreover, it takes care of the decay of26_{Al and}60_{Fe. If thepreprocessor directive CARINA is used, the feed-} back subroutinewind uses sequential star formation. Thepreprocessor directiveEKIN switches between compiling the code for kinetic energy feedback or code where the feedback is inserted mainly as thermal energy. The preprocessor directive TMIN ensures that the total energy is al- ways larger than the kinetic energy. Further preprocessor directives are TMAX, which sets a maximal temperature (used for tests only), DECAYINTERVAL and KAHANBABUSKA that avoid problems with number precision in the tracer decay and in large sums, and THII which sets T = 10.000 Kelvin in the feedback region. Finally the feedback arrays are deallocated by

clean_stopinupdate_time.f90(Code ListingC.8).

To control the adaptive mesh refinement in the feedback region we patched flag_utils.f90

and hydro_flag.f90 (Code Listing C.9 and C.10). This is advantageous since too low refine- ment leads to x-shaped outflows whereas very high resolution leads to bouncing waves inside the

feedback regionwhich can be computationally costly. Radiative cooling in a multi-phase ISM

The standard treatment of cooling and heating processes in RAMSES is discussed in Sect. 2.2.6.

For our simulations we used two modified versions of cooling_module.f90. One version is shown in Code Listing C.19, the other one has been described by Ntormousi et al.(2011). The latter contains cooling tables generated with theCLOUDYcode. In the version shown in Code List- ing C.19, thepreprocessor directiveartificial_ISM (lines 416-447) establishes a warm phase by using a density dependent temperature floor. We need this, since we want two stable thermal phases in our simulations: a cold cloud and a warm, diluteISM. Cells, which are undisturbed by stellar feedback should neither cool nor heat. For our production runs, we used the version ofNtor- mousi et al. (2011), but tests with the artificially stable ISM showed that the dense bubble shell will always loose almost all its thermal energy and cool to the equilibrium temperature (i.e. the minimum temperature in the artificially stableISM). Hence thefeedback energy efficiencyof both cooling modules was of similar order. It turned out that mixing across the contact discontinuity

has a very strong influence on thefeedback energy efficiency.

We patchedcooling_fine.f90(Code ListingC.18) to switch off cooling in thefeedback region. Technically, this is implemented with a mask. All cells inside thefeedback regionplus a layer with a width set by coolplus in the driver parameters in thenamelistdo not suffer radiative cooling losses.

Since our simulations focus on the feedback energy efficiency, it is important for us to be able to monitor the energy losses via radiative cooling. We thus store the loss during the last time step for every cell. Since we do not want this array to be advected like a passive scalar, we store it at

nvar+1. To do this, we increase the array size ininit_hydro.f90(Code ListingC.14). To avoid loosing the data during memory defragmentation, we also patched load_balance.f90 (Code ListingC.15). The losses per time step are analyzed inoutput_hydro.f90(Code Listing C.16) and re-set inamr_step.f90(Code ListingC.17).

Initial conditions

Patches tohydro_parameters.f90(Code ListingC.11) andinit_flow_fine.f90(Code List- ing C.12) enabled us to set the initial distribution of radioactive tracers and to read in SPH data. For this purpose we also wrote the module sph(Code Listing C.13). Thepreprocessor directive

5.2 Implementation of mass, momentum and energy feedback 95 JIM uses the settings for the SPH data provided by Jim Dale (ISM structures in the simulations presented inDale and Bonnell,2011). If it is not defined, the data format of the SPH data provided by Clare Dobbs (molecular clouds in the simulations presented inDobbs et al.,2011) is used. Other patches

Additionally we have set default units inamr_commons.f90(Code ListingC.22). These defaults can be overwritten by different choices in the namelist. Since some of our simulations (namely the simulations with stellar feedback into the clouds of Clare Dobbs (Dobbs et al.,2011)) observe energy flowing out of the computational box, we monitored such energy losses with the new mod- ule inoutflow.f90(Code ListingC.23). Finally we often re-started our simulations and thus we patchedinit_amr.f90(Code ListingC.20) since RAMSESdoes not allow to change the initially

chosen output times, which is quite inconvenient for re-simulations when the initial simulation showed an interesting phase in the model’s evolution that should be analyzed in more detail. Our version ofgodunov_utils.f90(Code ListingC.21) removes outflows from almost empty cells. It can also ignore almost empty cells when theCFL(sect3.3) is evaluated. For the HLLC solver, the preprocessor directive ALUSTOP only allows the radioactive tracers to flow into cells with temperatures above a temperature threshold.

To stabilize our simulations we also avoid negative internal energies in set_uold (Code List- ing C.24, godunov_fine.f90). We remove outflows from almost empty cells and reset the pressures in these cells in subroutine godfine1 (Code Listing C.24, godunov_fine.f90) and subroutinectoprim(Code ListingC.25,umuscl.f90). godunov_fine.f90can also be used to reset the cooling losses.

The Makefile in Code ListingC.26summarizes the newly definedpreprocessor directives.