Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
CRONOS-Setup for Planetary Nebulae Felix Niederwanger, BSc. June 16, 2014 Abstract This thesis covers the first steps of the implementation of a full 3D radiative- hydrodynamics simulation for the evolution of a planetary nebula (PN) envelope. The underlying framework is CRONOS, a fully parallel hydrodynamics framework (C++, OpenMPI) allowing the user to choose different Riemann solvers and limiters. The setup is based on a roadmap with clear defined milestones. Each milestone consists of a implementation and additional test cases, to ensure numerical stability and physical correctness. The inner region where the central star of the planetary nebula (CSPN) lives is blanked out and considered as additional boundary condition. Starting from an isothermal stellar wind with gas pressure as the only force the work covers the advance towards a full energetic treatment of a double-wind model that interact on a artificial cold disk with a high density contrast. This was the ultimate stage reached within this work and is designed in a way to advance further to the full simulation of the evolution of a PN. A full radiative-hydrodynamics simulation is far beyond the bounds of a MSc. thesis, this work covers the first steps toward the full setup. A detailed outlook and considerations about the next steps toward the full simulation are discussed in a separate chapter. Danksagung Ich widme diese Arbeit meinen Eltern Martha und Martin Niederwanger, die mich während meiner Tätigkeiten im Studium immer tatkräftig unterstützten. Ich bedanke mich an dieser Stelle bei Ihnen für die finanzielle Grundlage, welche diese Arbeit erst ermöglicht hat und den menschlichen Beistand, den sie mir bei meinem Weg durch das ganze Studium geleistet haben. Großer Dank gilt meinem Betreuer Stefan Kiemeswenger, der trotz eines Wegs nach Chile immer Zeit gefunden hat, mich bei Fragen oder Problemen zu unterstützen und weiter zu helfen. Auch der Arbeitsgruppe, die mich ebenso unterstützt und motiviert hat möchte ich großen Dank aussprechen. Allen voran möchte ich dabei Silvia Öttl danken, die mir mit Rat und Tat stets aktiv weiterhalf und bei Fragen immer zugegen war. Ohne eine solch fruchtbare Umgebung wäre diese Arbeit nicht in dieser Zeit fertig geworden. Ich bedanke mich des weiteren bei Ralf Kissmann für die zahlreichen Hilfestellungen beim CRONOS-Code und bei unserem Systemadministrator Josef Schafer für die zahllosen hilfreichen Einwände und Hinweise. Es sind noch zahlreiche weitere Personen beteiligt, welche aufzuzählen ein Ding der Unmöglichkeit ist. Allen Freunden und Kollegen gilt ein besonderer Dank, die mich in dieser Zeit auch wieder an die schönen Dinge des Lebens erinnert haben. Meiner Freundin Eva danke ich für die Geduld die du aufgebracht hast, und die schönen Zeiten, die mich gestärkt und auch motiviert haben, weiter zu machen. 1 Contents 1 Introduction 1.1 Introduction . . . . . . . . . . . . . 1.1.1 Stellar evolution of a CSPN Born-agains . . . . . . . . . 1.1.2 Planetary Nebulae . . . . . 1.2 The idea of the setup . . . . . . . . 1.3 Comparison to previous work . . . . . . . . (Central . . . . . . . . . . . . . . . . . . . . . . . . star of . . . . . . . . . . . . . . . . . . . . . . . . the planetary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . nebula) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 7 7 9 9 2 Model 2.1 Environment . . . . . . . . . . . . . . . . . . . 2.1.1 Boundary conditions . . . . . . . . . . . 2.1.2 Chronological sequence . . . . . . . . . 2.2 Numerical model . . . . . . . . . . . . . . . . . 2.3 Stellar wind models . . . . . . . . . . . . . . . 2.3.1 Isothermal wind with gas pressure only 2.4 Gravity . . . . . . . . . . . . . . . . . . . . . . 2.5 Radiative transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 12 12 14 15 17 18 3 CRONOS 3.1 Physical point of view . . . . . . . 3.1.1 Hydrodynamic equations . 3.1.2 Riemann solvers . . . . . . The Riemann problem . . . Riemann solvers . . . . . . Limiter . . . . . . . . . . . 3.1.3 Normalised Euler equations 3.1.4 Energy modes . . . . . . . . 3.1.5 Numerical domain . . . . . 3.1.6 CFL-condition . . . . . . . 3.2 Technical point of view . . . . . . . 3.2.1 Setting up CRONOS . . . . 3.2.2 CRONOS module . . . . . 3.2.3 CAT-File . . . . . . . . . . 3.3 VTK-Data processing . . . . . . . 3.4 CRONOS Objects . . . . . . . . . 3.4.1 Structure: Objects vs Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 19 19 20 20 21 22 23 24 25 26 26 26 27 29 31 31 32 4 Implementation 4.1 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Milestones . . . . . . . . . . . . . . . . . . . . . . Milestone 1: Blanked out region . . . . . . . . . Milestone 2: Wind with gas pressure . . . . . . . Milestone 3.1: Full energy mode . . . . . . . . . Milestone 3.2: Gravity . . . . . . . . . . . . . . . 4.1.2 Milestone 4: Additional numerical tests . . . . . Determining and testing the numerical resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 34 34 36 36 41 43 44 46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Outlook 5.1 Summary of the current stage . . . . . . . . . . . . . . 5.2 Further steps . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Photon momentum transfer . . . . . . . . . . . 5.2.2 Radiative heating and cooling using CLOUDY 5.2.3 Evolution of a planetary nebula . . . . . . . . . 5.3 Additional improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 49 50 50 51 51 53 A Normalisation 54 B Visualisation 56 C CRONOS-Objects 59 3 Chapter 1 Introduction 1.1 Introduction In this section the basic concepts of planetary nebulae and the idea of the intended radiative-hydrodynamics setup are introduced. A general overview of planetary nebulae is given and a comparison to similar works is discussed at the end of the chapter. A prelimary presentation of the ideas was shown at the “Asymmetrical Planetary Nebulae VI conference” in November 2013 Niederwanger et al. [2014]. The introduction material for the stellar evolution is based on the work of Karttunen, Kröger, and Oja [2007], VoigtHans-Heinrich and Röser [2012], for the planetary nebulae on Karttunen, Kröger, and Oja [2007], Kwok [2000], Kifonidis [1996]. 1.1.1 Stellar evolution of a CSPN (Central star of the planetary nebula) A cloud of gaseous material and dust in the interstellar medium is contracted by self-gravitation. The cloud is made by hydrogen and helium with some small traces of ”metals” (All elements beyond Helium are called “metals” in stellar astrophysics). As the cloud condenses, more and more material is attracted. The in-falling matter converts potential energy to thermal energy, the cloud heats up and starts to radiate. At this stage the only source for radiation is the temperature, therefore the cloud emits a clean black-body spectrum at this stage. Initially, as the opacity is small, the thermal radiation will escape the protostar into the vacuum. As more and more material condenses, the opacity is rising and so is the temperature, because the thermal energy in form of radiation is now partially re-absorbed and cannot escape any more. More and more material condenses in the cloud, thus increasing the opacity even more. As the temperature rises, the molecules dissociate and later also atoms ionize. When the central temperature reaches some few million Kelvin, hydrogen burning is ignited, which becomes the main energy source for the star. This is the point where the star reaches the main sequence phase in the Hertzsprung-Russel diagram (see figure 1.1). Stars in the main sequence are in hydrostatic equilibrium. This means, there is a balance between radiation pressure and gravity that stabilises them. Massive stars with M > 60 − 80 M are not possible on longer time-scales, because their radiative pressure exceeds the gravity, the star is disrupted. This stage is then called a Wolf-Rayet (WR) star. On the other hand stars below 0.08 M do not reach the temperature to ignite hydrogen burning. In the following the focus is set on the evolution of 1 − 8 M stars, as these are possible candidates for the formation of PNe. For a 1 M star like our sun, after some 10 gigayears (some 1010 yrs) of thermonuclear fusion, the core-hydrogen is exhausted. This varies strongly with the mass of the star: for a 2 M star the core burning rests for about 3 109 yrs, for a 8 M -star for about some 107 yrs. The star now enters the RGB-phase (red giant branch), where the core (at this stage mostly helium He) contracts and heats up. Hydrogen burning still takes place in a shell around the core, feeding the core with even more helium. The inner core is collapsing until at a certain density, where it becomes degenerated. At this state the core temperature can be considered to be constant: the electron gas is able to transport heat almost instantaneously within the degenerated core. This degeneration has an impact on the later following helium-flash, since due to it’s homogeneous temperature it takes simultaneously place 4 Figure 1.1: Hertzsprung-Russel-Diagram: The luminosity of a star in dependency of it’s spectral type or temperature. The main sequence, giants, supergiants and the white dwarfs are shown as groups. Credit: ESO on the whole core, after reaching a certain threshold energy. When the central temperature reaches some million Kelvin, the 3α-process can take place, burning helium to carbon (and some oxygen) according to the following reactions: 4 He +4 He →8 Be + γ 8 Be +4 He →12 C + γ When the He-burning is ignited, the star transits from the RGB-phase to the AGB-phase (asymptotic giant branch). Convection from the core to the shell brings the heavier products to the outer regions. The mixing is called the first dredge-up. The different shell-structures of the AGB-star are illustrated in figure 1.2. The hydrogen burning in the shell triggers an expansion and an increase of the luminosity, the star becomes a red giant. The resulting luminosity of the red giant star depends on the core mass of the star. In the special case of a PN progenitor with it’s shells around the star (see figure 1.2), the luminosity of the star stays equal until the H-envelope is consumed. As long as the envelope mass exceeds some percent of the total star mass, the envelope shrinks, converting gravitational energy into thermal energy. This process keeps the luminosity constant. After the H-envelope is burned down to a mass of < 10−4 M , the H-burning shell dies out. Now the star cools down following the cooling track according to the Blöcker-Tracks [Bloecker, 1995] (see figure 1.4). The evolution after the helium burning phase depends strongly on the mass of the star: For stars with masses above 10 M the carbon or oxygen core can be ignited. Since the central stars of planetary nebulae (CSPN) are between 1 − 8 M this case is not covered in this work. Stars that are forming PNe,consist at this stage of four different regions (see figure 1.2): • Inert core, not hot enough to ignite carbon • He-shell • H-shell • Circumstellar envelope of the detached shells 5 Figure 1.2: The shell-structures of a star in the AGB-state. Stars with large masses may also have additional shells containing heavier elements (such as e.g. 12 C, 16 O, 28 Si) The He and H-burning shells are alternatively expanding (thereby cooled) and contracting (heated up). The cooling during the expansion stops the burning processes, that is re-ignited after the following contraction. This state of alternative burning in different shells is called the TP-AGB-phase (thermally pulsing asymptotic giant branch). The thermal pulses are He-flashes taking place in the shell. Since the burning phases of the two shells are not exactly opposite, there is also a convective mixing of 4 He and 20 N e in the stellar atmosphere, called the second dredge-up. These convective mixing transfers heavy materials from the core into the shells, that are later accelerated and blasted off as stellar wind. This wind enriches the interstellar medium with metals. On the contrary, also heavier materials produced in the shell are transferred to the core. Within some thermal pulses, the star loses the whole H-shell. During the TP-AGB phase there is an immense outflow of material up to 10−4 M /yr over a duration of some 10.000 yrs. This massive mass-loss rate is later reduced by several orders of magnitude. As the outer envelope expands, it cools down. After a certain temperature has been reached, dust formation in the shell becomes possible. At about the same time, the star begins to pulse at very large amplitudes. Dust has a higher cross-section for the interaction of photons from the stellar pulses, so it is more likely for the dust to absorb a photon and it’s momentum. This photon-momentum transfer plays an important role in the acceleration of the dust particles. The result is a expanding dusty shell and the lift-off of the outer shell. The cold, outer shells of the circumstellar envelope are at this stage ejected. What remains is the inner part of the star. As the star radius is at this stage much smaller than the previous radius, a less dense but much faster wind is now ejected, as the escape velocity depends on the inverse square root of the radius: r 2GM vesc = (1.1) R The details of this process are described in section 1.1.2). The fast wind of the hot, small star overhauls the previous ejected slow, but much denser wind. The interaction between these two winds is considered as one of the major processes for PNe formation [Kwok et al., 1978, Kwok, 2007]. It’s also important, that the CSPN is in the right mass regime to form a PN. Low-mass stars evolve too slowly to ionise the nebulae before it’s expansion reduces the density too much so they become remain invisible. High-mass stars evolve too quickly, the nebula won’t be visible either because it is not sufficient expanded when ionised. Only expanded, ionised nebulae are clearly visible. At this stage the star is a degenerated C-O-core with circumstellar H and He-burning shells (see figure 1.2). While in the post-AGB phase, the star transits horizontally at almost constant luminosity towards higher temperatures. When the H is exhausted, the main heat source terminates and the star goes downwards in the HRD (see figure 1.1), it slowly cools down. This behaviour is also shown in figure 1.4, 6 taken from Bloecker [1995]. Born-agains When the star leaves the AGB-phase, a last thermal pulse in this stage can change the burning process from H to He-burning. As the outer edge of the H-shell overlaps with the He shell, the star will evolve back to the AGB and after a few hundred years restarts the post-AGB phase as a He-burner. Figure 1.3: Late thermal pulses of a post-AGB star (3 M ) in the Hertzsprung-Russel-diagram. The time marks are in units of 103 yrs. Taken from Bloecker [1995]. This behaviour is shown in figure 1.3, taken from Bloecker [1995]. 1.1.2 Planetary Nebulae Planetary Nebulae (PNe) are a relative short phenomena resting for some 10, 000 yrs in the late life of a star. PNe can be formed around stars with masses between 0.8-8 M . In the Hertzsprung-Russel-diagram the PN crosses a horizontal line where the luminosity stays almost constant while the AGB-star heats up towards higher temperatures. Followed by this transition it enters the white dwarf sequence, where the star cools down and becomes less and less bright. The sequence from the AGB-star to the white dwarf is shown in figure 1.4, taken from Bloecker [1995]. The wind of CSPN contains metallic elements, that are blasted off via the stellar wind. Most of the N , C and products of the slow-neutron-capture-process (e.g. M g and heavier elements) are produced via AGB-stars and blasted off as stellar wind, so PNe play an important role in the chemical composition of the interstellar medium (ISM). The main characteristics of planetary nebulae are their circumstellar envelopes, produced by varying outbursts of different stellar winds. The resulting ionised nebulae are found in different shapes and forms. A planetary nebula has to fulfil the following conditions: 1. Hot white dwarf type central star 2. The lucent material around the star must originate from it 7 Figure 1.4: The evolution of a post-AGB star (initial mass is two times 3 M with different AGB mass loss scenarii, and 5 M ) in the Hertzsprung-Russel-diagram according to Bloecker [1995]. The time marks are in units of 103 yrs Name Old wind Superwind Fast-wind Epoch AGB POST-AGB several thousand years after the superwind Mass-loss rate Average Very high Low Speed Slow Slow Fast Table 1.1: Overview of the different wind phases. Numerical values are shown in table 2.1. See also figure 2.2 in section 2.2. The later condition allows us to distinguish between real PNe and symbiotic miras. Symbiotic miras are a binary system consisting of a hot star and a cool mira. While the envelope of a PN is blown off it’s central star, the lucent material of a symbiotic mira comes from the surface of it’s companion star. Physically the both differ in their lifetimes: While the symbiotic mira state can go through the whole mira state, the duration of a PN lasts for some 104 -105 years [see Schmeja and Kimeswenger, 2001]. Planetary nebulae are considered as result of three interacting winds: A slow AGB-wind, that fills the circumstellar environment, a following slow but very dense wind (labelled as “superwind”), and a fast but not so dense wind (“fast wind”). Table 1.1 gives an overview over the three different wind phases. The idea of the interacting wind model was introduced by Kwok et al. [1978]. Previous models tried to explain the formation of PNe by sudden-ejection models, but failed in several points like there isn’t any instability mechanisms that leaves the star in the exact mass configuration so it can heat up. Without the transition to the blue side of the Hertzsprung-Russel-diagram, the star won’t be hot enough to ionise the surrounding shells. The concrete formation of a PN is a very dynamic and complex mechanism. As Sun Kwok said, “ PNe are not simply AGB envelopes diffusing into the interstellar medium; a separate mechanism is needed to accelerate, compress, and shape the AGB envelope into PNe [Kwok, 2000]. ” The AGB-star burns until most of it’s own H-envelope is ejected. While the circumstellar envelopes are blasted off, the core remains exposed and further nuclear burning processes reduce the H envelope even more. As the star heats up, a massive outflow of material is produced (the ”superwind”). The escape velocity vesc depends on the radius according to 8 r 2GM (1.1) R As the core shrinks, the new wind will be faster than it’s more extended progenitor. Sun Kwok suggested, PNe are a result of these two colliding winds: the dense but slower wind of the red giant progenitor that is overhauled by the faster stellar wind of the CSPN. This simple model is widely accepted, but lacks in some details as it will be discussed in section 1.3. The collision of the two winds creates a bubble at high temperatures. Following, this interaction exposes a pressure on the shell. Because of it’s underlying pressure the shell expands [Kwok, 2000]. The fast-winds pushes together the slower expanding shells forming multiple shells. While the outer shells expand, the fuel of the CPSN is exhausted. The central star is getting hotter and becomes a white dwarf. This increases the output of UV-photons, specially of photons above 13.6 eV (ionisation energy of H). These photons ionise the (still expanding) outer shells, forming a glowing plasma at low densities - a PN is born. vesc = 1.2 The idea of the setup The idea is to set up a full 3D-radiative transfer hydrodynamics simulation using CRONOS [Kissmann, 2006] for the hydrodynamics and to use CLOUDY [Ferland et al., 2013] to calculate the parameters for a highly sophisticated radiative transfer mechanism. In comparison to previous works from Perinotto et al. [2004], where 1D radiative transfer hydrodynamics models are used to simulate the evolution of the post-AGB-phase, a full 3D-approach for the same phases is taken. Using this approach one can expect insights about the formation and structures that appear in PNe. Details about the setup and implementation are covered in chapter 4. A full established and functional radiative-hydrodynamics environment for PN is far beyond the scope of a MSc. thesis. This work covers the first steps in the implementation and gives an outlook of the further steps towards a full 3D radiative-hydrodynamic simulation for the formation of a planetary nebula. 1.3 Comparison to previous work There exist various previous work based on radiation-hydrodynamics simulation on the formation of PN. Different groups are thereby focusing on different aspects of the physics: Okorokov et al. [1985b] focused on the shell formation and wind structures of the Post-AGB phase using a two-component hydrodynamics calculation with a radiation transfer model, that took frequency and angle dependency into consideration. The two-component model is widely accepted as important role in the formation of PN, since the increased cross section of dust particles can capture efficiently the momentum of photons. They introduced three phases of the stellar wind that will also be used in this thesis’ approach to model the stellar wind of the CSPN in the simulations. Details about this model are described in sections 2.1 and 2.2. They also showed, that the ionisation plays an important role in acceleration of the dust and gas components. The concluded that a better treatment of the mass-outflow, a non-spherical symmetry and more accurate treatment of shocks would improve their work. The envelope is assumed to be blown off during the superwind phase using a constant mass loss rate. It is to mention, that the superwind is created by the thermal pulses of the H and the He-shell. The assumption of a constant mass loss rate could be too coarse, especially for the formation of multiple-shell PNe. With the tables from Bloecker [1995] and the approach of using the CRONOS code (See chapter 3) all of their suggestions are included in the setup of this thesis, but in a 3D instead of a 1D environment. Perinotto et al. [2004] did similar radiation-hydrodynamics calculations to investigate how the resulting PN depends on different masses and mass-loss rates of the CSPN. Unlike Okorokov, they did not use two-component hydrodynamics for the gas and the dust components. An improved schema for the Blöcker-Tracks for the mass-loss rates was used. Like Okorokov, they also assume spherical-symmetry. The improved wind-schemas using the Blöcker-tables are still widely accepted [Perinotto et al., 2004]. Most morphologies of PNe do not depend directly on the time-dependent mass-loss-function as the shock waves created by ionisation modifies the initial density and velocity values. Furthermore were they able to show that the increasing stellar wind is able to create double-shell features. This requires the high 9 mass-loss-rates of the AGB star (the superwind) to continue until the shell detaches quickly. Shock waves are assumed to disrupt the initial conditions of the density and the velocity. As current observations on NGC 2438 showed no evidence for dominating shock interactions this assumption may not be valid for each PN. The consideration of significant shocks must be therefore done for each PN individually [Öttl et al., 2014]. Although the colliding wind model of Kwok [2000] is widely accepted, Okorokov showed that there are some non-negligible effects during the phases of stellar evolution, so that the assumption of a constant velocity wind and a constant mass loss rate has to be improved [see Okorokov et al., 1985a]. 10 Chapter 2 Model The following chapter describes the model used for the simulations and test cases. The concrete implementation was done by using a roadmap with defined milestones. The starting point from bottom was to set up a plain hydrodynamics environment and add, step by step, more complexity. The added mechanisms were tested by several test cases and only after eliminating all occurring problems, the next step is faced. The reader should be aware, that the models described in this chapter include also features that are not yet implemented in the setup, but are important to fulfil the next milestones. The full setup of a 3D radiative-hydrodynamics simulation for PN is far beyond the bounds of a MSc. thesis - here the first steps toward the full setup are implemented. Details about the concrete setup, the roadmap and the defined milestones are covered in chapter 3. Intrinsically with the approach to use different milestones, in the first stages not all model features are implemented. 2.1 Environment This work distinguishes between the nucleus and the envelope of a planetary nebula (PN). CSPN stands for central star planetary nebulae and includes also the region surrounding the central star or stars. This work focuses on the evolution of the envelope of a PN. As a consequence, the inner region was suppressed in the simulations. This blanked out region contains the CSPN with the surrounding region, at least until the sonic point of the stellar wind. The physics of the CSPN is very complicated, including stellar atmosphere simulations with convective flows and more complex mechanisms. The treatment of the inner region as additional boundary condition is possible due to the negligible influence of the envelope to the central region. At this sage, no luminosity or temperature functions except for constant values were used. In the near future the functions for the luminosity L(t, M∗ ) and the temperature T (t, M∗ ) (where t is the time and M∗ the mass of the star) of the central star are considered to be taken from Paczynski [1970] and improved by using the evolutionary tracks of Bloecker [1995]. The central region is treated as a boundary condition with defined values for the density ρ, the velocity ~v and the total energy E, as these field are used by CRONOS (see chapter 3). The concrete implementation of these functions depends on the actual case. In the following test cases, constant functions over the time were taken. Future implementation will include a full choreography of the different building blocks, that are currently handled isolated. The numerical domain is set to be in Cartesian coordinates. CRONOS would also support different other coordinate systems (see chapter 3) but as spherical symmetry will not be assumed, a non-spherical coordinate system is chosen. With this approach numerical artefacts produced by the assumption of spherical symmetry (See section 1.3) are excluded. 2.1.1 Boundary conditions The ultimate approach for the outer boundary conditions is to set the border to defined values. In the first test cases a outflow boundary condition supported by CRONOS (see chapter 3) was used, but failed 11 after gravity was included. To fix this issue, the field values for the outer boundary condition are set to typical values for the ISM. When using these fixed boundary conditions the the domain must be large enough to contain the actual nebula including an adequate puffer zone so that numerical stability is ensured. If the numerical region is close to the border, artificial boundary effects caused by numerical instabilities take place. A detailed description of the problem with the boundary conditions is discussed in chapter 4. Additionally to the outer boundary conditions, the inner region (where the CSPN lives) is treated as another boundary condition. As this work focuses on the evolution of the circumstellar envelope, the inner field until at least to the sonic point of the isothermal stellar wind was blanked out. As discussed above, the physics in the region of the CSPN is very complex and in this setup assumed as boundary condition. 2.1.2 Chronological sequence The domain is initially filled with a 1/ra density field (a is typically a value between 1.0 − 2.0) and constant velocity pointing radially away from the CSPN. The specific fillup parameters depend on the actual test cases. After the initial fillup the environment should be in conditions similar to the AGB wind. At this stage one has a (blanked out) CSPN and a empty ISM domain. Hereupon the environment can establish hydrostatic state, before the inner boundary condition is set to the physical values. This ensures that possible unphysical initial disturbances are stabilised. At the same time this was the first test case to test the numerical stability of the inner boundary condition. Details about the concrete setup are found in chapter 4. After the initial fillup and reaching hydrostatic equilibrium, a blanked out region where the star lives and a stable ISM domain is established. From the point of view of the evolution of a PN, this defines the environment, where the AGB-wind blasts into. Now the boundary conditions for the inner region are set to the values of the different wind phases (Old wind, superwind and fast-wind as described in section 2.2). At the current stage different wind models are tested isolated from each other. At the ultimate stage it is possible to establish an environment where the implementation of a complete choreography can take place by merging all individual components together. This implementation will be part of a future work. The expected result of subsequent works on the simulation is to investigate the behaviour of the colliding winds and the resulting formation of a planetary nebula. 2.2 Numerical model This thesis describes the current stage of implementing a 3D-radiative-hydrodynamics environment for the investigation of planetary nebulae. Most of the described stages are testes as isolated test cases. Currently there is no working implementation including all discussed topics. Most of them are included in separate test chases. The details of the current implementation and the results of the test cases are discussed in chapter 4. Most of the considerations are based on the work of Okorokov et al. [1985a]. Okorokov et al. were the first to present a radiation hydrodynamics model at the IAU symposium in London (1983): The PN evolves from an ejected envelope of a red supergiant. In Okorokov’s work, the luminosity and temperature functions of the CSPN are taken from Paczynski [1970]. It is considered to re-take the same functions and improve them with the Blöcker-Tracks [see Bloecker, 1995]. As this is planned for a future work and not discussed further in this thesis. Details about the outlook and the plans in the near future are found in chapter 5. Okorokov et al. distinguished between three phases: • Fillup (old wind) • Superwind • Fast-wind Beginning with the old-wind phase, the central star is treated as a star with a steady-flow of about Ṁ = 10−6 M /yr. After this fillup of the domain of the evolving planetary nebula, the superwind-phase begins. This is a phase with a very intensive mass loss rate, some orders of magnitude above the previous 12 and also the following mass-loss-rates as suggested by Iben and Renzini [1981] (see table 2.1 and figure 2.2). The envelope is assumed to be blown off during the superwind phase with a constant mass-loss rate. As discussed in section 1.3, this assumption could be too coarse as during this phase several pulsation mechanisms take place. Bloecker [1995] describes, the stellar wind during the RGB-phase (the phase where the core-hydrogen is exhausted but the He-ignition did not yet begin) can be estimated according to Reimers-formula [see Baschek et al., 2012] LR (2.1) M with the fitting parameter ηR = 0.5 for a 1 M star, and ηR = 1.0 for more massive stars [Bloecker, 1995]. During the AGB-phase, the stellar wind can achieve mass-loss rates up to 10−4 M /yr (superwind). After the AGB-phase the mass-loss rate is reduce by several orders of magnitude. Bloecker was able to show, that also a brusque termination the AGB-phase to set the mass-loss rate after some thermal pulses to 0 yielded the massive AGB remnants (superwind) - a precondition for the formation of a PN [see Bloecker, 1995]. ṀR = 4 10−13 ηR After the stage of the high mass output (superwind) from the CSPN, the fast-wind phase starts. The CSPN has now a an expanding, circumstellar envelope ejected prior by the superwind. Okorokov et al. assumed that the velocity of the fast-wind is proportional to the temperature of the CSPN, reaching a maximum value of 2000 km/s. Figure 2.2 shows the wind velocities at the different stages of the evolving PN. The numerical values are shown in table 2.1. Figure 2.1: Okorokov’s model of the mass loss rate Ṁ and the wind velocity v of a evolving PN. Taken from Okorokov et al. [1985a]. The numerical values are shown in table 2.1. 13 Phase Old-wind Superwind Fast-wind Mass-loss-rate Ṁ 10−6 M /yr 10−4 M /yr 10−7 M /yr Velocity 25 km/s at r = 5 1013 cm 25 km/s at r = 5 1013 cm Linear increasing, up to 2000 km/s Table 2.1: Numerical values used in Okorokov et al. [1985a]. They were used as reference values for different test cases Okorokov et al. [1985a] showed that the hydrodynamic approach for the evolution of HII regions is accurate by using a 1D hydrodynamic simulation with radiation transfer and spherical symmetry. The integral momentum of the fast wind (10−7 M /yr with v ≈ 2000 km/s, see table 2.1) corresponds to the observed momentum of a typical planetary nebula envelope (M = 0.2 M , v ≈ 20km/s). The superwind phase model could be inaccurate, since a star that evolves to a AGB has an increasing mass-loss-rate. Figure 2.2: Hertzsprung-Russel diagram of the the proto-planetary nebula phase. The two tracks correnspong to stars with different masses. Taken from Kwok [1993] Okorokov et al. suggested, that the initial wind is created with a rate of about Ṁ = 10−6 M /yr before a fast stellar wind increases the temperature of the envelope and creates the shell-like structures that are typically observed in a PN [see Okorokov et al., 1985b]. A nonspherical symmetry and better treatment of shocks are brought up as possible improvements of their work. The former suggestion is already included in this work as CRONOS is used as hydrodynamic framework. The later suggestion may be deprecated since Öttl et al. [2014] showed in a recent paper, that NGC 2438 shows no evidence for shocks. 2.3 Stellar wind models In section 4.1 the concrete implementation of different milestones towards the goal is discussed. In the first and most simplest case a isothermal solar wind with a constant mass-loss rate was used. The following sections are based on Lamers and Cassinelli [1999], if not otherwise specified. Historical background The first hints, that stellar winds cannot be modelled by static descriptions but are in fact a highly dynamical process comes from the observations of comets: Comets have in general two tails: A diffuse, dusty tail, arranged toward the sun in the track of the comet, and a second radial from the sun pointing tale, the ion tail. Figure 2.3 shows an illustration of comet Hale Bopp with it’s two tails. The blue tail in the figure is the ionic tail, the diffuse white tail is the dusty one. 14 Figure 2.3: Comet Hale Bopp (USNO). Taken from Blackwater Falls State Park, Davis, Public Domain. The blue tail is the ion-tail, the white tail is the diffuse dusty tail The origin and direction of the dusty tail was well understood as interaction between radiation pressure and gravitation. The second tail couldn’t be understood as static phenomenon, since the observed structure was varying in size and acceleration with the observation time. Biermann [1951] postulated a steady plasma stream emitted by the sun. Today this plasma stream is known as stellar wind and represents a dynamical stellar atmosphere that predicted the behaviour of the ion tail of comets very well. Eugene Parker worked on this idea and was the first, who developed the idea of a supersonic stellar wind [see Prölss, 2003]. 2.3.1 Isothermal wind with gas pressure only In this simple case the wind is assumed to be isothermal and the only forces are • Gravity (directed inward) • Gradient of the gas pressure (directed outward) The only assumption that is taken in this case is that even for a time-dependent stellar wind with a constant mass-loss-rate the integrated matter going through any sphere with radius r stays constant. This is denoted by the equation of mass conservation, integrating the gas outflow on a arbitrary shell Ω around the center Z Ṁ = ρ vdΩ Ω Since the first test cases (see section 4.1) are based on spherical structures in a Cartesian grid, spherical symmetry can be assumed, and the equation above becomes Ṁ = 4πr2 ρ(r)v(r) = constant (2.2) Now, using Newton’s law, the velocity gradient on the distance r and time t is given as δv(r, t) δv(r, t) dr(t) dv dv(r, t) = + = v(r) dt δt δr dt dr In the simplest case stationary solutions are searched for, so the time derivative becomes zero. With the assumption that the only two forces are gravity and gas pressure, the equation above becomes the momentum equation dv v dr |{z} Acceleration + 1 dp ρ dr | {z } Gas pressure 15 + GM∗ =0 2 | r{z } Gravity (2.3) The wind is considered as perfect gas, so the ideal gas equation holds pµ = RρT (2.4) Where µ = 0.602 mH is the mean atomic weight of the wind under solar conditions. Further, the physical conditions are (almost) fully ionised. R is the gas constant. Combining equation 2.3 and the ideal gas law 3.17 with the force due to the gradient of the pressure field 1 dp dT RT dρ RT 1 dρ = Rµ + = ρ dr dr µρ dr µ ρ dr gives us a differential equation for the velocity of the stellar wind 2 1 dv 2a GM∗ /(v 2 − a2 ) = − 2 v dr r r (2.5) with the (constant) isothermal speed of sound s a= RT µ Looking at equation 2.5, one finds two interesting points: The point where the enumerator becomes zero, and the point where the denominator becomes zero (singularity). At the critical point rc the numerator becomes zero. It is the point where r = rc with GM∗ 2a2 The critical point has to be beyond r0 , otherwise the isothermal assumption does not hold. Looking at equation 2.5 one see, that the velocity gradient becomes zero, unless rc = v(rc ) = a Similar, the only point where v = a holds can be the critical point, otherwise the velocity gradient would go to ±∞. The critical point is also called the sonic point, because at this point the wind reaches the isothermal speed of sound a. This is in general only valid for the isothermal case. Since the velocity gradient function implies a monotone behaviour, it is the only point where the wind has the speed of sound. There still exists different solutions to the momentum equation 2.3. The different types of solution are shown in figure 2.4. As pointed out above, a valid solution must fullfill v = a, otherwise the velocity gradient would go to ±∞. Considering equation 2.5 for the wind velocity one can see, that the only point where the velocity gradient becomes zero is at r = rc . In all other cases either monotone increasing or decreasing velocity profiles are found and the behaviour to the left and the right of the critical point rc can be alternating. Solutions A, B and D can be excluded: Solution A has infinite velocity at the origin. The velocity of solution B decreases right of the sonic point, a behaviour that does not correspond to observations of the solar wind. Solution D reaches a velocity of ∞ at the origin and decreases after the critical point. The only physical solution is C, a solution that starts subsonic, goes through the critical point and ends supersonic. This is a rough approach for the stellar wind. This model has several issues in consideration of observations made by solar probes: • Infinite acceleration (comes from the isothermal assumption) • Model is isotherm - In reality the temperature decreases with increasing r This simple characterisation of a stellar is not sufficient for a sophisticated model. Especially in the regions far beyond the sonic point, the isothermal approach does not commensurate with observations and energy conservation: The energy density of the isothermal wind is given by e(r) = v2 2 |{z} Kinetic energy GM∗ r } | {z − Potential energy 16 + 5 RT 2 µ | {z } Enthalpy (2.6) Figure 2.4: Possible solutions for the momentum equation 2.3. The only physical solution goes through the sonic point rc , reaches there the isothermal speed of sound a and has a monotone increasing behaviour. This is solution C, all others are unphysical. p 2 For very large distances it becomes e(r → ∞) ≈ v2 with v(r → ∞) ≈ 2a ln(r/r0 ) increasing to infinity. The diverging energy density in the regions far away from the sonic point is a direct consequence to the isothermal assumption. Nevertheless the isothermal wind model is very useful for the first test cases of CRONOS. The velocity function can be determined from equation 2.5 and the assumption of a constant mass loss rate (Ṁ = 4πr2 ρ(r)v(r), see equation 2.2) can be easily checked in the numeric domain. This makes the isothermal wind with gas pressure only an ideal candidate to check, weather the code can handle the artificial inner boundary condition (the blanked out region). Details about the test cases are found in chapter 4. 2.4 Gravity The environment was testes by using the most simple form of gravity: A single gravity source at the center of the central star. Although the gravitational influence of the star could be neglected for the desired simulation of a PN, a defined environment that allows self-gravity could become important in a future work. Gravity is defined as a source term according to Newton’s formula M∗ · m (2.7) r2 where M∗ is the mass of the central star (the only source of gravity in this simple model), G is the gravitational constant and r denotes the distance from the gravity source. m is the mass, at which the force acts on. In terms of a force density equation 2.7 becomes FG = G · fG = FG M∗ · m M∗ · ρ =G· 2 =G· V r ·V r2 (2.8) CRONOS uses density values (force density, energy density, ecc) as field variables, therefore also a force density to express gravity is used. The idea to test gravity is to use well-known Kepler-orbits. If a density clump around the central blanked out-region has the Kepler-velocity vK , then the clump’s trajectory should be a stable orbit around it’s gravitational center. r GM∗ vK = (2.9) r 17 When using a numerical grid it’s necessary to give the density clump a differential velocity: If the clump takes more than one grid cell, the different grid cells have a different Kepler-velocity, since vK is a function of r. If using an average velocity for the whole clump, it will dissolve, since the inner parts of the clump are too slow and fall into the gravity cone while the outer parts are too fast and escape. 2.5 Radiative transfer Radiative transfer was not yet implemented in the setup of this thesis. A full 3D-radiative-hydrodynamics setup would be outside the bound of a MSc. thesis, but there are plans for a future work to extend the achieved setup with a interface to CLOUDY for the radiative transfer mechanism. From time to time, a CLOUDY run is invoked to calculate the parameter needed for the calculation of the radiative transfer terms. For the CRONOS setup this means to reduce the time steps. A single simulation timestep ∆t becomes ∆t = min(∆thydro , ∆tradiative ) (2.10) The interface between the radiative transfer and the hydrodynamics will be the thermal energy eth and the density ρ. For CLOUDY it is important to have the density ρ and the temperature T (from eth ) to calculate the tables and the transported input radiation field. The radiative transfer mechanism influences the thermal energy and therefore the pressure. Figure 2.5: Pipeline and interfaces between CRONOS and CLOUDY for the radiative transfer. Since CLOUDY runs are very expensive in CPU time, an algorithm to decide weather the environment changes are negligible or a new CLOUDY-run is necessary. The resulting tables from CLOUDY (or the cached ones, if the changes are negligible) is then taken to do the radiative transfer calculations. The interface from the radiative transfer to the hydrodynamics is the thermal energy eth . Figure 2.5 illustrates the pipeline for the radiative transfer, the implementation will be part of a future work. 18 Chapter 3 CRONOS CRONOS [Kissmann, 2006] provides a selective 2D or 3D hydro- or magnetohydrodynamics environment in a dimensionless domain. It supports Cartesian, cylindrical or spherical coordinate systems and provides different types of Riemann solvers (see 3.1.2). Because of it’s high flexibility it provides a very powerfull framework for various types of hydrodynamic and magnetohydrodynamic simulations. The simulation for this thesis build on top of CRONOS, in a future work a extension with an interface to CLOUDY is planned, to provide also a highly sophisticated radiative transfer mechanism. This is needed for the complete simulation of the evolution of a planetary nebula. As the complete setup is beyond the scope of a MSc. thesis, this work includes the first steps towards the full simulation. A future works that completes the desired goal is planned and discussed in chapter 5. 3.1 Physical point of view CRONOS defines a finite-volume environment solving the equations of hydrodynamics or magnetohydrodynamics at each timestep. CRONOS supports the following coordinate systems: • Cartesian coordinates • Spherical coordinates • Cylindrical coordinates Choosing the coordinate system for an arbitrary environment sets the internal representation of the calculation domain and the form of the equations. The integration of the hydrodynamics equations really takes place in the chosen coordinate system. Additional to the coordinate systems, the user can configure the number of grid cells and the domain size in each direction independent. The number of grid cells and the size or the calculation domain determines the resolution of each individual simulation run. CRONOS can run in two different modes: • Hydrodynamic mode Solving the Euler equations • Hydromagnetodynamic mode - Solving MHD equations 3.1.1 Hydrodynamic equations Hydrodynamics equations without magneto-hydrodynamics (MHD) are used. CRONOS supports MHD but at the current stage the focus is on the radiative-hydrodynamics so the electrodynamic effects are neglected in this thesis. The equations that CRONOS solves iteratively after each time steps are the Navier Stockes equations: ∇p ν 2 f D v = δt v + v · ∇v = − + ∇ v+ Dt ρ ρ ρ (3.1) ∇·v =0 (3.2) 19 CRONOS does not include the viscosity (ν = 0). Therefore the Navier-Stokes equation 3.1 becomes the simplier Euler-equation ρ · [δt v + v · ∇v] = −∇p + f (3.3) The continuity equation (3.2) stays the same. The integration of each timestep is done by a corresponding Riemann solver, covered in the following section. 3.1.2 Riemann solvers The following section is based on Toro [2009]. The Riemann problem The conservation Euler-equations (see 3.3) in differential form can be written as δt U + δx F(U) = 0 U and F(U) are the conserved variables and fluxes given by ρ U = ρu E (3.4) (3.5) ρu (3.6) F = ρu2 + p u(E + p) where ρ is the density, u is the velocity and E = ρ 21 u2 + e is the total energy density. e is the internal energy and for ideal gases it obeys p e= (3.7) (γ − 1)ρ For smooth solutions, equation 3.4 can be written in different formulations. But for solutions that include shocks, non-conservative formulations could lead to incorrect solutions. As the solutions for this simulations include shocks, the conservative formulations must be taken. The Riemann problem is the initial-value problem for the Euler-equation 3.4 with the fields (UL , UR ). δt U + δx F(U) = 0 UL if x < 0 U(x, 0) = U(0) (x) = UR if x > 0 (3.4) (3.8) UL and UR are the conserved fluid values (see equation 3.5) on the left respectively on the right of the position of the Riemann problem. In the most simplest case they are considered as piecewise constant with a single contact discontinuity at x = 0. A illustration of the Riemann problem is shown in figure 3.1. 20 Figure 3.1: Illustration of the Riemann problem. The density rho is shown for two timesteps t1 < t2 Additional to the Riemann problem, one must also consider the given boundary conditions of the computational domain. The most general Riemann problem is to solve the following initial boundary value problem: Conservation equation δt U + δx F(U) = S(U) Initial condition U(x, 0) = U(0) (x) Boundary condition U(0, t) = UL (t), U(L, t) = UR (t) U and F are the conservation Euler-equations according to 3.4, S(U) is a source term (within this section S(U) = 0 for simplicity) and the numerical domain ranges from 0 ≤ x ≤ L. Riemann solvers In CRONOS the user can choose between the following Riemann solvers: • HLL • HLLC • HLLD The Harten, Lax and van Leer approximate Rimeann solver (HLL) is given by if xt < SL UL hll ˜ U if SL ≤ xt ≤ SR U (x, t) = UR if xt ≥ SR (3.9) SR UR − SL UL + FL − FR SR − SL Harten, Lax and van Leer proved that when having a convergent solution, this method converges toward the physical and entropy satisfying solution of the conservation laws. For details see Toro [2009]. Do not use the HLL if you are dealing with shocks. HLL can’t handle contact discontinuities such as in shocks or shear waves: Keep that in mind, since when using HLL these waves will be missing solutions. In that case use the HLLC instead. U hll = The HLLC (Harten-Lax-van Leer, the C stands for contact) Riemann solver is a extension to the HLL, adding estimations of the missing contact and shear waves solutions. The last mentioned Riemann Solver, the Harten-Lax-van Leer-Discontinuities (HLLD) approximate Riemann solver is used in magneto-hydrodynamics environments. Since this work is focusing on hydrodynamics without electro-magnetodynamics effects this solver is not discussed further. The Riemann solver in CRONOS must be configured in the CAT-file (see section 3.2.3). 21 Limiter To avoid oscillations in the solutions provided by the Riemann solvers, flux limiters come to play. CRONOS supports the following Limiters: • No limiter • minmod • van Leer For this setup a empiric approach using the images from Toro [2009] should give a idea about the concept of Limiters. Figure 3.2: Overview over different test cases for the van Leer and minmod (mina) Limiter. Numerical solution (points) vs. exact solution (line) at time t = 0, t = 1 and t = 10. Taken from Toro [2009] Figure 3.2 shows the behaviour of the van Leer and the minmod (mina) Limiter in the following two 2 test cases: a gauss-profile u(x, 0) = αe−βx (a and b in figure 3.2) and a square wave (c and d in figure 3.2) according to 0 if x < 0.3 1 if 0.3 ≤ x ≤ 0.7 u(x, 0) = 0 if x > 0.7 Using a limiter, the edges of structures are smoothed. This results in less oscillations and better convergence properties than the plain Riemann solver. Further, the van Leer limiter smooths the edges 22 of the square wave less than the minmod limiter. This must be mentioned when the domain contains shock fronts. If dealing with strong and sharp structures in a simulation, the right choice of the limiter could become important. For a detailed overview of the different limiters the interested reader is referred to Toro [2009]. 3.1.3 Normalised Euler equations CRONOS internally solves the Euler equations (equation 3.3) in normalised form. The consequence of such a practice is that the Riemann solver is able to solve comparable problems in custom scaling. CRONOS is therefore able to perform simulations in arbitrary huge or small numerical domains. Originally used for the turbulent ISM [see Kissmann, 2006], this representation allows the downscaling to the parsec-scale (needed for the evolution of a PN) with only minor considerations. The dimensionless representation of the Euler-equations is given by the replacement the fluid variables with their normalised equivalents. The normalisation if fully determined by r0 , T0 , ρ0 and γ, all other normalisation constants can be derived from them. The replacement provisions are given in the following. A variable with a tilde on top (e.g. ã) is the normalised equivalent of the original (a). r ro v ṽ = cs t t · cs t̃ = = τ L ρ̃ = r̃ = ˜ = ρ ρ0 ρ0 c2s T T0 p p̃ = ρ0 c2s f f̃ = ρo c2s T̃ = (3.10) with the speed of sound r cs = γ kB T0 mH (3.11) is the internal energy. The total energy ẽ is defined as ẽ = 1 ˜2 ρ̃v |2 {z } + |{z} (3.12) Internal energy Kinetic energy The energy density is defined as the total energy per unit volume: ẽ = 1 ˜2 ρ̃v + 2 (3.12) The time scale for the simulation is determined by the spacial length and the speed of sound. The typical time length is therefore determined by τ= L cs With these replacements the Euler equation becomes δ ρ̃ ṽ + ṽ · ∇ṽ = −∇p̃ + f̃ δ t̃ (3.13) One can see that the form of the equation stays the same but the fluid fields ρ, v and p are replaced by their normalised equivalents ρ̃, ṽ and p̃. f becomes f˜ with the relation f˜ = f ρo c2s The normalised representation of the Euler-equations makes the internal handling very easy since the user defines the normalisation constant in the CAT-file and the code of the module is then independent on the scaling of the problem. The same module can then be applied on any arbitrary scaling without 23 modifications. A counter-part is the increasing complexity in the implementation of source terms. Many problems occur just because of wrong usage of the normalisation. Keep in mind that when applying a source term on the velocity, the energy has to be modified according to the following relation (if in full energetics mode, see section 3.1.4) ρL ∆Eges = ~v · f~ · (3.14) cs In terms of C++ code it becomes the following snippet Listing 3.1: Handling the internal energy when adding source terms // c_sound - Speed of sound . Make sure to use the value of the CAT file double c_sound = 1.0; void src_User ( Data & gdata , NumMatrix < REAL ,3 > nom [ N_OMINT ] , NumMatrix < REAL ,3 > nom_user [ N_OMINT_USER ]) { // Force field in x ,y , z d i r e c t i o n double force [3]; for ( int i_z = 0; i_z <= gdata . mx [2]; ++ i_z ) { for ( int i_y = 0; i_y <= gdata . mx [1]; ++ i_y ) { for ( int i_x = 0; i_x <= gdata . mx [0]; ++ i_x ) { // Add source terms to force - array // [...] // Add forces to v e l o c i t y field . Apply n o r m a l i s a t i o n rules nom [ q_sx ]( i_x , i_y , i_z ) += force [0]* rho / sqr ( c_sound ) ; nom [ q_sy ]( i_x , i_y , i_z ) += force [1]* rho / sqr ( c_sound ) ; nom [ q_sz ]( i_x , i_y , i_z ) += force [2]* rho / sqr ( c_sound ) ; // Apply force to energy field double Eges = ( gdata . om [ q_sx ]( i_x , i_y , i_z ) * force [0] + gdata . om [ q_sy ]( i_x , i_y , i_z ) * force [1] + gdata . om [ q_sz ]( i_x , i_y , i_z ) * force [2]) * rho * / sqr ( c_sound ) ; nom [ q_Eges ]( i_x , i_y , i_z ) += Eges ; } 3.1.4 Energy modes CRONOS supports two energy modes: Isothermal and full energetics. Choosing a energy mode will change the internal code on multiple sections. The resulting code is very fast, but a change in the energy mode requires a complete re-compilation. The total energy density for each cell is defined as ẽ = ρ̃|ũ|2 2 } | {z Kinetic energy if in MHD mode, the magnetic energy term emag = γ= p̃ γ−1 | {z } + (3.15) Thermal pressure |B|2 2µ0 is also included. γ is the adiabatic exponent: cv + R cv (3.16) The pressure is defined via the ideal gas law p = n · kB · T (3.17) If in isothermal mode, the energy is the kinetic energy and an additional thermal pressure term, that is equal on the whole numerical domain. The relevant energy for the isothermal case is therefore limited 2 to the kinetic energy ekin = ρ|u| 2 . 24 When using the full energetics mode, CRONOS uses internal a field called Etherm . This field is the energy density given in equation 3.151 . The first steps with CRONOS were made with a steady isothermal-wind. The idea was to start with the isothermal mode and slowly approach to the full energetics mode doing several tests on the numerical stability of the setup. A full description of the steps towards the full energetics mode is found in chapter 4. 3.1.5 Numerical domain As previous mentioned, a Cartesian grid is chosen for the numerical domain. The choice of the coordinate system must be done in the CRONOS code itself, and can not be changed after compilation. The size of the domain and the number of grid cells can be configured in the CAT file (see section 3.2.3). The numerical grid consists of a predefined number of grid cells. The number of grid cells in each direction can be configured individually and will be denoted as Nx , Ny and Nz . The actual size length of the numerical domain is denoted as Lx , Ly and Lz . CRONOS as of it’s current state uses internally a logical, isometric grid. The mapping of the coordinates at the i-th grid cell is given by xi = x0 + i∆x (3.18) yi = y0 + i∆y (3.19) zi = z0 + i∆z (3.20) with ∆{x, y, z} = L{x,y,z} /N{x,y,z} . Some internal functions (Riemann solver) need the derivative of the fields at the grid coordinates (i, j, k) (denoting the grid indices in x,y,z-direction). The numerical calculation of the first derivation in a 1D-grid of the field f at the i-th grid cell is denoted by fi0 and given by the following formula fi−1 − fi+1 2 · ∆x The numerical calculation for the second derivation fi00 is given by fi0 = fi00 = fi−1 − 2fi + fi+1 (∆x)2 (3.21) (3.22) The representation of equations 3.21 and 3.22 can vary since the upper formulas are approximations and there could be some correction terms - Details are found in the standard literature for numerical mathematics. It is important to realise, that the derivative functions depend on the values of their neighbour cells. Since the Riemann solver is applied on the whole grid, this could be a problem at the border cells, where no neighbours exist. The solution to this problem is the introduction of ghost cells - The grid is extended to a certain amount of additional cells (in practice 3 as needed for the second order derivative). With this extension, it’s possible to calculate all relevant derivatives on the whole numerical grid. Figure 3.3 illustrates a 1D-grid with 10 grid cells and three ghost cells in each direction. With this configuration it’s possible to calculate the third derivative in the whole 10 grid cells. Figure 3.3: Real grid (grid cells 0-9) and ghost cells. Using three ghost cells it’s possible to calculate the third derivative in the whole real grid domain. Additionally ghost cells are used to implement boundary conditions 1 Except when initialising the field. There it stands for the thermal pressure only. See section 3.2 for details. 25 The introduction of ghost cells has another important property: Boundary conditions. The Riemann solver cannot be applied on the ghost cells, since there are no derivatives available (neighbour cells missing). Boundary conditions determine the behaviour of these ghost cells. In practice it means, that after each time step the boundary conditions apply to the ghost cells and set their values instead of applying a Riemann solver to them. Boundary conditions could be for instance a reflection of values, making the grid periodic (think of a torus - what goes out right comes in left and vice-versa), a outflow of values of just set constant values. A detailed overview of the supported boundary conditions if found in section 3.2.3. For this thesis, the setup included a Cartesian grid and the HLL or HLLC-Riemann solver with two Runge-Kutta steps. 3.1.6 CFL-condition CRONOS uses the approach of discretised time steps. The time ∆t for a single timestep is determined by the CFL condition, formulated by Courant-Friedrichs-Lewy: ∆t ≤ ∆x vmax (3.23) The method used by the Riemann solvers is stable, as long as the CFL condition holds. With the CFL condition according to equation 3.23 it is possible to determine the current timestep. Additionally the value cfl threshold in the CAT-file can be used to fine-tune the timesteps. This becomes important, when additional source terms are implemented that modify the velocity field. Details are covered in section 4.1.1. 3.2 Technical point of view The following section should be seen as addition to the existing CRONOS Manual [Kleimann, 2012]. It summarises the most important parts for this work and extends it with experiences and knowledge acquired during the setup. Last but not least it should also provide a small documentation for user who want to improve the existing model and simulation codes. CRONOS is written in C++ and parallelized using OpenMPI. The different simulations in CRONOS are called modules. A single module consists basically of two different components: The module code and a CAT file. The module code is static and defines the physical framework in which the simulation runs. The CAT file is a plain text configuration file that is used to set the parameters for a simulation run (e.g. mass of central star, initial density, ecc.). The idea is to write the module code that is defining the underlying physical processes and (after compilation of the module) configure the environment parameters with the CAT file. The code (and so the physical processes) are relatively static and should not be touched if not absolutely necessary. However, the CAT file witch defines the environment parameters can be configured easily. 3.2.1 Setting up CRONOS The main characteristics of CRONOS are defined in constants.H in the User-directory. 26 Listing 3.2: constants.H defines the main behaviour /* ! Can be C R O N O S _ H Y D R O for a hydrodynamics - only or C R O N O S _ M H D for a magneto - h y d r o d y n a m i c e n v i r o n m e n t */ # define FLUID_TYPE CRONOS_HYDRO /* ! Number of Runge - Kutta steps . Default is 2 */ # define RK_STEPS 2 /* ! C o o r d i n a t e system to be used 1 = Cartesian 2 = Cylindrical 3 = S p h e r i c a l */ # define GEOM 1 /* ! Number of d i m e n s i o n s to use */ # define DIM 3 /* ! E n e r g e t i c s mode . S u p p o r t e d modes are FULL Running in full e n e r g e t i c s mode ISOTHERMAL Running in i s o t h e r m a l mode # define E N E R G E T I C S FULL /*! TRUE if user defined fields should be used */ # define OMS_USER TRUE /* ! If O M S _ U S E R is TRUE , this defines the number of user fields */ const int N_OMINT_USER = 2; The grid used by CRONOS contains the following fluid variables Fluid field Name Identifier ρ Density q rho vx Velocity in x-direction q sx vy Velocity in y-direction q sy vz Velocity in z-direction (if DIM = 3) q sz Eges Total energy (only if ENERGETICS = FULL) q Eges To help identifying the fields, CRONOS has a set of predefined integer values (”Identifier”). These identifier are makeing the code more readable, e.g. gdata.om[q_sx](x, y, z) = 0.0; gdata.om[q_sy](x, y, z) = 0.0; gdata.om[q_sz](x, y, z) = 1.0; By convetion, all user variables should be identified by comparable constants (e.g. q Tracer, q Gravity, ...). Additional to the build-in fields, there is a arbitrary set of user-variables. The number of USERvariables is set via N OMINT USER in the file constants.H (See listing 3.2). It is recommended to set the name of the user fields since these names are also written to the HDF5 output: gdata.om_user[q_Gravity].rename("Gravity"); This helps identifying the fields when doing the data analysis. Be aware that after changing constants.H you MUST run a make clean otherwise your changes won’t be applied in the next compilation process of make. 3.2.2 CRONOS module The user can create it’s own module by creating a class that inherits the superclass ProblemType. The most basic setup is a new class that overloads the method2 init fields (See listing 3.3) 2 In object-oriented programming a function of an object is called a method. 27 Listing 3.3: Obligatory methods for a CRONOS module class CronosModule : public ProblemType { public : CronosModule ( const Data &) ; virtual void init_fields ( Data & , int [] , int []) ; }; The method init fields is used to initialise the field when setting up the domain. This method is responsible for filling up the domain with a 1/ra -density profile (as used in this work), and all other initial values. When dealing with the full energetics equation, the field Etherm must be assigned as well. Be aware, that in the current version of CRONOS, Etherm in the method src User is the total energy density per unit volume. In init fields and in the HDF-5 output files Etherm is the thermal energy. In a future release of CRONOS this issue will be solved using the thermal -flag in the CAT-file. Since this is only a planned feature, at this stage the user has to remember when Etherm is the thermal and when it is the total energy density. Furthermore the user must define a problemtype-number. This number must be a unique key for the module and is used in the CAT-file to specify which module should be used. The CAT-file holds a row problem (e.g. problem = 42 ). This attribute must match to the problemtype-number of the module. It’s also necessary to extend the problemtype-number checking in the file modules.C according to listing 3.4. Details about the CAT-file are in section 3.2.3. Listing 3.4: Extend the problemtype matching in modules.C void Environment :: setType ( Data & gdata ) { int type = static_cast < int >( value (( char *) " type " ) ) ; if ( type == 63) Problem } else if ( type Problem } else if ( type Problem } else if ( type Problem } else if ( type Problem { = new linHydroWaves ( gdata ) ; == 42) { = new Mat hTestMod ule ( gdata ) ; == 43) { = new Pl an et a ry Ne bu l a ( gdata ) ; == 17753) { = new Ad ve ct i on Mo du l e ( gdata ) ; == 23) { = new Win dDiskMod ule ( gdata ) ; // [...] Even more problem types } else { cerr << " exit ( -22) ; Unknown problem type -- exiting " << endl ; } Problem - > init_problem ( gdata ) ; Problem - > set_InfoData ( gdata ) ; } Apart from the obligatory init fields-method there are other useful methods that can be overloaded. Listing 3.5 gives an extended example of a possible CRONOS module including a small doxygen documentation. 28 Listing 3.5: Extended methods for a CRONOS module /* ! E x t e n d e d CRONOS module s k e l e t o n code */ class E x t e n d e d C r o n o s M o d u l e : public ProblemType { public : /* ! C o n s t r u c t o r . Used to read and i n i t i a l i z e the module data */ E x t e n d e d C r o n o s M o d u l e ( const Data &) ; /* ! Method called once to i n i t i a l i z e the fields */ virtual void init_fields ( Data & , int [] , int []) ; /* ! Method for user - defined source terms */ virtual void src_User ( Data & , NumMatrix < REAL ,3 > [] , NumMatrix < REAL ,3 > []) ; /* ! Method for user - defined b o u n d a r y c o n d i t i o n s . If used , set the b c _ X _ b o t and b c _ X _ t o p values in the CAT file to 4. */ virtual void bc_User ( Data & , NumMatrix < REAL ,3 > & , int , int , int , int ) ; /* ! Method for user - defined fluxes */ virtual void g e t _ P h y s F l u x U s e r ( Data & gdata , cronos :: vector < REAL > & iPos , phys _fields_ 1D & pf , phys_ fields_1 D & pfUser , int dir , REAL shift ) ; /* ! Method called when the program writes to HDF5 . This can be used to store a d d i t i o n a l data to HDF5 */ virtual void WriteToH5 ( Hdf5Stream &) ; }; The method src User is used to implement user defined source-terms like gravity or radiative transfer. This method is the location where radiative transfer couples to the hydrodynamics. The method bc User is used for user defined boundary conditions. Since the intrinsic boundary conditions of CRONOS are not supporting the center region as boundary conditions, this has to be defined manually in this method. The last method, get PhysFluxUser is used to apply the calculated fluxes of a Riemann step to additional fields like a Tracer field, that can be used to trace particle flows. Since this is used for debugging purposes only, it is not discussed in details in this work. 3.2.3 CAT-File The CAT-file is used to configure your simulation. While the CRONOS module should implement the physical processes that are forming the environment, this file sets the boundary conditions and initial values, as well as the physical settings where the module operates on. It holds all parameters, including environment, OpenMPI and CRONOS settings in one file. Although most CAT-files are structured into different “sections”, CRONOS reads the file as a whole and does not divide this sections. The CAT-file is read sequentially using the format name = value While working with CRONOS, the CAT-file reader was extended to be able to handle also comments: Lines beginning with a minus (−), a semicolon (;), a number sign (#) or a double-point (:) will be ignored. Spaces after the name are ignored. If the value includes spaces, CRONOS will only read the value before the first space. This means the user can keep old values by leaving them in the CAT-file, separating the actual value from the ignored old value with a space. Listing 3.6 shows a small snippes from a CAT-file. 29 Listing 3.6: Snippet from a CRONOS CAT-file # Lines b e g i n n i n g with one of the f o l l o w i n g symbols are ignored : # ; : - # # MPI part # - - - - - - - - - - - - - - - - - MPI - - - - - - - - - - - - - - - # # Number of p r o c e s s e s in x ,y , z d i r e c t i o n nprocx = 2 nprocy = 2 nprocz = 2 # If the value part c o n t a i n s spaces , # the value until the first space is used # So here reorder = 0 will be applied , 1 is ignored reorder = 0 1 # These s e c t i o n s are found in most CAT - files # Keep in mind , that CRONOS itself does NOT r e c o g n i s e s s e c t i o n s ! # - - - - - - - - - - - - - - - - - Stuff - - - - - - - - - - - - - # cfl_min = 0.2 cfl_threshold = 0.4 # - - - - - - - - - - - - - - - - - Timing - - - - - - - - - - - - # runtime = 1440000 t_end = 120.0 dt = 1e -20 The CAT-file contains numerious configuration parameters. A listing of the most important values is shown in table 3.1. Additional to these parameters, each module holds it’s own set of configuration parameters. Name nproc{x,y,z} cfl threshold cfl min t end dt dt float dt mov mx, my, mz {x,y,z}b,{x,y,z}e type restart restart step Limiter RiemannSolver bc {x,y,z} top bc {x,y,z} bot thermal Isothermal Soundspeed Adiabatic Exponent Initial density Initial Temp ScaleGrid scale {x,y,z} rhomin pmin vmax Type Integer Float Float Float Float Float Float Integer Float Integer {0,1} Integer {0,1,2} {hll, hllc, hlld} {0,1,2,3,4,5} {0,1,2,3,4,5} {0,1} Float Float Float Float {0,1} {pi, e, 1} Float Float Float Description MPI: Define number of processes in x,y,z direction Value for global CFL-number Deprecated, originally used for the global CFL-number Simulation end-time Initial timestep Time after Float-output is triggered Time after Movie-output is triggered Number of grid cells in x,y,z direction Defines the domain size, from xb to xe, yb to ye, zb to ze Defines the underlying module. See section 3.2.2 and modules.C Start new simulation (0) or continue (1) existing simulation If restart = 1, defines the timestep from where to continue Limiter to be used. 0 = no limiter, 1 = minmod, 2 = Van Leer Riemann-Solver. See 3.1.2. In isothermal mode HLLC = HLL Boundary conditions, explanation in text Boundary conditions, explanation in text In src User the thermal energy (0) or the total energy(1) is used If isothermal this defines the speed of sound Defines the adiabatic exponent γ Fillup-value for the density ρ Fillup-value for the thermal energy Etherm (1) enables the grid-scaling factors defined in sclale {x,y,z} Possible scaling factors, if ScaleGrid is enabled. Lowest admissible density in simulation domain Lowest admissible pressure (See 3.15) Highest admissible velocity Table 3.1: Various generic CAT-file parameters The boundary conditions bc {x,y,z} bot and bc {x,y,z} top support the following values: 30 0 1 2 3 4 5 Periodic Periodic (deprecated) Extrapolation Outflow User-defined Reflection “Torus”: What goes out left, comes in right and vice-versa Deprecated periodic boundary condition. Use 0 instead Material flows out at border Defined in module via bc User method Reflecting material Caution when using the Outflow -boundary condition and source terms that point inwards: If there is a netto inflow (v < 0) at the border, it could produce numerical instabilities. The outflow-boundary condition expects the flux to flow out of the grid - the behaviour when having a inflow is not defined! The number of processes nproc used for the simulation is given by nproc = nproc · nproc · nproc x y z If running in parallel mode (OpenMPI), this number has to be the same as the number of processors defined when launching OpenMPI, otherwise CRONOS throws an error. In single-core mode this value is ignored. 3.3 VTK-Data processing The output of CRONOS is a HDF5-file per relevant time-step. For this thesis the float output is considered to have sufficient precision. Therefore the double-precision output is triggered less often, since this files have the double size and are only needed to re-start the simulation from a given point of time. Doubleprecision output files can be seen as checkpoints where the simulation can fall-back in case of a system crash or other failures. Initial when having a parallel run, CRONOS wrote a single file for each individual process. This results in a splitted grid with sometimes 16 or even more files per timestep. Therefore a converter utility was written, able to merge the splitted grids and convert them into plain VTK, used for ParaView3 . This issue was solved while working on this thesis, so that now the output of each timestep is a single, already merged HDF5-file. The converter is still used to convert the HDF5-file to VTK since these files are easier to handle in ParaView than the given HDF5-files. 3.4 CRONOS Objects For some test cases it’s necessary to put simple geometric objects in the grid. To make the treatment with some predefined geometric objects very easy, some auxiliary C++ objects are implemented with the aim, to provide a very simple and easy way to add several objects to the grid. The user creates a new geometric object with the desired properties and adds the object to the grid, without worrying about parallelisation or the internal implementation. As an example, applying the blanked out region (see section 4.1.1) is done with the following 3 http://http://www.paraview.org/ 31 Listing 3.7: Applying the blanked-out region from milestone 1 /* C o n s t r u c t o r used for c r e a t i n g CRONOS objects */ P la ne ta r yN eb ul a :: Pl an e ta ry Ne b ul a ( Data & gdata ) { /* Create the blanked out region object with the p a r a m e t e r s * r_0 = Radius * rho_0 = Density to i n i t i a l i s e * v_0 = Radial v e l o c i t y at the border */ # if ENERGETICS == FULL this - > blank_region = new PN_Blan kRegion ( r_0 , rho_0 , v_0 , value (( char *) " E_Central " )); # else this - > blank_region = new PN_Blan kRegion ( r_0 , rho_0 , v_0 ) ; # endif void P la ne ta r yN eb ul a :: src_User ( Data & gdata , NumMatrix < REAL ,3 > nom [ N_OMINT ] , NumMatrix < REAL ,3 > nom_user [ N_OMINT_USER ]) { /* Removes all fluxes on the blanked out region */ this - > blank_region - > apply_src ( gdata , nom , nom_user ) ; } void P la ne ta r yN eb ul a :: init_fields ( Data & gdata , int ibeg [3] , int iend [3]) { /* I n i t i a l i s e blanked out region */ this - > blank_region - > apply ( gdata , ibeg , iend ) ; } 3.4.1 Structure: Objects vs Field A CRONOS objects consists of two different parts: A operation and a geometric object. The operation defines what to do, the geometric objects defines the place where to do it. The following operations are currently available: • Setting the velocity (VelocityField ) • Setting the density (DensityField ) • Setting the energy (EnergyField ) • Removing all fluxes (StaticField ) • Apply gravity (GravityField ) Operations must be applied on concrete geometric objects. They limit or define the location or space where the operation has to be applied. The following geometric objects are currently implemented: • Disk • Sphere • Universe • Cube Each geometric object has a origin and two angles θ and φ. The angles define the orientation in the grid, the origin defines the offset from the (0,0,0) position. Apart from this basic properties additional parameters are needed for the concrete objects. The idea is now to define a geometric object, and let a field act on that object. An example is given in listing 3.8. 32 Listing 3.8: Example of using CRONOS objects void ObjectExample :: init_fields ( Data & gdata , int ibeg [3] , int iend [3]) { /* First define the disk */ REAL r_0 = 1.0; // Inner disk radius REAL r_1 = 5.0; // Outer disk radius REAL h = 0.5 // Disk height REAL theta = M_PI / 2.0; // D e c l i n a t i o n REAL rho = 10.0 // Density to apply Disk * disk = new Disk ( r_0 , r_1 , h ) ; disk - > setTheta ( theta ) ; /* Create the density field and apply it */ DensityField * densityField = new DensityField ( disk , rho ) ; densityField - > apply ( gdata , ibeg , iend ) ; /* Cleanup */ delete densityField ; delete disk ; } With this approach of decoupled geometric objects and operations to perform on them, the user has a powerful toolbox for creating arbitrary environments. An extended example and description of the CRONOS objects is found in Appendix C. 33 Chapter 4 Implementation This section covers the concrete implementation and the setup of the numerical simulation using CRONOS. As previously discussed in chapters 2 and 3, the realisation was done by taking the model considerations as isolated test cases. This ensures numerical stability and decouples the different stages of development from each other. On errors, only the responsible part has to be replaced, leaving all other parts untouched. To ensure correctnes and to monitor the development progress, a roadmap that defines the concrete intermediate goals was made. This roadmap includes different milestones, that will be discussed in this chapter. 4.1 Roadmap The approach of this work was to define certain milestones as fall-back points. Once a milestone is implemented, several tests have to be passed before advancing to the next milestones. Some milestones depend on the successful and accurate implementation of previous ones. Before advancing to the next goal, procedures to test the correct implementation and to ensure code quality are done. This concept allows us to test the actual setup in isolated test cases and fall back, if something goes wrong. To ensure physical correctness and numerical stability, several different test cases for each milestone are build. This effort on each milestone could be seen as time-consuming on the short time-scale, but in the long term it is the only possibility to establish a correct working environment. 4.1.1 Milestones For this thesis the following milestones are defined on the roadmap: 1. Blanked out region 2. Isothermal stellar wind 3. Gravity 4. Photon momentum transfer 5. Radiative heating and cooling / CLOUDY 6. Evolution of a planetary nebula This is the complete roadmap towards the simulation of a planetary nebula using 3D-radiativehydrodynamics. The complete setup would be too much work for a Master thesis - the first three milestones are implemented and merged together by using an additional intermediate step. Most milestones depend on each other. This means it’s necessary to complete the previous milestone and ensure correct behaviour. If something goes wrong on a underlying milestone it’s obligatory to fall back to that point and correct the issue before proceeding. This structure allows us to build several fall-back mechanisms - errors are easier found and can be corrected also in the late development cycles. 34 The dependency of the different milestones is shown in figure 4.1. Figure 4.1: Illustration of the dependencies of the different milestones. As the complete implementation of a 3D-radiative-hydrodynamics simulation is far beyond the bounds of a Master-thesis, the first three milestones are implemented in this thesis. Milestone 3 is splitted into two different stages: • Full energetics mode • Gravity Splitting the milestone instead of making two separate one was done, because the two stages strongly depend on each other. Basically, the gravity was only implemented to test the correct implementation of energy source terms - Central gravity from the star doesn’t play a relevant role in the evolution of a PN but it is a excellent testing ground for the correct behaviour of source terms and forces. Typical values for the boundary condition are the following: With a density of about 10 mH /cm3 and typical wind velocities of about 10 − 50km/s, for a distance of 0.01 pc the kinetic energy in in the range of 1.16 · 10−19 − 2.91 · 10−19 J, while the potential energy is about 3.24 · 10−36 J. The further away, the less relevant the potential energy becomes. mH representing the mean atomic weight in solar conditions, so mh ≈ 1.4 · mamu (where mamu is the atomic mass unit - mamu = 1.660538921 · 10−27 kg). The relation of kinetic energy towards the potential energy is about Ekin /EGrav ≈ 3 − 10 · 1016 Gravity towards the central star does not play a role in the formation of a planetary nebula beyond 0.01 pc. In the simulations the only place where gravity could become important is within the blanked out region and therefore not part of the numerical domain. 35 Milestone 1: Blanked out region Milestone 1 is the basement for all future processes. As discussed in section 2.1 the inner region of the PN (the CSPN and the surrounding environment) is considered as boundary condition. This means a mechanism that sets the values of the inner region to well defined values after each simulation timestep is needed. Implementing the blanked-out region as a static boundary condition is a crucial step as all further processes are based on this assumption. The blanked out region is in the range of 0.01 − 1 pc, so the star in the center is far below the grid resolution (even smaller than a single pixel!). To achieve a quasi-spherical structure, the boundary condition must be large enough: A sufficient amount of pixels is crucial for the blanked out region itself and the numerical stability. The blanked out region must contain at least sufficient pixels for the Riemann solver, otherwise the second order derivative is not accurate (see equation 3.21). A illustration of the established blanked out region is shown in figure B.1 in Appendix B. The goal of Milestone 1 was to getting started with CRONOS: Set up the build chain, compile CRONOS, create a user module, defining the environment and configuring the CAT file. It’s a very rough approach to set the boundary conditions to constant values. This could lead to undesired instabilities on the border, caused by the interaction with this regime. The used Riemann solvers depend on higher order derivatives of the field values to calculate the fluxes of the grid cells. As discussed in section 3.1.5, the second order derivative of a 1D-grid cell for instance is calculated via x00i = xi−1 − 2xi + xi+1 (∆x)2 (3.21) Where xi is an arbitrary field at the i-th grid cell. The value at the grid cell xi influences not only the derivative af position i, but also the numerical derivative of the neighbouring cells. Setting rough boundary conditions that are far apart from the field values will inevitable disturb the domain at the edges. This could produce oscillations or other nonphysical phenomena due to numerical effects just because of the rough boundary condition. This is an issue that can only be solved by a clever choice of the boundary condition values and that has to be tested for each set of environment values individually: A process that will go through the whole building process and also future milestones. To keep these numerical effects small enough to be neglected, the domain must be sufficient large. The cells close to the inner boundary condition may be not accurate but will stabilise further away. Therefore the surrounding cells around the inner (and outer) boundary condition should be faded out when doing the data analysis, since they could include some undesirable effects due to the boundary conditions. Figure 4.2 shows a density plot of the initial 1/r density profile with the blanked out region plateau in the middle. Figure B.1 (Appendix B) visualises the density of a central XY-slice at the inner boundary condition. The density-profile was chosen as 1/r profile, because it’s the profile that is needed in milestone two. Milestone 2: Wind with gas pressure Milestone two builds up on milestone 1 since the inner boundary condition is used. In practice milestone two extends the constant inner region with the model considerations of a isothermal wind with gas pressure only (as discussed in section 2.3.1). Milestone 2 is fulfilled by defining a (constant) mass loss rate at the inner region. Since the theoretical considerations behind milestone two are based on the assumption of spherical symmetry it’s necessary that also the inner region is spherical - a condition well fulfilled by the blanked out region. The edges of the blanked out region define the border, where the values for the constant mass loss rate are set in the field. The mass loss rate corresponds to the outflow of a stellar wind at a constant rate. Ṁ = 4πr2 ρ(r)v(r) = 4πF = const (4.1) where r is the distance from the center of the star and F is the mass flux. Using the HLL or HLLCRiemann solver (a conservative Riemann Solver, see section 3.1.2 for details), the mass loss rate in each shell around the same center must be the same (assumption of the isothermal wind with gas pressure) 36 since this is a requirement of the assumption and a property of the given Riemann solvers. The idea is now to test the numerical stability of the inner boundary condition and of the environment by setting a initial unphysical environment, that is not too far away from the expected solution and let the system evolve. As the system evolves, beginning from the source of the mass loss rate, the system should now converge towards the physical solution of the isothermal wind outside the sonic point. This can be checked by calculating the mass loss rate for each individual shell and comparing it to the mass loss rate at the inner boundary condition (see figure 4.4). Figure 4.2: Plot of the initial 1/r density profile with the blanked out region (plateau). The values are on a radial slide through the center of the domain. The initial velocity was set to zero on the whole grid. The density is set as an 1/r-function according to r (4.2) r0 where the parameters ρ0 and r0 are defined in the CAT-file. A plot of the initial density function at the x-axis is shown in figure 4.2. Since in this milestone a isothermal wind is considered, the pressure is internally calculated by CRONOS by assuming the same temperature in the whole domain - as consequence the resulting pressure is proportional to the density ρ(r) = ρ0 · pisotherm ∝ ρ The velocity of the inner boundary condition is set to a given value v (defined in the CAT file): The initial velocity is zero except for the inner boundary condition. After some timesteps the velocity field increases due to the initial density profile. At this stage the mass loss rate at the outer shells is far apart a constant value - each shell has it’s own mass loss rate, configured by the initial unphysical state. Beginning from the innermost shell, the isothermal wind now blasts into the medium that itself tries to stabilise. Heavy initial fluctuations in the density and velocity fields are found across the region - they converge to a stable solution but are blown away by the stellar wind in the supersonic regime that comes from the blanked out region. A plot of the evolving velocity if shown in figure 4.3. Thus the expectation for the mass loss rates of the individual shells is to converge in time towards a constant value across the whole grid. 37 Figure 4.3: Evolution of the velocity at a radial profile through the XY-pane. The initial fluctuations are stabilised by the stellar wind in the supersonic regime coming from the blanked out region. In all test cases this convergence of the mass loss rate could be observed using different Riemann solvers, as shown in figures 4.4 and 4.5. The chronological sequence is the following: The initial profile is unstable and stabilises itself within some few timesteps. The resulting mass loss rate is unphysical and increasing in respect to the distance from the center (see figure 4.4). Beginning from the innermost shell, the correct constant mass loss rate stabilises and propagates with the stellar wind towards the border. The initial semi-stable mass loss rate coming from the 1/r-density profile is blasted away. While this evolution takes place, a shock wave, also created by the initial conditions, propagates from the center to the outer region. This shock wave can be seen in figure 4.7 as collage and in figure 4.4 as an increased mass loss rate and is illustrated in figure 4.6 - it leaves the field without artefacts. In time the whole domain converges towards the correct solution, although at the innermost and the outermost grid cells some numerical artefacts in form of arch-shaped curves are observed (figure 4.5). 38 Figure 4.4: Evolution of the mass loss rate at a radial profile through the XY-pane. It can be seen, that the initial mass loss rates gets pushed to the outside, while beginning from the center of the stellar wind, the physical solution propagates and becomes stable Figure 4.5: Same as in figure 4.4, but using the HLLC Riemann solver. The differences are only marginal and not even visible in this plots. Figure 4.6 shows the evolution of the mass loss rate in the first timesteps. The mass loss rate is increasing before it converges toward the expected constant value (around timestep 90). This initial increase results in the above already mentioned shock wave: A devastating construct that disrupts the initial density distribution while propagating towards the borders at supersonic speed. The supersonic speed of the shock wave and as well as the supersonic speed of the resulting steady-state solution is a 39 result of the isothermal assumption. Although this solution is analytically correct, the physical value is questionable. The isothermal wind beyond the sonic point does not correlate with observations, since the wind cools down - an so does the acceleration. Nonetheless the knowledge of the correct solution makes this case ideal for testing the behaviour of the simulation setup. Furthermore this shock wave is an ideal construct for comparing the different Riemann solvers (HLL and HLLC) since supersonic waves and shocks are present. Using this setup, both, the HLL and HLLC Riemann solvers, lead to the correct solution of the assumed constant mass loss rates. There are only marginal differences in the field values (several orders of magnitude below the significant values). The resulting plots for the evolving mass loss rates are shown in figures 4.4 and 4.5 for the HLL, respectively the HLLC-Riemann solver. Figure 4.6: Evolution of the mass loss rate at a radial profile through the XY-pane. Initial the mass loss rate is zero because the velocity is set to zero on the whole grid (see equation 2.2). Driven by the initial 1/r-density profile a unphysical and in time increasing outflow emerges. This outflow result in a shock wave heading towards the border. Around timestep 90 the mass loss rate decreases toward the correct solution. The initial unphysical fillup fades away. Additional tests on the numerical stability were done using different grid sizes. The domain size of the plots was 1 pc and the wind velocity v = 1.0 ciso . The isothermal speed of sound was set to ciso = 12.000 m/s. Conclusion of this milestone: Both used Riemann solvers (HLL and the HLLC) yielded the correct solution for the mass loss rate using a isothermal wind with gas pressure only. Figure 4.2 displays the radial density profile in the XY-pane. After some timesteps the initial density profile is disrupted by a shock wave, that is created by the initial unphysical conditions. The field values converge toward the correct solution for the stellar wind beginning from the center to the border. The field values near the borders are considered as inaccurate due to numerical artefacts as can be seen in figure 4.4 (the arc curves at the edges). The quintessence of this milestone improves the model that is considered for the future evolution of a PN: As shown in the dynamic evolution of the expected values it is important to fill the initial field and then let the system come to a stable state. When dealing with a PN it may be important to initially fill the domain with some values, let a static stellar wind converge toward it’s steady state and begin with the superwind phase, when this steady state is reached. This means that at this stage already two different phases are needed, before the first wind phase of a PN (the superwind) can begin! 40 Figure 4.7: Collage of the density-slide at the center of the domain. One can see the evolution of the density and the initial shock wave before the domain converges to a stable density-profile Milestone 3.1: Full energy mode Milestone three is divided into two different stages: 1. Full energetics mode 2. Gravity In the evolution of a PN, central gravity towards the CSPN doesn’t play a relevant role. Outside the blanked out region the distance to the central region is so huge, that the gravity force density fG is very close to zero already at the border of the blanked out region (r0 ), and becoming even smaller at larger distances: fG = G · M∗ · ρ →0 r02 (2.8) But gravity is a ideal force for testing the correct implementation of energy source terms. So it is the test case for switching to a full treatment of the energy equation (3.12). ẽ = ρ̃|ũ|2 p̃ + 2 γ−1 (3.15) Switching to FULL ENERGY mode is done in the file constants.H with the definition of the C-define ENERGETICS. Listing 4.1: Switching between ISOTHERMAL or FULL ENERGETICS mode in constants.H // Choose this define for a i s o t h e r m a l energy t r e a t m e n t # define ENERGETICS ISOTHERMAL // Choose this define for the full e n e r g e t i c s t r e a t m e n t # define ENERGETICS FULL Changing the energy mode influences the structure of CRONOS at multiple critical parts. After making such changes, a re-compilation of the whole CRONOS code has to be performed. 41 When dealing with the full energetics equation, the field Etherm becomes visible. The field Etherm is used differently in different methods: In the method init fields, Etherm is only the thermal energy. In src User Etherm represents the total energy density, and in the output HDF5-file Etherm is again the thermal energy only. In a future version of CRONOS it is planned to handle Etherm also in src User as thermal energy density, but at the time this thesis was written, Etherm was still the total energy density per unit volume. This means basically, that the kinetic energy must be added or removed when the velocity field is modified. The velocity field is the interface to additional source terms. The following equation described, how sources in terms of forces have to be added to the velocity field: f =ρ· f dv ↔ dv = dt dt ρ (4.3) In addition, the scalar product of the force and the velocity has to be added to the energy dE = f~ · ~v (4.4) dt Appendix A gives a detailed view of how to implement additional forces and how to apply the normalisation rules of the normalised Euler equations. In the HDF5-output file, Etherm is then again the thermal energy only (kinetic energy not included). Now this energy density (Etherm ) is the interface between the hydrodynamics and the radiative transfer: radiative transfer mechanisms transport thermal energy in form of radiation across the domain and cooling and heating mechanisms will change Etherm after a hydrodynamic timestep. This is not part of the current setup, but show the importance of the correct treatment of the energy density when adding source terms like radiative heating and cooling or photon momentum transfer. When such source terms (like gravity) are added to the numerical model, the energy Etherm has to be modified according to equation 4.4, otherwise the energy balance will be inconsistent. When changing the velocity of a grid cell, the corresponding change of kinetic energy also has to be taken into account. The following code snipped was created to handle the energy change resulting from the force terms. It is designed in a way, that additional forces (like gravity or photon momentum transfer) can be added without worrying about the energy balance and normalisations. Listing 4.2: Handling the internal energy when adding source terms REAL Eges = ( gdata . om [ q_sx ]( i_x , i_y , i_z ) * force [0] + gdata . om [ q_sy ]( i_x , i_y , i_z ) * force [1] + gdata . om [ q_sz ]( i_x , i_y , i_z ) * force [2]) * rho / sqr ( c_sound ) ; nom [ q_Eges ]( i_x , i_y , i_z ) += Eges ; Listing A.1 in Appendix A gives an extended code example how to handle the internal energy when adding additional force source terms. Another important issue is to fulfil the CFL-condition in the presence of source terms. The CFLcondition (see equation 3.23) guarantees a stable numerical solution by defining the maximum timestep dt, so that the flux in each grid cell influences only the direct neighbour cells. The timestep dt is computed from the CFL condition ∆t ≤ ∆x vmax (3.23) and then multiplied with a custom defined cfl threshold : dt = cf lthreshold · ∆t In the presence of source terms, the modified velocity field could possibly violate the CFL conditions. At the current stage it is therefore necessary to set the CAT-file value cfl threshold to sufficient small values. Otherwise, the CFL-condition could be violated by applying the source terms. A violation results in a crash or (even worse) numerical instabilities that are difficult to trace back. On the other hand, a too low cfl threshold triggers lots of unnecessary calculation cycles, resulting in a very poor performance. 42 It is under discussion, if in a future release of CRONOS a method (e.g. cfl User ) is implemented, where the user module can actually influence the CFL-value of a timestep to avoid this issue. Milestone 3.2: Gravity In this thesis, gravity is considered as probing ground for the setup of source conditions. Although gravity towards the CSPN does not play an important role in the evolution of a PN, the simplicity of the force and the known results of Kepler orbits makes Newtonian gravity an efficient test case. A central star that lives within the blanked out region and a given mass M∗ is considered and, as usual, defined by the values of the CAT-file. The distances and mass of the star must not represent realistic physical values for the PN in this scenario. The initial filled environment with a initial (weak) stellar wind has now some time to converge towards a hydrostatic stable solution, before some small density crumbs are arranged on a horizontal plane around the central region. This can be seen in the first tiles of figure 4.8. The density crumbs are set to Kepler speed according to r GM∗ vK = r Each pixel of the crumb gets the same Kepler speed, calculated at the center of the chunk. (2.9) Going forward in time they should build stable orbits around the central region. Although the crumbs are in pressure equilibrium with the environment, they are smearing out with time, because of the nature of the hydrodynamics simulation. The smearing-out effect can be seen in figure 4.8. Figure 4.8: Volume plot-collage of the evolution of the density. Initially the environment has time to come to a hydrostatic state. Then some small density crumbs are arranged around the central region. The crumbs have Kepler speed and are moving around the region, while smearing out. In this setup the density crumbs are extend over multiple pixels. As each pixel has a individual distance to the center r, also the Kepler speed according to equation 2.9 would be different in respect to the neighbour pixels. In the test cases, the whole crumb gets the same averaged Kepler speed. The distance for the Kepler speed is the distance from the center of the star to the center of the crumb. Consequently the inner pixels of the crumb have a effective velocity below the Kepler speed, the outer pixels above the Kepler speed. This accelerates the smearing-out effect even more and can be seen in figure 4.8: The inner part of the crumbs are too slow an fall towards the center, while the outer parts are too fast and gain distance from the star. The crumbs diffuse, the inner and outer parts repair to new stable Kepler orbits r∗ . In this test case, the CFL value has to be minimised. The used value was 0.02 instead of the default value of 0.4: # From the CAT file cfl_threshold = 0.02 43 This is important since otherwise the CFL-condition is violated by the additional source terms, respectively the gravity force. This behaviour is discussed in the previous section (see 4.1.1). Conclusion of this milestone: The energetic mode increases the complexity and CPU time of a simulation. The user has to be aware how to implement source terms and add their corresponding energy according to ∆E = f~ · ~v · ∆t (4.4) Forgetting to add the energy for source terms or sluttishness in the normalisation is a common source of errors that often (but unfortunately not always) results in a crash of the program. To reduce this errors, use the force template (see listing A.1 in Appendix A). When dealing with forces that influence the source terms be aware not to violate the CFL-condition. It could be necessary to lower the parameter cfl threshold in the CAT file. It is in discussion to let the user module influence the choice of the timestep dt, although this is currently computed according to the CFL-criterion. A small CFL-value increases the CPU cycles for the simulation. The user module could reduce the amount of additional (unnecessary) calculations by influencing the timestep dt according to it’s grid values. This step is in discussions with the CRONOS maintainer. 4.1.2 Milestone 4: Additional numerical tests After the successful handling of gravity as source term and the correct implementation of the isothermal stellar wind, additional tests that include both cases with the full energetic treatment are done. These test serve as intermediate milestone where the project could fall back, if there are serious issues in the next steps. The setup is based on the previous milestones, the following features are re-used: • Blanked out region (Milestone 1) • Stellar wind (Milestone 2) • Full energetics mode (Milestone 3) This milestone is based on the experiences for the Mexico-poster [Niederwanger et al., 2014] where the idea was to create a dense isothermal disk that explodes, forming two bipolar jet-like structures. For the presentation in Mexico, the simulation was still isothermal, a full energetic treatment was implemented in milestone 3 after the conference. As discussed in milestone 3 (see section 4.1.1), three different phases for the stellar wind are needed: 1. Initial fill-up 2. Initial convergence to hydrostatic equilibrium 3. Insertion of the disk and fast wind The initial fill-up was done with a more realistic 1/r2 density function and a wind velocity of zero throughout the whole domain, except for the blanked out regio, where the stellar wind blasts off with a velocity of v = 1.0 cs . The initial fill-up is will converge towards a hydrostatic equilibrium. It’s not possible to fill the whole domain with parameters for the constant mass loss rate, since this was an assumption for the isothermal stellar wind and this milestones implements the full energetics equation according to 3.15. After the domain is in hydrostatic equilibrium (phase 2), a disk with a higher density but at the same pressure as the surrounding environment is inserted abruptly (phase 3). The disk looks like in figure 4.9. When the disk is inserted, also the stellar wind blasts off immediately faster. This fast supersonic wind forms a shock wave. From a initial velocity of v˜0 = 1 it is set to v˜1 = 8 with a increasing thermal energy at the inner boundary conditions from E˜0 = 102 to E˜1 = 104 . The values are in the dimensionless representation of the Euler equations (See section 3.1.3 and Appendix A). The fast stellar coming from the center is supersonic and hot. The material from the initial full-up is shocked by the stellar wind and can be seen as shock wave. The shock wave is propagating from the center towards the borders. As the disk that is inserted into the numerical domain is in pressure equilibrium with it’s environment, it represents a dense, cold barrier for the fast stellar wind - The shock wave is slowing down, while kinetic and thermal energy are transferred to the disk. As a result, the disk’s pressure increases and it is dissolving 44 Figure 4.9: After the initial fill-up and the convergence towards a hydrostatic equilibrium, a high-density disk is inserted (contrast 1 : 10). from the inner part. Figure 4.10: Evolution sequence - An disk in pressure equilibrium with the environment is disturbed by a fast and hot stellar wind. The stellar wind shocks the surrounding material and forms a expanding shock wave. This wave is restraint by the density disk, that is torn apart as a result of the interaction with the shock wave and the stellar wind. The same evolution sequence at higher resolutions is shown in figure B.3 in Appendix B A sequence of the evolution is shown in figure 4.10. In this sequence and as well in the Mexico presentation, bipolar structures evolved. In comparison to the evolving bipolar jet-like structures of the Mexico presentation, these structures are less jet-like and the result looks more like a hourglass. The reason is the full energetic treatment: In the isothermal environment, the pressure is proportional to the density pisotherm ∝ ρ This makes it impossible to form high-density structures in a isothermal regime that not strive to explode. In full energetics mode, the thermal energy field Etherm allows us to form a (almost) stable disk in pressure equilibrium that is later torn apart from a heat and/or momentum source. In this case the shock 45 wave with it’s supersonic velocity and high density disrupts the disk, while in the Mexico presentation the isothermal pressure caused the disk with it’s increased density to explode more homogeneous. Initially all structures are deployed around the y-axes. To ensure that the evolving structures are formed because of underlying physical behaviour and are not a result of numerical preferableness toward the main axes, the disk was set offset from the center and declined by a arbitrary angle φ. With this configuration the possible numerical discrimination towards the main axes is excluded. In both cases (Mexico and this test case) the same bipolar structures evolve regardless of the declination angle φ - The test of the numerical stability can be seen as fulfilled in both cases. Figure 4.11: Artificial disk with a density contrast 1 : 10 from three different viewpoints at two different resolutions. The size of the numerical domain is the same. The upper images show the disk in a grid with 323 cells while the lower images are created from a grid containing 643 cells. Determining and testing the numerical resolution The configuration of a declined disk is in addition a good indicator for the needed resolution. Figure 4.11 shows he same disk at different resolutions. The resolution is defined as the number of grid cells in each direction. The size of the numerical domain stays the same, only the number of grid cells differ in each picture in figure 4.11. The grid size must be chosen very carefully: Increasing the grid size, increases the numerical resolution but also the calculation time. Duplicating the grid size by a factor of two in each direction, make the simulation 23 = 8 times as expensive. Choosing a resolution that is too low, causes numerical instabilities. A compromise between stability and runtime must be found. For each simulation run and each configuration the domain size and the resolution must be chosen very carefully. Increasing the resolution when numerical stability is reached is a waste of CPU time, as the increasing resolution yields the same solution, only with increased grid cells and more costs in computational time. The pictures of figure 4.11 show, that the disk is composed of different pixels. With time, the initial disk dissolves as shown in figure 4.10. To determine the correct resolution, a simulation using the same physical environment parameters was performed. The chosen resolutions were 163 , respectively 323 , 643 , 1283 and 2563 grid cells. A plot of identical times during this simulation run using the mentioned resolutions is shown in figure B.3 in Appendix B. It can be clearly seen, that too low resolution do not reflect the correct physical behaviour. The disk dissolves as it should be, but the expected cylindrical-symmetric cloud, clearly visible at higher resolutions, does not form. This is because of the poor resolution and it’s following numerical instabilities. With this small grid size, the formation is suppressed - The yielded solution is inaccurate, the resolution is too low. 46 Although the solution with 1283 grid cells looks accurate, another simulation run that doubled the resolution of the numerical domain to 2563 shows heavy turbulences. It seems that turbulence becomes active on this resolution due to the choice of cylindrical spherical structures in a Cartesian grid. The overall solution at 2563 grid cells stays about the same as in the lower resolution runs, but turbulence forms details that are not found in lower resolutions. The turbulent structures are independent on the choice of the Riemann solver (tested with HLL and HLLC) using the Van-Leer limiter. A comparison of the resolution 1283 and 2563 grid cells is shown in figure 4.12. Figure 4.12: Comparison of the same timestep t = 88.60 between 1283 (left) and 2563 (right) image. The resolution is high enough so that turbulence effects (because of the spherical structure in a Cartesian grid) comes into play. The resolution differs strongly in the details. The global solution stays about the same. With increasing resolution, also the computational time and the size of the output HDF5 files increases about linear in each direction as can be seen in figure 4.13. Figure 4.14 shows that a single process on the local computer is even slower than a parallel run using multiple processes. If the number of processes is increased simultaneous with increasing grid size, the overhead of process synchronisation is negligible. The runtime stays about the same, if the number of processes is increased with the number of grid cells. Conclusio of this milestone: The choice of the Riemann solver should be HLLC when dealing with shock waves, although in this test cases no relevant differences between the HLL and HLLC Riemann solvers could be observed. It’s important to set the numerical resolution to sufficient high values to ensure numerical stability. Turbulences and other unexpected structures could evolve in the Cartesian grid when inserting spherical objects if the grid size is inadequate. The numerical resolution should be high enough to yield the correct solution, but not too high, not to waste unnecessary CPU time. The resolution depends on the concrete configuration of the numerical domain (domain size, forces, ecc.) and on the Riemann solver (including the CFL-values as discussed in milestone 3). With this milestone the ability for CRONOS to deal with the double-wind model and possible initial objects in the field is shown. Initial objects like a disk could contribute to the different asymmetrical shapes found in observations of PNe. This point needs further investigation and will be a part of future works. With the setup created within this thesis, the ability to produce accurate hydrodynamics simulations with arbitrary objects is shown. 47 Figure 4.13: Runtime plot on the same simulation using different grid sized. The runtime increases approximately linear with the grid size. Figure 4.14: Runtime plot on the same simulation using different grid sizes and processor count. The synchronisation-overhead when using multiple processors is negligible. When using large grid sizes, one process is slower than multiple processes. 48 Chapter 5 Outlook As previous already discussed, the goal of the project is the implementation of a full 3d radiativehydrodynamics simulation environment for the formation of planetary nebulae. As this is far beyond the bounds of a MSc thesis, the first steps towards a full setup are done. For the current stage of the implementations see chapter 4. Figure 4.1 shows a illustration of the roadmap towards the full 3d radiative-hydrodynamics simulation. With this theses the ability to implement the desired double-wind model and possible initial objects in the numerical grid is shown. Further steps are the implementation of radiative transfer and photon momentum transfer. This will be done in a successive work. 5.1 Summary of the current stage The latest achieved steps are described en detail in section 4.1.2: The actual implementation of additional numerical tests, to test all previous achieved steps in the implementation. The result is a simulation of a fast and dense wind blasting against a high density disk that is in pressure equilibrium with the environment. As the wind has a increased velocity and thermal energy compared to the previous wind (the environment converged towards hydrostatic equilibrium) it overhauls the last stellar wind forming a shock wave that propagates toward the border. A high density disk (density contrast 1 : 10 and higher) was put in the environment when the fast wind started, forming a barrier for the evolving new fast stellar wind. The disk is declined by an arbitrary angle φ to avoid numerical artefacts, caused by numerical preference towards to main axes in a Cartesian grid. The result of this simulation is shown in figure 4.10. This simulation was done with several parameters, varying in grid size (resolution), disk declination and density contrasts. Within this test, the numerical stability and the correct implementation of the previous milestones was shown. Turbulent structures coming from the spherical object in the Cartesian grid are observed at the ultimate simulations. If the grid size is sufficient large we could not find relevant differences in this test case between the HLL and HLLC Riemann solvers and the used minmod and Van-Leer -limiters. The setup implements additional source terms between the hydrodynamic steps that are processing the inner blanked out region and non-hydrodynamic forces like gravity (and in the near future also photon momentum transfer and radiative transfer mechanisms). This additional forces must not violate the CFL-condition according to equation 3.23: ∆t ≤ ∆x vmax (3.23) As the timestep for any hydrodynamic step is chosen by the Riemann solver according to the CFLcondition multiplied by a CFL-threshold factor, the user must set the CFL-threshold low enough to ensure the CFL-criterion is not violated (see section 3.1.6). For the last described test gravity as neglected, therefore we do not needed to set the CFL-threshold below that of a simulation that is driven by hydrodynamic-forces only. But if dealing with additional source terms, the correct choice of CFLthreshold, the Riemann solver and a suitable limiter could become an important issue. Of milestone 3.1 the simulation threads with the full energy equation according to ẽ = 1 ˜2 ρ̃v + 2 49 (3.12) (see section 4.1.1). , representing the internal energy of a grid cell, can be seen as thermal energy or as pressure. is implemented in CRONOS as the field Etherm and is the main interface to radiative transfer mechanisms implemented in a successive work. 5.2 5.2.1 Further steps Photon momentum transfer Based on the latest setup, the next step is to implement photon momentum transfer as an additional force between each hydrodynamic timestep. This is done in the src User method (see section 3.2.2). The source of photons for the photon momentum transfer is the CSPN. This means, that the inner grid cells will get the greatest velocity gradient at each timestep. CRONOS at this stage threads the grid as isometric grid. The CFL-criterion (see equation 3.23 and section 3.1.6) must be fulfilled within the whole grid. To achieve this goal, the CFL-threshold must be set to an adequate value. At this stage, CRONOS does not let the user module influence the determination of the CFL-value as this is computed via the CFL-criterion. The choice of a adequate CFL-threshold is important to ensure numerical stability when dealing with additional source terms, but could also waste unnecessary CPUtime, when choosing it too low. As the next timestep dt depends on the actual field values of the grid, the option to let the user module influence the calculation of the next timestep dt could increase the performance: unnecessary timesteps caused by a too low CFL-threshold could be avoided. This could be an improvement to CRONOS in the next versions, that is currently in discussion. The implementation of the photon momentum transfer influences the velocity field, and in the later phases also the thermal energy. Based on the current model consideration of PNe (see chapter 1), the CSPN is a very hot star at the end of it’s stellar lifecycle. Such hot stars have a very high output of UV-photons. These photons are absorbed by dust and gas in the inner regions of the PNe and re-radiated as thermal infra-red photons or as the famous forbidden lines, that can escape from the nebula because practically no further interactions occur. As the thermal radiation is distributed over the whole spherical angle we do not expect any net momentum by the thermal emission. But the UV-photons come exclusively from the central star region, so they carry a net momentum pointing radial away from the star. This behaviour is illustrated in figure 5.1. For details about this topic see Lamers and Cassinelli [1999, Chapter 8 - Line driven winds]. Figure 5.1: Photon momentum transfer. The infalling UV-photons carry a net momentum as they all come from the central start. The re-radiated infrared-photons from thermal emission do not carry a net momentum, as they are equally distributed among the whole spherical angle. This process can occur on dust particles as well as in the gas component. The absorbed photon therefore influences the momentum of a single dust particle (or the gas) and it’s temperature. In our hydrodynamics environment we deal with a ensemble, containing a huge amount of gas and dust particles, therefore we can apply a net momentum transfer and heat source mechanism for each grid cell. The field interfaces between the hydrodynamics and the photon momentum transfer mechanism is the velocity field and the thermal energy for the absorption of the photons, and the density to determine how much photons will propagate through the medium: 50 The radiation comes from the central star with a given intensity I. The amount of intensity absorbed in each grid cell is determined by the basic equation of radiative transfer dIν = −αν Iν + S (5.1) dt where αν is the extinction coefficient for the frequency ν and S a possible source of radiation. In the first steps we do not consider any further sources for UV photons, therefore S = 0 and equation 5.1 becomes dIν = −αν Iν dt αν depends on the cross section for the dust particles and the amount of dust particles in a single grid cell. The interface between the hydrodynamics environment and the radiative transfer equation is therefore the density field ρ. ρ determines the amount of dust particles and therefore the amount of radiation absorbed in the each individual grid cell. It further determines the remaining radiation intensity after each grid cell so that αν is a function of the density ρ: αν (ρ). 5.2.2 Radiative heating and cooling using CLOUDY PNe show typically an emission spectrum including forbidden lines. The spectrum is mainly formed by thermal emission, recombination processes and forbidden quantum transitions. Because of these processes, the spectra are far away from a typical black-body spectrum. Recombination of the ionised plasma and the forbidden transitions from together efficient heating and cooling mechanisms for the plasma. Apart from these, also other processes like photoionisation, collisions and several scattering and collision mechanisms participate in the complicated thermodynamics. A analytical expression of the complex processes is not always possible or feasible in reasonable computational time, even if treated isolated from each other. The targeted approach for this setup is to use CLOUDY [Ferland et al., 2013] to calculate the parameters for an effective radiative transfer process. The use of CLOUDY displays a very sophisticated, state-of-the-art approach to calculate realistic cooling- and heating processes for the underlying hydrodynamics simulations. Such an approach is not yet be done as this setup is very expensive in terms of CPU time. A CLOUDY run can be very intensive and this is only a intermediate step between each Riemann solver integration step, that itself consumes an immense amount of CPU time! A effective caching algorithm has to be found to reduce the number of CLOUDY runs to a supportable minimum without loosing too much precision. This step is essential for the simulation of a PNe. The idea is to use the underlying hydrodynamics environment fields to calculate the needed parameters for radiative transfer mechanisms using CLOUDY. As CLOUDY calculations are very expansive, the previous results are stored and a new CLOUDY-run is invoked, only when the hydrodynamics parameters deviate relevant compared to the conditions of the previous CLOUDY run. With this approach we hope to reduce the number of CLOUDY runs to a tolerable number, so that the estimated cost in CPU-time does not explode. This approach is still of theoretical nature, the concrete implementation is part of a future work. A illustration of the expected CRONOS-CLOUDY pipeline is shown in figure 2.5. 5.2.3 Evolution of a planetary nebula The latest step is to merge all previous milestones and implement a single simulation module including all relevant aspects. As all previous milestones implement the isolated processes detached from each other, the forging process has to be a additional milestone. The expected result is a CRONOS module implementing the physics for the formation of a PN. The parameters of the simulation should be configurable in the CAT-file for the module. In this step we intent to implement the model described in chapter 1 and 2. The stellar evolution tracks of Blöcker discussed in section 1.1.2 define the stellar parameters in time, the different wind phases are considered to be used from Okorokov et al. [1985a] (see figure 2.2 in section 2.2). Since this are very early model considerations for future works, they may be altered. 51 The expected result is a post-AGB star that evolves according to the stellar evolution based on the tracks of Bloecker [1995]. The double- wind model of Kwok [2000] is implemented using the old-wind, superwind and fast-wind model of Okorokov et al. [1985a]. With this model considerations we intent to establish a physical model and simulation environment for the evolution of planetary nebulae. Because the design of the simulation environment is based on the 3D hydrodynamics framework CRONOS, studies on asymmetric evolutions is possible. Most catalogued PNe have observed asymmetries as can be seen in figures 5.2 and 5.3. This could lead to a topic for future research projects. In the latest steps of this MSc thesis we were already able to produce a asymmetric density nebulae, using a fast stellar wind and a density disk surrounding the central star, as found in some AGB stars before they enter the PN stages. The evolution of such an asymmetric nebula with a dissolved surrounding disk is shown as collage in figure 4.10 and was already presented at the “Asymmetrical Planetary Nebulae VI” conference [Niederwanger et al., 2014]. Figure 5.2: Hubble picture of NGC-6302. The gaseous nebula looks like a butterfly. It’s expansion speed is about 950000 km/h. The planetary nebula lives in the milky-way, about 3.800 ly away from the constellation Scorpio. Credit: NASA, ESA, and the Hubble SM4 ERO Team. A full 3D radiative-hydrodynamics threatment for the formation of a planetary nebulae is a new approach. Comparative previous works from Schönberner (Perinotto et al. [2004]) and Okorokotv (Okorokov et al. [1985a]) did similar simulation efforts but assumed spherical symmetry and did not a full 3D treatment. This limits their studies on symmetrical PNe only. A full 3D simulation approach could give new inputs in the formation of asymmetric structures of PNe. 52 Figure 5.3: Hubble picture of NGC-6543, the cat-eye nebula. Credit: NASA, ESA, HEIC, and The Hubble Heritage Team (STScI/AURA). 5.3 Additional improvements Within this thesis the first steps towards a full 3D radiative-hydrodynamics simulation for the evolution of a planetary nebula are described. The model discussed in chapter 2 is a result of comparisons with previous works, mostly based on Okorokov et al. [1985a] and Perinotto et al. [2004]. A future work is the full implementation of the last milestones as described in section 4.1 based on the numerical model presented in this work. The numerical model is an approximation and further improvements could possibly become necessary. A major concern could be the dust. As discussed in section 5.2 for the photon momentum transfer, dust plays an important role for the transformation of UV photons to infra-red thermal emission and the absorption of momentum from the radiation of the CSPN. In our model we neglect the isolated treatment of dust, assuming the composition of dust to be isotropic in the whole region. Okorokov et al. [1985a] treated the dust as separated component in his simulations, while also Perinotto et al. [2004] neglected this two-component hydrodynamic treatment. Since the main ingredient of dust is carbon coming in the late PN stages from the star, the dustyness may not be isotropic at all, leading to inhomogeneous acceleration mechanisms from the photon momentum transfer and possibly issues in the absorption of the UV photons. 53 Appendix A Normalisation The Euler equation 3.3 is given by ρ · [δt v + v · ∇v] = −∇p + f (3.3) δ where δt is the partial derivative δt . The normalised Euler equation looks the same but uses the later shown substitution rules (see frame below). Applying them yields ρ̃ [δt ṽ + ṽ · ∇ṽ] = −∇p̃ + f̃ (3.13) The normalisation of this equation if fully determined by the choice of r0 , T0 , ρ0 and γ. All other normalisation constants can be derived from them. The replacement provisions are given in the following. The variables with a tilde on top (e.g. ã) are the normalised equivalent of their original a. r ro v ṽ = cs t · cs t t̃ = = τ L ρ̃ = r̃ = ẽ = ρ ρ0 e ρ0 c2s T T0 p p̃ = ρ0 c2s f f˜ = ρo c2s T̃ = (A.1) with the speed of sound r cs = γ kB T0 mH (A.2) Useful is also the pressure-energy-temperature relation p̃ = (γ − 1)ẽ = ρ̃ · T̃ Furthermore for an ideal gas the following relations hold p ∝ ργ T ∝ ργ−1 When adding source terms using the method src User keep in mind, to add the corresponding energy difference according to ρL ∆Eges = ~v · f~ · (3.14) cs The CRONOS-C++ snippet to do so is the following 54 Listing A.1: Handling the internal energy when adding source terms REAL force [3]; for ( int i_z = 0; i_z <= gdata . mx [2]; ++ i_z ) { REAL z = gdata . getCen_z ( i_z ) ; for ( int i_y = 0; i_y <= gdata . mx [1]; ++ i_y ) { REAL y = gdata . getCen_y ( i_y ) ; for ( int i_x = 0; i_x <= gdata . mx [0]; ++ i_x ) { REAL x = gdata . getCen_x ( i_x ) ; force [0] = 0.0; force [1] = 0.0; force [2] = 0.0; /* ==== APPLY FORCES ( USER SECTION ) ==== */ // Here the // e . g . /* REAL radius if ( radius > F_g user can modify the force - field force [ i ] = sqrt ( x * x + y * y + z * z ) ; 0.0) { = G_Grav * this - > m_sun / sqr ( radius * norm_length ); force [0] += ( x / radius ) * F_g ; force [1] += ( y / radius ) * F_g ; force [2] += ( z / radius ) * F_g ; } */ /* ==== END OF USER SECTION ==== */ /* ==== APPLY FORCES TO GRID ==== */ REAL rho = gdata . om [ q_rho ]( i_x , i_y , i_z ) ; // Apply n o r m a l i s a t i o n rules nom [ q_sx ]( i_x , i_y , i_z ) += force [0]* rho / sqr ( c_sound ) ; nom [ q_sy ]( i_x , i_y , i_z ) += force [1]* rho / sqr ( c_sound ) ; nom [ q_sz ]( i_x , i_y , i_z ) += force [2]* rho / sqr ( c_sound ) ; # if ENERGETICS == FULL REAL Eges = ( gdata . om [ q_sx ]( i_x , i_y , i_z ) * force [0] + gdata . om [ q_sy ]( i_x , i_y , i_z ) * force [1] + gdata . om [ q_sz ]( i_x , i_y , i_z ) * force [2]) * rho / sqr ( c_sound ) ; nom [ q_Eges ]( i_x , i_y , i_z ) += Eges ; # endif } } } 55 Appendix B Visualisation This appendix includes some additional visualisation material that is not printed in the main document. Figure B.1: Density profile at a central slide of the blanked out region 56 Figure B.2: Visualisation of the initial density distribution. 57 Figure B.3: Density-plot of the same simulation using five different resolutions. From the right to the left: 163 , 323 , 643 , 1283 , 2563 grid cells. 58 Appendix C CRONOS-Objects CRONOS objects are an extension to the current version of CRONOS, that should simplify the implementation of simple geometric objects. A objects is composed by two components: • Object • Field (Geometric) objects determine the location WHERE a field is set, field define WHAT to set. For instance, object can be a disk, a sphere or a cube, while a field can be a density, energy or gravity field. The combination of a object and a field generates the output on the numerical grid. As an example: A density crumb as implemented in milestone 3 (see section 4.1.1) is a sphere object in combination with a density field. The sphere object defines where the density crumb is located, the density field sets the density of the crumb object. The hierarchy of the objects is shown in figure C.1, the hierarchy of the fields is shown in figure C.2. Figure C.1: UML diagram of the CRONOS objects. Figure C.2: UML diagram of the CRONOS fields. Each geometric object has a origin x0 and the angles φ and θ. They define the angle, how the object is rotated in respect to the x- or respectively the y-axis. As the origin an the angles are implemented in GeomObject and therefore inherited by each individual geometric object, they are available in all subclasses. At the current stage, the following geometric objects are available 59 Object Description Parameters Disk A (rotatable and translatable) disk ri , ro , h Sphere A sphere with a defined radius r Cuboid A cuboid with custom lengths a, b, c Universe The universe is a field that is everywhere Listing C.1 shows how to create some geometric objects and use the translation and rotation methods. Listing C.1: Example how to create geometric objects void G e o m O b j e c t E x a m p l e :: init_fields ( Data & gdata , int ibeg [3] , int iend [3]) { /* First we define a disk */ REAL r_0 = 1.0; // Inner disk radius REAL r_1 = 5.0; // Outer disk radius REAL h = 0.5 // Disk height REAL theta = M_PI / 2.0; // D e c l i n a t i o n REAL rho = 10.0 // Density to apply Disk * disk = new Disk ( r_0 , r_1 , h ) ; disk - > setTheta ( theta ) ; disk - > setPhi (0.0) ; // I n h e r i t e d from GeomObject , but useless for the disk /* Create a cuboid with a = 1 , b = 2 , c = 3. T r a n s l a t e it */ Cuboid * cuboid = new Cuboid (1.0 ,2.0 ,3.0) ; cuboid - > setOrigin (0.0 , 5.0 , -2.0) ; /* Create a sphere with radius 2.5 */ Sphere * sphere = new Sphere (2.5) ; // Here we need to apply the objects // [...] // See the next listing /* Cleanup */ delete sphere ; delete cuboid ; delete disk ; } Listing C.1 does only create the geometric objects. Without a field (think as a operation) the object doesn’t do anything. Listing C.2 shows hot to apply a certain density and energy on the cuboid, and sets the sphere’s velocity Listing C.2: Example how to create geometric objects // E x t e n s i o n to the listing above . Apply some fields (" O p e r a t i o n s ") on the defined // g e o m e t r i c objects const double rho = 10.0; const double Etherm = 100.0; DensityField * diskDensity = new DensityField ( disk , rho ) ; EnergyField * diskEnergy = new EnergyField ( disk , Etherm ) ; // Note : apply is o v e r l o a d e d . diskDensity - > apply ( gdata , ibeg , iend ) ; diskEnergy - > apply ( gdata , ibeg , iend ) ; delete diskDensity ; delete diskEnergy ; // Speed set to 10.0 in x d i r e c t i o n . y and z are 0.0 VelocityField * sphe reVeloci ty = new VelocityField ( sphere , 10.0 , 0.0 , 0.0) ; sphereVelocity - > apply ( gdata , ibeg , iend ) ; delete spher eVeloci ty ; The method apply is overloaded. There are two methods available, depending if you want to use the parallel version of apply, or the non-parallel version as needed for instance for src User. 60 Listing C.3: The method apply is overloaded and ships with a parallel and non-parallel version void W indDisk Module :: init_fields ( Data & gdata , int ibeg [3] , int iend [3]) { // If in init_fields , use the p a r a l l e l version diskDensity - > apply ( gdata , ibeg , iend ) ; } void DemoModule :: src_User ( Data & gdata , NumMatrix < REAL ,3 > nom [ N_OMINT ] , NumMatrix < REAL ,3 > nom_user [ N_OMINT_USER ]) { // In src_User , use the non - p a r a l l e l version diskDensity - > apply ( gdata ) ; } 61 Bibliography B. Baschek, W. Kegel, and G. Traving. Problems in Stellar Atmospheres and Envelopes. Springer, 2012. ISBN 3642809219. URL http://www.amazon.com/ Problems-Stellar-Atmospheres-Envelopes-Baschek/dp/3642809219%3FSubscriptionId% 3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative% 3D165953%26creativeASIN%3D3642809219. L. Biermann. Kometenschweife und solare Korpuskularstrahlung. Zeitschrift für Astrophysik, 29:274, 1951. T. Bloecker. Stellar evolution of low- and intermediate-mass stars. II. Post-AGB evolution. Astronomy and Astrophysics, 299:755, July 1995. G. J. Ferland, R. L. Porter, P. A. M. van Hoof, R. J. R. Williams, N. P. Abel, M. L. Lykins, G. Shaw, W. J. Henney, and P. C. Stancil. The 2013 Release of Cloudy. Revista Mexicana de Astronomia y Astrofisica, 49:1–27, 2013. I. Iben and A. Renzini. Book-Review - Physical Processes in Red Giants. Journal of the British Astronomical Association, 92:50, Dec. 1981. H. Karttunen, P. Kröger, and H. Oja. Fundamental astronomy. Springer, 2007. URL http://books.google.at/books?hl=en&lr=&id=RacoITLoz_oC&oi=fnd&pg=PA3&dq=Fundamental+ Astronomy+Karttunen&ots=Q5cOR2rhKX&sig=DXz8rJlLw8b94yzlDb3Z3TuV3Eg. K. Kifonidis. Gasdynamische Modelle für planetarische Nebel mit sich schnell entwickelnden Zentralsternen, 1996. R. Kissmann. Numerical Investigation of the Turbulent ISM, 2006. J. Kleimann. CRONOS Manual. Technical report, 10 2012. S. Kwok. Proto-planetary nebulae. 31:63–92, 1993. doi: 10.1146/annurev.aa.31.090193.000431. S. Kwok. The Origin and Evolution of Planetary Nebulae - . Cambridge University Press, Cambridge, 2000. ISBN 978-0-521-62313-1. S. Kwok. The Origin and Evolution of Planetary Nebulae. Cambridge Astrophysics. Cambridge University Press, 2007. ISBN 9780521039079. URL http://books.google.at/books?id=a_BO6p9LVdcC. S. Kwok, C. Purton, and P. Fitzgerald. On the origin of planetary nebulae. The Astrophysical Journal, 219:L125–L127, 1978. URL http://adsabs.harvard.edu/full/1978ApJ...219L.125K. H. J. G. L. M. Lamers and J. P. Cassinelli. Introduction to stellar winds. Cambridge University Press, Cambridge, 1999. ISBN 978-0-521-59565-0. F. Niederwanger, S. Öttl, S. Kimeswenger, R. Kissmann, and K. Reitberger. 3D Radiative Transfer models of Planetary Nebulae with CRONOS and CLOUDY. In Asymmetrical Planetary Nebulae VI conference, Proceedings of the conference held 4-8 November, 2013. Edited by C. Morisset, G. Delgado-Inglada and S. Torres-Peimbert., Apr. 2014. URL http://www.astroscu.unam.mx/apn6/PROCEEDINGS/. V. Okorokov, B. Shustov, A. Tutukov, and H. Yorke. Numerical models of planetary nebulae evolution. Astronomy and Astrophysics, 142:441–450, 1985a. URL http://adsabs.harvard.edu/full/1985A% 26A...142..441O. V. A. Okorokov, B. M. Shustov, A. V. Tutukov, and H. W. Yorke. Numerical models of planetary nebulae evolution. Astronomy and Astrophysics, 1:441–450, 1985b. 62 B. Paczynski. Evolution of Single Stars. I. Stellar Evolution from Main Sequence to White Dwarf or Carbon Ignition. Acta Astronomica, 20:47, 1970. URL http://adsabs.harvard.edu/full/1970AcA. ...20...47P. M. Perinotto, D. Schönberner, M. Steffen, and C. Calonaci. The evolution of planetary nebulae. Astronomy and Astrophysics, 414(3):993–1015, 2004. doi: 10.1051/0004-6361:20031653. URL http: //dx.doi.org/10.1051/0004-6361:20031653. G. Prölss. Physik des erdnahen Weltraums: Eine Einführung (German Edition). Zweite Auflage. Springer, 2003. ISBN 3-540-40088-5. S. Schmeja and S. Kimeswenger. Planetary nebula or symbiotic Mira? Near infrared colours mark the difference. page Astron.Astrophys., Aug. 2001. doi: 10.1051/0004-6361:20011161. URL http: //arxiv.org/abs/astro-ph/0108331v1;http://arxiv.org/pdf/astro-ph/0108331v1. E. F. Toro. Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction. Springer, 2009. ISBN 3540252029. URL http://www.amazon. com/Riemann-Solvers-Numerical-Methods-Dynamics/dp/3540252029%3FSubscriptionId% 3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative% 3D165953%26creativeASIN%3D3540252029. VoigtHans-Heinrich and H.-J. Röser. Abriss Der Astronomie. Wiley-VCH Verlag GmbH, 2012. ISBN 3527407367. URL http://www.amazon.com/ Abriss-Astronomie-Hans-Heinrich-Voigt-Hermann-Josef/dp/3527407367%3FSubscriptionId% 3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative% 3D165953%26creativeASIN%3D3527407367. S. Öttl, S. Kimeswenger, and A. A. Zijlstra. Ionization structure of multiple-shell planetary nebulae. I. NGC 2438. Astronomy and Astrophysics, 565:A87, May 2014. doi: 10.1051/0004-6361/201323205. 63