P LUTO code modifications

Code ListingB.15shows a minimal implementation of a constant stellar wind. In this code snippet, we see two different methods to insert a constant wind with a terminal velocity of108_{cm s}−1 _and

a mass loss rate of 3×10−5 _M

per year. Thepreprocessor directives(#ifdef-directives) in lines

22-24 switch between no wind (neither THERMALWIND nor INFLOWING_WIND defined), kinetic or thermal energy input. According to these choices, lines 140-181 either insert the thermal energy of the wind inside the domain or use the wind’s kinetic energy in an inflow boundary condition. In the rest of Code Listing B.15 we see the definition of the units (lines 53-55), the specific heat ratio (line 57) and theinitial conditions (a homogeneous cloud, lines 59-63). In the latter the velocities are not shown, since they are also set to zero in the default template forinit.c. Time dependent stellar feedback

Code ListingB.16 shows the implementation of a time dependent stellar wind with a subsequent

SNexplosion ininit.c. Again, we define feedback modes (lines 15-22), set the code units and global parameters (lines 54-62) as well as the initial conditions (lines 78-83) where we added

6_{Some authors call this phenomenon “artificial jets”.}

7_{The free streaming region is not removed from the efficiency plots. After 1 Myr the free streaming region of a} 60Mstar in an∼100cm−3 contains∼2%of the kinetic energy. Its share of thermal energy is larger than2%[no

5.2 Implementation of mass, momentum and energy feedback 91 a tracer to monitor energy losses via radiative cooling. Lines 85-97 contain code for tests with viscosity andSNe with linear velocity profiles. These lines are not used in our “standard models”. Lines 113-138 take care of reading in old models. The new computational volume is typically larger than the volume in the read-in simulation. Therefore all cells are initialized with our desired

initial conditionsand only the cells present in the old simulation are overwritten with the read-in data. In the boundary conditions routine (lines 155-390) we use the tabulated wind data. This routine calculates thefeedback regionvolume (lines 194-214). The kinetic energy feedback (lines 215-236) is similar to the aforementioned constant wind. Lines 241-276 can merge cells, if the

mean free path becomes larger than a grid cell length. This part of the code was only used for tests, not for production runs. In lines 278-372 we finally find the time dependent stellar feedback. The routine first checks, if aSNexplosion is due (lines 278-280). If this is the case, it either adds the SN ejecta derived from theEkström et al. (2012) final masses or a canonical value of 3M

(lines 292-304). Which one of these twoSNmodels is used, depends on thepreprocessor directive

GENEVA. Lines 311-315 reduce the time step length shortly before theSN. If theSNis not due yet, and the Geneva stellar evolution models (Sect.2.7.1, data fromEkström et al.,2012) are used, the code interpolates in the table (line 319). In lines 324-329 the code evaluates the cavity size and adds a SN explosion if a pre-defined bubble size is reached before the time when the SNwould be due. This was used for consistency checks withTenorio-Tagle et al.(1990) who use a constant wind and add the SNexplosion when a given cavity size is reached. Lines 346-355 add the time dependent wind and lines 355-367 add a constant wind.

The interpolation routine is shown in lines 391-472. Basically, we read in a table when this in- terpolation routine is called for the first time (lines 409-430). Then we do a binary search in the table (lines 439-469) and use the time step length, the code units and the desired feedback region

volume to get mass and energy densities (lines 469-470). Calls to the feedback routines

The code in boundary.c (Code Listing B.1) checks if there is still a massive star that has not exploded and calls UserDefBoundary from Code Listing B.16 if it has not been done yet for this time step. This check is necessary since the predictor corrector scheme would add the stellar feedback several times (twice for RK2 and three times for RK3) otherwise.

pluto.h(Code ListingB.8) now also contains a global variable for the time of theSNexplosion and theSNroutine and the wind table look-up are listed inprototypes.h(Code ListingB.9). Radiative cooling in a multi-phase ISM

The RAMSEScooling-heating module ofNtormousi et al.(2011), which is discussed in Sect.5.2.3,

has been ported and merged with the PLUTOcooling table. This is shown in Code ListingB.10of

radiat.c. However, from Code ListingB.3 it can be seen that we do not use radiative cooling inside thefeedback region and that we have moved the minimal temperature check to Code List- ingB.10. Moreover we created an artificial equilibrium for the1 000K models in the cooling table

Code ListingB.2. Other patches

The patches in Code ListingB.6(input_data.c) help us restarting the simulation: Our strategy is to start with a small box, but before the shock can reach the boundary, we restart the simulation

and add more cells of unperturbed medium. This increase of the simulation volume is carried out when a minimal number of unperturbed cells (i.e. cells with zero velocity, initial density and initial pressure) is reached. This is not visible in the source code since this process is controlled with a shell script (Code Listing B.20). The minor patch in Code Listing B.11 takes care that after a restart with a larger volume the output files are still numbered consecutively. Basically, this only makes post-processing of the data easier. Code ListingB.12 only got some additional debugging output. Our modifications in Code Listing B.13 avoids outflows from already empty cells. Code ListingB.7shows our modification of the minimal pressure and minimal density. This patch was needed due to the very strong gradients in our models. Code Listing B.14 shows, at which place the thermal conduction coefficient can be modified. It also shows that we do not use thermal conduction in thefeedback region. Code ListingB.4indicates at which place the viscosity can be changed. In Code ListingB.5we added new units and limits.

Typical code settings for our models are shown in Code Listing B.18. An example of pluto.ini

containing run-time parameters can be found in Code Listing B.17. Code Listing B.19shows an example for a post processing routine.