Download Master thesis

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