Microphysics - bender.astro.sunysb.edu

Microphysics

A collection of astrophysical microphysics routines

User’s Guide

March 30, 2018

Chapter Listing

preface ix

1 The Basics 1

2 Data Structures 3

3 Runtime Parameters 7

4 Equations of State 19

5 Nuclear Reaction Networks 25

6 Transport Coefficients 41

7 OpenACC 43

8 Unit Tests 45

9 SDC 51

References 55

iii

Contents

preface ix

1 The Basics 1

1.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Design Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Data Structures 3

2.1 EOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 burn t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 rate t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 burn type module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Integrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Converting Between Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Initial Values and Threadsafety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Runtime Parameters 7

4 Equations of State 19

4.1 Available Equations of State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.1 gamma law general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 polytrope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.3 ztwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.4 multigamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.5 helmholtz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.6 stellarcollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Interface and Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Initialization and Cutoff Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4 Input Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

v

vi CONTENTS

4.5 EOS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Nuclear Reaction Networks 25

5.1 Network Requirements and Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Available Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 aprox13, aprox19, and aprox21 . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.2 breakout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.3 CONe2NSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.4 general null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.5 ignition chamulak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.6 ignition reaclib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.7 ignition simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.8 iso7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.9 kpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.10 powerlaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.11 rprox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.12 triple alpha plus cago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.13 xrb simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Reaction ODE System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3.1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3.2 Thermodynamics and T Evolution . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.3 nspec evolve Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.4 Evolving Mass Fractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.5 Renormalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Stiff ODE Solvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4.1 actual integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4.2 Righthand side wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4.3 BS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4.4 VODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.5 VBDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.6 Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.5 Overriding Parameter Defaults on a Network-by-Network Basis . . . . . . . . . . . . 39

6 Transport Coefficients 41

6.1 Thermal Conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 OpenACC 43

7.1 General Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2 Common Compiler Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2.1 PGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.3 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.3.1 cuda-gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8 Unit Tests 45

8.1 Comprehensive Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.1.1 EOS test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.1.2 Network test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2 Individual Network Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CONTENTS vii

8.3 burn cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.3.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.3.2 Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.3.3 Running the Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.3.4 Graphs Output by burn cell.py . . . . . . . . . . . . . . . . . . . . . . . . . . 48

9 SDC 51

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9.2 Interface and Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.2.1 sdc t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9.3 ODE system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529.4.1 actual integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529.4.2 Righthand side wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

References 55

Preface

Welcome to the Microphysics User’s Guide!

In this User’s Guide we describe the microphysics modules designed to enable simulations of stellarexplosions.

The original design was to support the AMReX codes CASTRO and MAESTRO. These all havea consistent interface and are designed to provide the users of those codes an easy experience inmoving from the barebones microphysics modules provided in those codes. For the purposes of thisuser’s guide, the microphysical components we currently deal with are the equation of state (EOS)and the nuclear burning network.

Microphysics is not a stand-alone code. It is intended to be used in conjuction with a simulationcode. At the moment, the interfaces and build stubs are compatible with the AMReX codes. Inmany cases we will provide test modules that demonstrate a minimal working example for howto run the modules (leveraging the AMReX build system). The goal is to make the support moregeneral, and extend to other codes in the future.

A number of the routines contained here we authored by other people. We bundle them here withpermission, usually changing the interfaces to be compatible with our standardized interface. We inparticular thank Frank Timmes for numerous reaction networks and his equation of state routines.

ix

CHAPTER 1

The Basics

1.1 Getting Started

Getting started with Microphysics using either CASTRO or MAESTRO is straightforward. Becausethe modules here are already in a format that the AMReX codes understand, you only need toprovide to the code calling these routines their location on your system. The code will do the rest.To do so, define the MICROPHYSICS HOME environment variable, either at a command line or (if youuse the bash shell) through your ∼/.bashrc profile, e.g.:

export MICROPHYSICS HOME=/path/to/Microphysics

For CASTRO the name of the EOS and network are set via the make variables EOS dir andNetwork dir. The macros in CASTRO’s Make.Castro will know to look in Microphysics using theMICROPHYSICS HOME variable to find the codes.

For MAESTRO, the name of the EOS and network are set via the make variables EOS DIR andNETWORK DIR, and the macros in MAESTRO’s GMaestro.mak file will find the code, again using theMICROPHYSICS HOME variable.

For other codes, one can use the interfaces in Microphysics/interfaces/ and sample routines inMicrophysics/unit test/ to incorporate these modules into your code. Note that there are a fewAMReX files required at the moment (mainly error handling and constants).

1.2 Structure

The high-level directory structure delineates the types of microphysics and the generic solvers:

• Docs/: this User’s Guide

1

2 Chapter 1. The Basics

• EOS/: the various equations of state

• integration/: the ODE integration routines used for the reaction networks

• interfaces/: copies of the main derived types that are used to interface with the EOS andreaction networks. Note that most application codes will have their own local copies. Theseare provided for unit testing in Microphysics.

• networks/: the nuclear reaction networks. This is mostly just the righthand side of thenetwork, as the actual integrators are decoupled from the network.

• neutrinos/: neutino loss source terms for the network energy equation.

• NSE/: routines for approximating nuclear statistical equilibrium.

• rates/: common nuclear reaction rate modules used by some of the networks.

• screening/: common electron screening factors used by some of the reaction networks.

• unit test/: self-contained unit tests for Microphysics. These don’t need any application codeto build, but will require AMReX.

• util/: linear algebra solvers and other routines.

1.3 Design Philosophy

Any application that uses Microphysics will at minimum need to choose an EOS and a network.These two components work together. The design philosophy is that the EOS depends on thenetwork, but not the other way around. The decision was made for the network to act as the coremodule, and lots of code depends on it. This avoids circular dependencies by having the eos t andburn t be built on top of the network.

The network is meant to store the properties of the species (typically nuclear isotopes) includingtheir atomic weights and numbers, and also describes any links between the species when burning.

The equation of state relates the thermodynamic properties of the material. It depends on thecomposition of the material, typically specified via mass fractions of the species, and uses theproperties of the species defined by the network to interpret the state.

We try to maximize code reuse in the Microphysics source, so the solvers (ODE integration for thenetwork and Newton-Raphson root finding for the EOS) is separated from the specific implmenta-tions of the microphysics.

All quantities are assumed to be in CGS units, unless otherwise specified.

CHAPTER 2

Data Structures

All of the routines in this software package are standardized so that you interact with them usingthe same type of data structure, a Fortran derived type (which, for our purposes, is analogous toa C++ struct).

2.1 EOS

The main data structure for interacting with the EOS is eos t. This is a collection of data specifyingthe microphysical state of the fluid that we are evaluating. This derived type has many components,and in the Fortran syntax we access them with the % operator. For a particular instantiation namedeos state, the most important data is the following:

• eos state % rho: density [g cm−3]

• eos state % T: temperature [K]

• eos state % p: pressure [erg cm−3]

• eos state % e: specific internal energy [erg g−1]

• eos state % h: specific enthalpy [erg g−1]

• eos state % s: specific entropy [erg g−1 K−1]

• eos state % xn(:): mass fractions of species (this is an array, dimensioned to be the numberof species, nspec)

• eos state % aux(:): any auxiliary variables carried with the fluid (this is an array, dimen-sioned to be the number of auxiliary quantities, naux)

3

4 Chapter 2. Data Structures

Note that both nspec and naux are meant to be properties of the network, and they will come inthrough the network module.

There is a lot more information that can be saved here, such as the partial derivatives of thethermodynamic state variables with respect to each other. To see a complete list, examine theeos type.f90 file inside the code calling Microphysics (e.g. Castro/EOS/eos type.f90).

2.2 Networks

2.2.1 burn t

The main data structure for interacting with the reaction networks is burn t. This holds thecomposition (mass fractions), thermodynamic state, and a lot of internal information used by thereaction network (e.g. the righthand side of the ODEs, the Jacobian, etc.). Typically the user willonly need to fill/use the following information:

• burn state % rho: density [g cm−3]

• burn state % T: temperature [K]

• burn state % e: the specific internal energy [erg g−1]

Note: this has two different contexts, depending on when it is accessed.

When you call the integrator and are in the process of integrating the reaction system, e willbe an integration variable and will account for the nuclear energy release. Due to the natureof our ODE system, this will not be thermodynamically consistent with ρ, T

Upon exit of the integration, the initial internal energy (offset) is subtracted off, and e nowrepresents the specifc nuclear energy release from the reactions.

• burn state % xn(:): the mass fractions

• burn state % aux(:): any auxiliary quantities (like Ye)

• burn state % i, % j, % k: hydrodynamic zone i, j, k for bug reporting, diagnostics

• burn state % time: the time since the start of the integration [s]

Note this is not the same as the simulation time. Each integrator will also store the simulationtime at the start of integration in their local storage—this can be used as an offset to convertbetween integration and simulation time.

• burn state % shock: are we inside of a hydrodynamic shock (the burner may wish to takeaction in this case)

2.2.2 rate t

The rate t structure is used internally in a network to pass the raw reaction rate information(usually just the temperature-dependent terms) between various subroutines. It does not come outof the network-specific righthand side or Jacobian routines.

2.3—Integrators 5

This main component of this is simply an array of dimension rates(num rate groups, nrates)—both of the parameters used in dimensioning this are network-dependent.

2.2.3 burn type module

In addition to defining the burn t type, the burn type module also defines integer indices into thesolution vector that can be used to access the different components of the state:

• neqs : the total number of variables we are integrating. It is assumed that the firstnspec evolve are the species.

• net itemp : the index of the temperature in the solution vector

• net ienuc : the index of the specifc internal energy in the solution vector

2.3 Integrators

Each integrator also has their own internal data structure that holds the information needed forthe integration. Meta-data that is not part of the integration vector of ODEs, but is attached to aparticular state (Yk, T , e), is stored in an array that can be passed into the righthand side routine.The different fields are accessed through the integer indices in the rpar indices Fortran module.The details of this storage is given for each integrator below.

2.4 Converting Between Types

There is significant overlap between eos t and burn t. The burn type module provides two rou-tines, burn to eos and eos to burn that convert a burn t state to an eos t state, and back. Onlythe thermodynamic variables that are common in the two types are copied. This is useful, forexample, if you have a burn t state and what to get thermodynamic information by calling theEOS.

2.5 Initial Values and Threadsafety

CHAPTER 3

Runtime Parameters

The behavior of the network and EOS are controlled by many runtime parameters. These param-eters are defined in plain-text files parameters located in the different directories that hold themicrophysics code. At compile time, a script in the AMReX bulid system, findparams.py, locatesall of the parameters files that are needed for the given choice of network, integrator, and EOS,and assembles all of the runtime parameters into a module named extern probin module (usingthe write probin.py script).

Note: depending on the application code, the filename of the source file that contains theextern probin module may differ (in CASTRO it is extern.f90, and uses the &extern namelist; inMAESTRO it is in the main probin.f90 and uses the same namelist as general MAESTRO runtimeparameters).

Parameter definitions take the form of:

# comment describing the parameter

name data-type default-value priority

Here, the priority is simply an integer. When two directories define the same parameter, but withdifferent defaults, the version of the parameter with the highest priority takes precedence. Thisallows specific implementations to override the general parameter defaults.

The documentation below is automatically generated, using the comments in the parameters files.

7

8C

hap

ter3.

Ru

ntim

eP

arameters

Table 3.1: BS parameters.

parameter description default value

ode_max_steps Maximum number of steps to use in the ODE integration 10000

ode_method use an implementation of the Bulirsch-Stoer semi-implicit extrapolation method (1) ora Rosenbrock method (2)

1

ode_scale_floor Floor to use for the ODE scaling vector 1.d-6

safety_factor when constructing the intermediate steps in the stiff ODE integration by how muchdo we allow the state variables to change over a dt before giving up on the step andretrying with a smaller step?

1.d9

scaling_method Which choice to use for the ODE scaling 1: |y| + |dy/dt|; 2: max(|y|,K) with K =constant

2

use_timestep_estimator use the VODE algorithm’s initial timestep estimator? .false.

Table 3.2: VBDF parameters.


dt_min minimum allowable timestep 1.d-24

jac_age number of times we can use the Jacobian before rebuilding 50

p_age number of times we use the same Newton iteration matrix before rebuilding 20

reuse_jac reuse the Jacobian? .false.

9

Table 3.3: breakout parameters.


eos_gamma 0.d0

Table 3.4: burn cell parameters.


run_prefix ””

small_dens 1.e5

small_temp 1.e5

Table 3.5: gamma law general parameters.


eos_assume_neutral .true.

eos_gamma 5.d0/3.d0

Table 3.6: helmholtz parameters.


eos_input_is_constant Force the EOS output quantities to match input .false.

use_eos_coulomb use the Coulomb corrections .true.

10C

hap

ter3.

Ru

ntim

eP

arameters

Table 3.7: integration parameters.


MAX_TEMP The maximum temperature for reactions in the integration. 1.0d11

SMALL_X_SAFE The absolute cutoff for species – note that this might be larger than small x, but theissue is that we need to prevent underflow issues and keep mass fractions positive in theintegrator. You may have to increase the floor to, e.g. 1.d-20 if your rates are large.

1.0d-30

atol_enuc 1.d-6

atol_spec 1.d-12

atol_temp 1.d-6

burner_verbose Should we print out diagnostic output after the solve? .false.

burning_mode Integration mode: if 0, a hydrostatic burn (temperature and density remain constant),and if 1, a self-heating burn (temperature/energy evolve with the burning). If 2, ahybrid approach presented by Raskin et al. (2010): do hydrostatic everywhere, but ifthe hydrostatic burn gives us a negative energy change, redo the burn in self-heatingmode. If 3, do normal self-heating, but limit all values of the RHS by the same factor Lsuch that e = fse/ts, where e is the energy injection rate, e is the internal energy of thezone, ts is the sound crossing time, and fs is a safety factor. L is computed as min(1,fs(e/e)/ts).

1

burning_mode_factor If we’re using burning mode == 3, this is the safety factor fs to use. 1.d-1

call_eos_in_rhs Do we call the EOS each time we enter the EOS? This is expensive, but more accu-rate. Otherwise, we instead call the EOS at the start of the integration and freeze thethermodynamics throughout the RHS evalulation. This only affects the temperatureintegration (which is the input to the rate evaluation). In particular, since we calcu-late the composition factors either way, this determines whether we’re updating thethermodynamic derivatives and other quantities (cp and cv) as we go.

.false.

centered_diff_jac one-sided numerical jacobian (.False.) or centered-difference Jacobian (.true.). Note:the centered-difference requires twice as many RHS calls

.false.

continued on next page

11

Table 3.7—continued


dT_crit If we want to call the EOS in general, but don’t want to overdo it, we can set a fractiondT crit such that we only do the EOS call if the temperature has changed by a relativefraction > dT crit. If we use this option, we will do a linear fit to c v and c p in betweenEOS calls. This will work regardless of call eos in rhs.

1.0d20

do_constant_volume_burn When evolving the temperature, should we assume a constant pressure (default) or aconstant volume (do constant volume burn = T)?

.false.

integrate_energy Allow the energy integration to be disabled by setting the RHS to zero. .true.

integrate_temperature Allow the temperature integration to be disabled by setting the RHS to zero. .true.

jacobian Whether to use an analytical or numerical Jacobian. 1 == Analytical 2 == Numerical 1

react_boost boost the reaction rates by a factor ¿ 1 -1.d0

renormalize_abundances Whether to renormalize the mass fractions at each step in the evolution so that theysum to unity.

.false.

retry_burn If we fail to find a solution consistent with the tolerances, do we want to try again witha looser tolerance?

.false.

retry_burn_factor If we do retry a burn, by what factor should we loosen the tolerance? 1.25d0

retry_burn_max_change What is the maximum factor we can increase the original tolerances by? 1.0d2

rtol_enuc 1.d-6

rtol_spec Tolerances for the solver (relative and absolute), for the species, temperature, and energyequations.

1.d-12

rtol_temp 1.d-6

Table 3.8: kpp parameters.


A_burn 10.d0

12C

hap

ter3.

Ru

ntim

eP

arameters

Table 3.9: multigamma parameters.


eos_gamma_default 1.4

species_a_gamma 1.4

species_a_name ””

species_b_gamma 1.4

species_b_name ””

species_c_gamma 1.4

species_c_name ””

Table 3.10: networks parameters.


small_x cutoff for species mass fractions 1.d-30

use_tables Should we use rate tables if they are present in the network? .false.

Table 3.11: polytrope parameters.


polytrope_K 0.0d0

polytrope_gamma 0.0d0


13



polytrope_mu_e 2.0d0

polytrope_type 0

Table 3.12: powerlaw parameters.


T_burn_ref reaction thresholds (for the power law) 1.0d0

burning_mode override the default burning mode with a higher priority 0

f_act 1.0d0

jacobian override the default Jacobian mode with a higher priority 2

nu exponent for the temperature 4.d0

rho_burn_ref 1.0d0

rtilde the coefficient for the reaction rate 1.d0

specific_q_burn reaction specific q-value (in erg/g) 10.d0

Table 3.13: rprox parameters.


atol_enuc 1.0e-8

atol_spec override the default tolerances for backwards compatibility 1.0e-11

atol_temp 1.0e-8


14C

hap

ter3.

Ru

ntim

eP

arameters




do_constant_volume_burn we typically run this network for constant-pressure burns .false.

jacobian override so that the default is an analytical Jacobian 1

rtol_enuc 1.0e-8

rtol_spec 1.0e-12

rtol_temp 1.0e-8

Table 3.14: stellarcollapse parameters.


eos_file name of the HDF5 file containing tabulated data ””

use_energy_shift .false.

Table 3.15: test eos parameters.


dens_max 1.d9

dens_min 1.d6

metalicity_max 0.1d0

small_dens 1.e-4

small_temp 1.e4


15



temp_max 1.d12

temp_min 1.d6

test_set ”gr0 3d”

xin_file ”uniform”

Table 3.16: test react parameters.


dens_max 1.d9

dens_min 1.d6

do_acc 1

run_prefix ””

small_dens 1.e5

small_temp 1.e5

temp_max 1.d15

temp_min 1.d6


tmax 0.1d0


16C

hap

ter3.

Ru

ntim

eP

arameters

Table 3.17: test sdc parameters.


dens_max 1.d9

dens_min 1.d6

do_acc 1

run_prefix ””

small_dens 1.e5

small_temp 1.e5

temp_max 1.d15

temp_min 1.d6


tmax 0.1d0


Table 3.18: triple alpha plus cago parameters.


atol_enuc 1.0e-8


atol_temp 1.0e-8



jacobian override so that the default is an analytical Jacobian 1

rtol_enuc 1.0e-6


17



rtol_spec 1.0e-12

rtol_temp 1.0e-6

Table 3.19: xrb simple parameters.


atol_enuc 1.0e-8


atol_temp 1.0e-8



jacobian override so that the default is a numerical Jacobian; we don’t yet have an analyticalJacobian

2

rtol_enuc 1.0e-8

rtol_spec 1.0e-12

rtol_temp 1.0e-8

CHAPTER 4

Equations of State

In this chapter on equations of state, we list the EOS routines available for your use, and then wedescribe the correct structure of an EOS module in case you want to build your own.

4.1 Available Equations of State

The following equations of state are available in Microphysics. Except where noted, each of theseEOSs will provide the full thermodynamic data (including all derivatives) in the eos t type.

4.1.1 gamma law general

gamma law general represents a gamma law gas, with equation of state:

p = (γ − 1)ρe. (4.1)

γ is specified by the runtime parameter eos gamma. For an ideal gas, this represents the ratio ofspecific heats. The gas is assumed to be ideal, with the pressure given by

p =ρkT

µmu(4.2)

where k is Boltzmann’s constant and µ is the mean molecular weight, calculated from the compo-sition, Xk. This EOS assumes the gas is either completely neutral (assume neutral = T), giving:

µ−1 =∑k

Xk

Ak(4.3)

19

20 Chapter 4. Equations of State

or completely ionized (assume neutral = F), giving:

µ−1 =∑k

(1 + Zk)Xk

Ak(4.4)

The entropy comes from the Sackur-Tetrode equation. Because of the complex way that compositionenters into the entropy, the entropy formulation here is only correct for a γ = 5/3 gas.

Note that the implementation provided in Microphysics is the same as the version shipped withMAESTRO, but more general than the gamma law EOS provided with CASTRO. CASTRO’s defaultEOS only fills the thermodynamic information in eos t that is required by the hydrodynamicsmodule in CASTRO.

4.1.2 polytrope

polytrope represents a polytropic fluid, with equation of state:

p = Kργ . (4.5)

The gas is also assumed to obey the above gamma law relation connecting the pressure and internalenergy. Therefore ρ is the only independent variable; there is no temperature dependence. Theuser either selects from a set of predefined options reflecting physical polytropes (e.g. a non-relativistic, fully degenerate electron gas) or inputs their own values for K and γ via polytrope K

and polytrope gamma.

The runtime parameter polytrope type selects the pre-defined polytropic relations. The optionsare:

• polytrope type = 1: sets γ = 5/3 and

K =

(3

π

)2/3 h2

20mem5/3p

1

µ5/3e

(4.6)

where mue is the mean molecular weight per electron, specified via polytrope mu e

This is the form appropriate for a non-relativistic fully-degenerate electron gas.

• polytrope type = 2: sets γ = 4/3 and

K =

(3

π

)1/3 hc

8m4/3p

1

µ4/3e

(4.7)

This is the form appropriate for a relativistic fully-degenerate electron gas.

4.1.3 ztwd

ztwd is the zero-temperature degenerate electron equation of state of Chandrasekhar (1935), whichis designed to describe white dward material. The pressure satisfies the equation:

p(x) = A(x(2x2 − 3)(x2 + 1)1/2 + 3 sinh−1(x)

), (4.8)

4.1—Available Equations of State 21

with A = πm4ec

5/(3h3). Here x is a dimensionless measure of the Fermi momentum, with ρ = Bx3

and B = 8πµempm3ec

3/(3h3), where µe is the mean molecular weight per electron and h is thePlanck constant.

The enthalpy was worked out by Hachisu (1986):

h(x) =8A

B

(x2 + 1

)1/2. (4.9)

(note the unfortunate notation here, but this h is specific enthalpy). The specific internal energysatisfies the standard relationship to the specific enthalpy:

e = h− p/ρ. (4.10)

Since the pressure-density relationship does not admit a closed-form solution for the density in termsof the pressure, if we call the EOS with pressure as a primary input then we do Newton-Raphsoniteration to find the density that matches this pressure.

4.1.4 multigamma

multigamma is an ideal gas equation of state where each species can have a different value of γ.This mainly affects how the internal energy is constructed as each species, represented with amass fraction Xk will have its contribution to the total specific internal energy take the form ofe = p/ρ/(γk − 1). The main thermodynamic quantities take the form:

p =ρkT

mu

∑k

Xk

Ak(4.11)

e =kT

mu

∑k

1

γk − 1

Xk

Ak(4.12)

h =kT

mu

∑k

γkγk − 1

Xk

Ak(4.13)

We recognize that the usual astrophysical A−1 =∑

kXk/Ak, but now we have two other sums thatinvolve different γk weightings.

The specific heats are constructed as usual,

cv =∂e

∂T

∣∣∣∣ρ

=k

mu

∑k

1

γk − 1

Xk

Ak(4.14)

cp =∂h

∂T

∣∣∣∣p

=k

mu

∑k

γkγk − 1

Xk

Ak(4.15)

and it can be seen that the specific gas constant, R ≡ cp−cv is independent of the γi, and is simplyR = k/muA giving the usual relation that p = RρT . Furthermore, we can show

Γ1 ≡∂ log p

∂ log ρ

∣∣∣∣s

=

(∑k

γkγk − 1

Xk

Ak

)/(∑k

1

γk − 1

Xk

Ak

)=cpcv≡ γeffective (4.16)

and p = ρe(γeffective − 1).

This equation of state takes several runtime parameters that can set the γi for a specific species.The parameters are:

22 Chapter 4. Equations of State

• eos gamma default: the default γ to apply for all species

• species X name and species X gamma: set the γi for the species whose name is given asspecies X name to the value provided by species X gamma. Here, X can be one of the letters:a, b, or c, allowing us to specify custom γi for up to three different species.

4.1.5 helmholtz

helmholtz contains a general, publicly available stellar equation of state based on the Helmholtz freeenergy, with contributions from ions, radiation, and electron degeneracy, as described in [9, 10, 5].

We have modified this EOS a bit to fit within the context of our codes. The vectorization isexplicitly thread-safe for use with OpenMP and OpenACC. In addition, we have added the abilityto perform a Newton-Raphson iteration so that if we call the EOS with density and energy (say),then we will iterate over temperature until we find the temperature that matches this density–energycombination. If we cannot find an appropriate temperature, we will reset it to small temp, whichneeds to be set in the equation of state wrapper module in the code calling this. However, thereis a choice of whether to update the energy to match this temperature, respecting thermodynamicconsistency, or to leave the energy alone, respecting energy conservation. This is controlled throughthe eos input is constant parameter in your extern namelist in your probin file.

We thank Frank Timmes for permitting us to modify his code and publicly release it in thisrepository.

4.1.6 stellarcollapse

stellarcollapse is the equation of state module provided on http://stellarcollapse.org. It isdesigned to be used for core-collapse supernovae and is compatible with a large number of equationsof state that are designed to describe matter near nuclear density. You will need to download anappropriate interpolation table from that site to use this.

4.2 Interface and Modes

4.3 Initialization and Cutoff Values

4.4 Input Validation

The EOS will make sure that the inputs are within an acceptable range, (e.g., small temp < T <maxT). If they are not, then it resets them silently—no error is thrown.

If you are calling the EOS with eos input re, and if e < 10−200, then it calls the EOS witheos input rt with T = max{small temp, T}.

User’s are encourage to do their own validation of inputs before calling the EOS.

http://stellarcollapse.org

4.5—EOS Structure 23

4.5 EOS Structure

Each EOS should have two main routines by which it interfaces to the rest of CASTRO. At thebeginning of the simulation, specific eos init will perform any initialization steps and save EOSvariables (mainly smallt, the temperature floor, and smalld, the density floor). These variables arestored in the main EOS module of the code calling these routines. This would be the appropriatetime for, say, loading an interpolation table into memory.

The main evaluation routine is called specific eos. It should accept an eos input and aneos state; see Section 2.

CHAPTER 5

Nuclear Reaction Networks

5.1 Network Requirements and Structure

A network both defines the composition advected by the hydro code as well as describes the burningprocesses between those isotopes. Evolving the species in a network requires an integrator. Thedesign of Microphysics decouples the integrator from the network, allowing for the ability to swapintegrators as desired. We discuss the integrators in a later section.

At a minimum, a network needs to provide:

• nspec : the number of species in the network

• nspec evolve : the number of species that are actually integrated in the network. Usuallythis is nspec, but in general any nspec evolve ≤ nspec is allowed. Those species not evolvedare held constant in the integration.

Note that the convention is that the first nspec evolve out of the nspec species are the onesevolved.

• nrates : the number of reaction rates. This is used to allocate space in the rate t type

• num rate groups : the number of components for each reaction rate we want to store in therate t type

• naux : the number of auxiliary quantities needed by the network (these are not evolved).does any net usethese?

• aion(:) : the atomic weight (in atomic mass units) of the species

• zion(:) : the atomic number of the species

• spec names(:) : a descriptive name of the species (e.g. "hydrogen-1")

• short spec names(:) : a shorten version of the species name (e.g. "H1")

25

26 Chapter 5. Nuclear Reaction Networks

• short aux names(:) : the names of the auxiliary quantities

• network name : a descriptive name for the network

Most of these quantities are Fortran parameters.

A convention adopted in Microphysics is that each network is responsible for determin-ing the energy release from a change in composition. Most networks will provide an arrayof the species binding energies and a routine to compute the energy yield from the reaction rates.

There are three primary files within each network directory.

• actual network.f90:

This is the Fortran module actual network with routines:

– actual network init()

– actual network finalize()

This supplies the number and names of species and auxiliary variables, as well as otherinitializing data, such as their mass numbers, proton numbers, and binding energies. It needsto define the nspec and naux quantities as integer parameters. Additionally it must definenspec evolve, the number of species that are actually evolved during a burn; in most cases,this should have the same value as nspec. Finally, it must also define nrates, the number ofreaction rates linking the isotopes in the network.

• actual rhs.f90:

This is the Fortran module actual rhs module, with routines:

– actual rhs init()

– actual rhs(state)

– actual jac(state)

This supplies an interface for computing the right-hand-side of the network, the time-derivative of each species (and the temperature and nuclear energy release), as well as theanalytic Jacobian. Both actual rhs and actual jac take a single argument, a burn t state.They set the time-derivatives and Jacobian elements in this derived type directly.

Note: some networks do not provide an analytic Jacobian and instead rely on the numericaldifference-approximation to the Jacobian. In this case, the interface actual jac is still neededto compile.

• actual burner:

This is the Fortran module actual burner module, with routines:

– actual burner init()

– actual burner(state in, state out, dt, time)

This contains the interface for doing an actual burn. Here, state in and state out areburn t objects. In general, you will want to call integrator to use one of the pre-definedODE integrators, but you could also write a custom integration here. This is covered in moredetail in § 5.4.

5.2—Available Networks 27

Notice that all three of these modules have initialization routines:

• actual network init()

• actual rhs init()

• actual burner init()

These must be called upon initialization. These should be not called within OpenMP parallelregions, because in general they will modify shared module data.

Note, depending on the network, some of these may do nothing, but these interfaces are all requiredfor maximum flexibility.

5.2 Available Networks

5.2.1 aprox13, aprox19, and aprox21

These are alpha-chains (with some other nuclei) from Frank Timmes. These networks share commonrates (from Microphysics/rates), plasma neutrino loses (from Microphysics/neutrinos), andelectron screening (from Microphysics/screening).

Energy generation. These networks store the total binding energy of the nucleus in MeV asbion(:). They then compute the mass of each nucleus in grams as:

Mk = (Ak − Zk)mn + Zk(mp +me)−Bk (5.1)

where mn, mp, and me are the neutron, proton, and electron masses, Ak and Zk are the atomicweight and number, and Bk is the binding energy of the nucleus (converted to grams). Mk is storedas mion(:) in the network.

The energy release per gram is converted from the rates as:

e = −NAc2∑k

dYkdt

Mk − eν (5.2)

where NA is Avogadro’s number (to convert this to “per gram”) and eν is the neutrino loss term.

5.2.2 breakout

5.2.3 CONe2NSE

5.2.4 general null

general null is a bare interface for a nuclear reaction network; no reactions are enabled, and noauxiliary variables are accepted. The data in the Fortran module is defined at compile type byspecifying an inputs file. For example, Networks/general null/triple alpha plus o.net woulddescribe the triple-α reaction converting helium into carbon, as well as oxygen and iron.


At compile time, the network module actual network.f90 is written using the python scriptwrite network.py and the template network.template. The make rule for this is contained inMake.package (for C++ AMReX) and GPackage.mak (for F90 AMReX). The name of the inputs fileis specified by the variable GENERAL NET INPUTS.

A version of this network comes with MAESTRO and CASTRO, so you do not usually need to worryabout the version in Microphysics.

5.2.5 ignition chamulak

This network was introduced in our paper on convection in white dwarfs as a model of Type Iasupernovae [14]. It models carbon burning in a regime appropriate for a simmering white dwarf,and captures the effects of a much larger network by setting the ash state and energetics to thevalues suggested in [3].

This network has nspec = 3, but nspec evolve = 1. Only a single reaction is modeled, converting12C into “ash”.

Energy generation. The binding energy, q, in this network is interpolated based on the density.It is stored as the binding energy (ergs/g) per nucleon, with a sign convention that binding energiesare negative. The energy generation rate is then:

e = qdX(12C)

dt= qA12C

dY (12C)

dt(5.3)

(this is positive since both q and dY/dt are negative)

5.2.6 ignition reaclib

5.2.7 ignition simple

This is the original network used in our white dwarf convection studies [12]. It includes a single-step12C(12C, γ)24Mg reaction. The carbon mass fraction equation appears as

DX(12C)

Dt= − 1

12ρX(12C)2fCoul [NA 〈σv〉] , (5.4)

where NA 〈σv〉 is evaluated using the reaction rate from (Caughlan and Fowler 1988). The Coulombscreening factor, fCoul, is evaluated using the general routine from the Kepler stellar evolution code(Weaver 1978), which implements the work of (Graboske 1973) for weak screening and the work of(Alastuey 1978 and Itoh 1979) for strong screening.

5.2—Available Networks 29

5.2.8 iso7

5.2.9 kpp

5.2.10 powerlaw

This is a simple single-step reaction rate. We will consider only two species, fuel, f , and ash, a,through the reaction: f + f → a + γ. Baryon conservation requres that Af = Aa/2, and chargeconservation requires that Zf = Za/2. We take our reaction rate to be a powerlaw in temperature.The standard way to write this is in terms of the number densities, in which case we have

dnfdt

= −2dnadt

= −r (5.5)

with

r = r0n2X

(T

T0

)ν(5.6)

Here, r0 sets the overall rate, with units of [cm3 s−1], T0 is a reference temperature scale, and ν isthe temperature exponent, which will play a role in setting the reaction zone thickness. In termsof mass fractions, nf = ρXa/(Aamu), our rate equation is

dXf

dt= − r0

muρX2

f

1

Af

(T

T0

)ν≡ ωf (5.7)

dXa

dt=

1

2

r0

muρX2

f

AaA2f

(T

T0

)ν=

r0

muρX2

f

1

Af

(T

T0

)ν(5.8)

We define a new rate constant, r0 with units of [s−1] as

r0 =

r0

muAfρ0 if T ≥ Ta

0 if T < Ta

(5.9)

where ρ0 is a reference density and Ta is an activation temperature, and then our mass fractionequation is:

dXf

dt= −r0X

2f

(ρ

ρ0

)(T

T0

)ν(5.10)

Finally, for the energy generation, we take our reaction to release a specific energy, [erg g−1], ofqburn, and our energy source is

ε = −qburndXf

dt(5.11)

There are a number of parameters we use to control the constants in this network. This is one ofthe few networks that was designed to work with gamma law general as the EOS.

5.2.11 rprox

This network contains 10 species, approximating hot CNO, triple-α, and rp-breakout burning upthrough 56Ni, using the ideas from [11], but with modern reaction rates from ReacLib [4] whereavailable. This network was used for the X-ray burst studies in [6, 13], and more details arecontained in those papers.


5.2.12 triple alpha plus cago

This is a 2 reaction network for helium burning, capturing the 3-α reaction and 12C(α, γ)16O.Additionally, 56Fe is included as an inert species.

This network has nspec = 4, but nspec evolve = 3.

5.2.13 xrb simple

This is a simple 7 isotope network approximating the burning that takes place in X-ray bursts(6 isotopes participate in reactions, one additional, 56Fe, serves as an inert composition). The 6reactions modeled are:

• 3α+ 2p→ 14O (limited by the 3-α rate)

• 14O + α→ 18Ne (limited by 14O(α, p)17F rate)

• 15O + α+ 6p→ 25Si (limited by 15O(α, γ)19Ne rate)

• 18Ne + α+ 3p→ 25Si (limited by 18Ne(α, p)21Na rate)

• 14O + p→ 15O (limited by 14O(e+ ν)14N rate)

• 15O + 3p→ 14O + α (limited by 15O(e+ ν)15N rate)

All reactions conserve mass. Where charge is not conserved, fast weak interactions are assumed.Weak rates are trivial, fits to the 4 strong rates to a power law in T9 ∈ [0.3, 1], linear in density.

5.3 Reaction ODE System

The equations we integrate to do a nuclear burn are:

dYkdt

= ωk(ρ, Yk, T ), (5.12)

de

dt= f(Yk) (5.13)

dT

dt=

e

cx. (5.14)

Here Yk ≡ Xk/Ak is the molar fraction of species k, where Xk is the mass fraction and Ak is themass number of that species. e is the internal energy, T is the temperature1 , and cx is the specificheat for the fluid. The function f provides the energy release based on the instantaneous reactionterms, Yk. As noted in the previous section, this is implemented in a network-specific manner.

In this system, e is not necessarily the total specific internal energy, but rather just captures theenergy release during the burn.

1Note that in previous versions of our networks in CASTRO and MAESTRO, there was another term in thetemperature equation relating to the chemical potential of the gas as it came from the EOS. We have since decidedthat this term should analytically cancel to zero in all cases for our nuclear networks, and so we no longer think itis correct to include a numerical approximation of it in the integration scheme. So the current results given by ournetworks will in general be a little different than in the past.

5.3—Reaction ODE System 31

Note that while Yk is the integration variable, this is invisible to the code that callsthe burner—it hands the burner the mass fractions Xk and gets back updated massfractions.

While this is the most common way to construct the set of burn equations, and is used in mostof our production networks, all of them are ultimately implemented by the network itself, whichcan choose to disable the evolution of any of these equations by setting the RHS to zero. Theintegration software provides some helper routines that construct common RHS evaluations, likethe RHS of the temperature equation given e, but these calls are always explicitly done by theindividual networks rather than being handled by the integration backend. This allows you towrite a new network that defines the RHS in whatever way you like.

5.3.1 Interfaces

The righthand side of the network is implemented by actual rhs() in actual rhs.f90, and ap-pears as:

subroutine actual_rhs(state)

type (burn_t) :: state

All of the necessary integration data comes in through state, as:

• state % xn(:) : the nspec mass fractions (note: for the case that nspec evolve < nspec,an algebraic constraint may need to be enforced. See § 5.3.3).

• state % e : the current value of the ODE system’s energy release—note: as discussed above,this is not necessarily the energy you would get by calling the EOS on the state. It is veryrare (never?) that a RHS implementation would need to use this variable.

• state % T : the current temperature

• state % rho : the current density

Note that we come in with the mass fractions, but the molar fractions can be computed as:

double precision :: y(nspec)

...

y(:) = state % xn(:) / aion (:)

The actual rhs() routine’s job is to fill the righthand side vector for the ODE system, state %

ydot(:). Here, the important fields to fill are:

• state % ydot(1:nspec evolve) : the change in molar fractions for the nspec evolve

species that we are evolving, d(Yk)/dt

• state % ydot(net ienuc) : the change in the energy release from the net, de/dt

• state % ydot(net itemp) : the change in temperature, dT/dt

If the network builds the RHS in terms of mass fractions, dXk/dt, then these will need to beconverted to molar fraction rates for storage, e.g., dYk/dt = A−1

k dXk/dt.

The Jacobian is provided by actual jac(state), and takes the form:


subroutine actual_jac(state)


The Jacobian matrix elements are stored in state % jac as:

• state % jac(m, n) for m,n ∈ [1,nspec evolve] : d(Ym)/dYn

• state % jac(net ienuc, n) for n ∈ [1, nspec evolve] : d(e)/dYn

• state % jac(net itemp, n) for n ∈ [1, nspec evolve] : d(T )/dYn

• state % jac(m, net itemp) for m ∈ [1,nspec evolve] : d(Ym)/dT

• state % jac(net ienuc, net itemp) : d(e)/dT

• state % jac(net itemp, net itemp) : d(T )/dT

• state % jac(p, net ienuc) = 0 for p ∈ [1, neqs], since nothing should depend on theintegrated energy release

Note: a network is not required to compute a Jacobian if a numerical Jacobian is used. This is setwith the runtime parameter jacobian = 2, and implemented in integration/numerical jacobian.f90

using finite-differences.

5.3.2 Thermodynamics and T Evolution

5.3.2.1 Burning Mode

There are several different modes under which the burning can be done, set via the burning mode

runtime parameter:

• burning mode = 0 : hydrostatic burning

ρ, T remain constant

• burning mode = 1 : self-heating burn

T evolves with the burning according to the temperature evolution equation. This is the“usual” way of thinking of the burning—all three equations (Eqs. 5.12, 5.13, and 5.14) aresolved simultaneously.

• burning mode = 2 : hybrid approach

This implements an approach from [8] in which we do a hydrostatic burn everywhere, but ifwe get a negative energy change, the burning is redone in self-heating mode (the logic beingthat a negative energy release corresponds to NSE conditions)

• burning mode = 3 : suppressed burning

This does a self-heating burn, but limits all values of the RHS by a factor L = min(1, fs(e/e)/ts),such that e = fs e/ts, where fs is a safety factor, set via burning mode factor.

When the integration is started, the burning mode is used to identify whether temperature evolutionshould take place. This is used to set the self heat field in the burn t type passed into the RHSand Jacobian functions.

5.3—Reaction ODE System 33

5.3.2.2 EOS Calls

The evolution of the thermodynamic quantities (like specific heats and other partial derivatives)can be frozen during the integration to their initial values, updated for every RHS call, or somethingin-between. Just before we call the network-specific RHS routine, we update the thermodynamicsof our state (by calling update thermodynamics)2 The thermodynamic quantity update dependson two runtime parameters, call eos in rhs and dT crit:

• call eos in rhs = T:

We call the EOS just before every RHS evaluation, using ρ, T as inputs. Therefore, thethermodynamic quantities will always be consistent with the input state.

• call eos in rhs = F

Here we keep track of the temperature, Told, at which the EOS was last called (which maybe the start of integration).

IfT − Told

T> dT crit (5.15)

then we update the thermodynamics. We also compute d(cv)/dT and d(cp)/dT via differ-encing with the old thermodynamic state and store these in the integrator. If this inequalityis not met, then we don’t change the thermodynamics, but simply update the compositionterms in the EOS state, e.g., A.

We interpret dT crit as the fractional change needed in the temperature during a burnto trigger an EOS call that updates the thermodynamic variables. Note that this is fullyindependent of call eos in rhs.

5.3.2.3 T Evolution

A network is free to write their own righthand side for the temperature evolution equationin its actual rhs() routine. But since this equation only really needs to know the instanta-neous energy generation rate, e, most networks use the helper function, temperature rhs (inintegration/temperature integration.f90):

subroutine temperature_rhs(state)


This function assumes that state % ydot(net ienuc) is already filled and simply fills state %

ydot(net itemp) according to the prescription below.

We need the specific heat, cx. Note that because we are evaluating the temperature evolutionindependent of any hydrodynamics, we do not incorporate any advective or pdV terms in theevolution. Therefore, for our approximation here, we need to decide which specific heat we want—usually either the specific heat at constant pressure, cp, or the specific heat at constant volume,cv. The EOS generally will provide both of these specific heats; which one to use is a choice theuser needs to make based on the physics of their problem. This is controlled by the parameter

2Note: each integrator provides its own implementation of this, since it operates on the internal data-structure ofthe integrator, but the basic procedure is the same.


do constant volume burn, which will use cv if .true. and cp is .false.. See [1] for a discussionof the temperature evolution equation.

A fully accurate integration of Equation 5.14 requires an evaluation of the specific heat at eachintegration step, which involves an EOS call given the current temperature. This is done ifcall eos in rhs = T, as discussed above. This may add significantly to the expense of the calcu-lation, especially for smaller networks where construction of the RHS is inexpensive

For call eos in rhs = F, we can still capture some evolution of the specific heat by periodicallycalling the EOS (using dT crit as described above) and extrapolating to the current temperatureas:

cx = (cx)0 +T − T0

d(cx)/dT |0(5.16)

where the ‘0’ quantities are the values from when the EOS was last called. This represents a middleground between fully on and fully off.

Note: if state % self heat = F, then we do not evolve temperature.

The runtime parameter integrate temperature can be used to disable temperature evolution (byzeroing out ydot(net itemp)).

why do this over thehydrostatic burnmode?

5.3.2.4 Energy Integration

The last equation in our system is the specific internal energy evolution, e. Again, because of theoperator-split approach to this ODE system, the evolution of e responds only to the nuclear energyrelease.

At initialization, e is set to the value from the EOS consistent with the initial temperature, density,and composition:

e0 = e(ρ0, T0, Xk0) (5.17)

In the integration routines, this is termed the “energy offset”.

As the system is integrated, e is updated to account for the nuclear energy release,

e(t) = e0 +

∫ t

t0

f(Yk)dt (5.18)

Note that thermodynamic consistency will no longer be maintained (because density doesn’t evolveand the T evolution is approximate) but e will represent an approximation to the current specificinternal energy, including the nuclear energy generation release.

Upon exit, we subtract off this initial offset, so % e in the returned burn t type from theactual integrator call represents the energy release during the burn.

5.3.3 nspec evolve Implementation

For networks where nspec evolve < nspec, it may be necessary to reset the species mass fractionseach time you enter the RHS routine. As an example, the network ignition chamulak has 3species, 12C, 16O, and 24Mg. In this network, 16O is not evolved at all and any change in 12C is

5.4—Stiff ODE Solvers 35

reflected in 24Mg. So we can evolve only the equation for 12C. The algebraic relation between theunevolved mass fractions that must be enforced then is:

X(24Mg) = 1−X(12C)−X(16O) (5.19)

This is implemented in the routine update unevolved species:

subroutine update_unevolved_species(state)


This needs to be explicitly called in actual rhs before the mass fractions from the input state areaccessed. It is also called directly by the integrator at the end of integration, to make sure the finalstate is consistent.

should we do this inthe conversion tothe burn type?

5.3.4 Evolving Mass Fractions

The default set of integration variables are {Yk, T, e}, but the system {Xk, T, e} can instead beevolved by setting the runtime parameter integrate molar fraction = F. This switches the in-ternal integration variables from Yk to Xk. No network-specific routines need to be changed, e.g.,inputs to actual rhs and actual jac remain unchanged, and still return their derivatives state

% ydot and state % jac in terms of Yk. These derivatives are converted to be in terms of Xk bymultiplying / dividing by Ak where appropriate by the wrappers that interface with the RHS andJacobian routines.

Analytically there should be no difference in the result of integrating Xk instead of Yk, but numer-ically, anecdotal evidence suggests that some networks meet their tolerances more easily when Xk

is the integration variable.

5.3.5 Renormalization

The renormalize abundances parameter controls whether we renormalize the abundances so thatthe mass fractions sum to one during a burn. This has the positive benefit that in some cases it canprevent the integrator from going off to infinity or otherwise go crazy; a possible negative benefitis that it may slow down convergence because it interferes with the integration scheme. Regardlessof whether you enable this, we will always ensure that the mass fractions stay positive and largerthan some floor small x.

do we alwaysrenormalize at theend?

5.4 Stiff ODE Solvers

The integration tolerances for the burn are controlled by rtol spec, rtol enuc, and rtol temp,which are the relative error tolerances for Eqs. 5.12, 5.13, and 5.14, respectively. There are corre-sponding atol parameters for the absolute error tolerances. Note that not all integrators handleerror tolerances the same way—see the sections below for integrator-specific information.

We integrate our system using a stiff ordinary differential equation integration solver. The absoluteerror tolerances are set by default to 10−12 for the species, and a relative tolerance of 10−6 is usedfor the temperature and energy. The integration yields the new values of the mass fractions, Y out

k .


There are several options for integrators. Each should be capable of evolving any of the networks,but varying in their approach. Internally, the integrators uses different data structures to store theintegration progress (from the old-style rpar array in VODE to derived types), and each integratorneeds to provide a routine to convert from the integrator’s internal representation to the burn t

type required by the actual rhs and actual jac routine.

The name of the integrator can be selected at compile time using the INTEGRATOR DIR variable inthe makefile. Presently, the allowed options are BS, VBDF, and VODE.

5.4.1 actual integrator

The entry point to the integrator is actual integrator:

subroutine actual_integrator(state_in , state_out , dt, time)

type (burn_t), intent(in ) :: state_in

type (burn_t), intent(inout) :: state_out

real(dp_t), intent(in ) :: dt , time

A basic flow chart of this interface is as follows (note: there are many conversions between eos t,burn t, and any integrator-specific type implied in these operations):

1. Call the EOS on the input state, using ρ, T as the input variables.

This involves:

(a) calling burn to eos to produce an eos t with the thermodynamic information.

(b) calling the EOS

(c) calling eos to XX, where XX is, e.g. bs, the integrator type. This copies all of the relevantdata into the internal representation used by the integrator.

We use the EOS result to define the energy offset for e integration.

2. Compute the initial d(cx)/dT derivatives, if necessary, by finite differencing on the tempera-ture.

3. Call the main integration routine to advance the inputs state through the desired time interval,producing the new, output state.

4. If necessary (integration failure, burn mode demands) do any retries of the integration

5. Subtract off the energy offset—we now store just the energy release as state out % e

6. Convert back to a burn t type (by calling XX to burn).

7. update any unevolved species, for nspec evolve < nspec

8. normalize the abundances so they sum to 1

5.4—Stiff ODE Solvers 37

5.4.2 Righthand side wrapper

Each integrator does their own thing to construct the solution, but they will all need to assess theRHS in actual rhs, which means converting from their internal representation to the burn t type.This is handled in a file called XX rhs.f90, where XX is the integrator name. The basic outline ofthis routine is:

1. call clean state

This function operates on the ODE integrator vector directly (accessing it from the integra-tor’s internal data structure). It makes sure that the mass fractions lie between [10−30, 1] andthat the temperature lies between [small temp, 1011]. The latter upper limit is arbitrary, butis safe for the types of problems we support with these networks.

2. renormalize the species, if renormalize abundances = Twe should put thecall toupdate unevolved species

before this, insteadof in theactual rhs

3. update the thermodynamic quantities if we are doing call eos in rhs or the dT crit requires

4. convert to a burn t type and call the actual RHS

5. convert derives to mass-fraction-based (if integrate molar fraction = F and zero out thetemperature or energy derivatives (if integrate temperature = F or integrate energy =

F, respectively).

6. limit the rates if burning mode = 3

7. convert back to the integrator’s internal representation

5.4.3 BS

This integrator is based on the stiff-ODE methods from [7], but written with reaction networkintegration in mind (so it knows about species), and in a modular / threadsafe fashion to workwith our data structures. This integrator appears quite robust.

bs t data structure. The bs t type is the main data structure for the BS integrator. This holdsthe integration variables (as y(1:neqs)) and data associated with the timestepping. It also holdsa burn t type as bs t % burn s. This component is used to interface with the networks. Theconversion routines bs to burn and burn to bs simply sync up bs t % y(:) and bs t % burn s.

The upar(:) component contains the meta-data that is not held in the burn t but nevertheless isassociate with the current state. This is an array that can be indexed via the integers define in therpar indices module. Note that because the bs t contains its own burn t type, the BS integratordoes not need as much meta-data as some other integrators. The fields of upar are:

• bs t % upar(irp nspec : irp nspec-1+n not evolved)

These are the mass fractions of the nspec - nspec evolve species that are not evolved inthe ODE system.

• bs t % upar(irp y init : irp y init-1+neqs)

This is the initial values of the ODE integration vector.


• bs t % upar(irp t sound)

This is the sound-crossing time for a zone.

• bs t % upar(irp t0)

This is the simulation time at the start of integration. This can be used as an offset to convertbetween simulation time and integration time (we always start the integration at t = 0).

Error criteria. There is a single relative tolerance used for all ODEs, instead of a separateone for species, temperature, and energy, it is simply the maximum of {rtol spec, rtol temp,rtol enuc}. The absolute tolerance parameters are ignored.

A relative tolerance needs a metric against which to compare. BS has two options, chosen by theruntime parameter scaling method. Considering a vector y = (Yk, e, T )ᵀ, the scales to compareagainst, yscal, are:

• scaling method = 1 :

yscal = |y|+ ∆t|y|+ ε (5.20)

This is an extrapolation of y in time. The quantity ε is a small number (hardcoded to 10−30)to prevent any scale from being zero.

• scaling method = 2 :

(yscal)j = max (|yj |, ode scale floor) (5.21)

for j = 1, . . . , neq. Here, ode scale floor is a runtime parameter that sets a lower-limit tothe scaling for each variable in the vector yscal. The default value is currently 10−6 (althoughany network can override this using priorities). The effect of this scaling is that species withan abundance � ode scal floor will not be used as strongly in assessing the accuracy of astep.

These correspond to the options presented in [7].

A final option, use timestep estimator enables the timestep estimator from VODE to determinea good starting timestep for integration.

5.4.4 VODE

VODE is a classic integration package described in [2]. We use the implicit integration method inthe package.

data structures. VODE does not allow for derived types for its internal representation andinstead simply uses a solution vector, y(neqs), and an array of parameters, rpar(:). The indicesinto rpar are defined in the rpar indices module.

tolerances. Our copy of VODE is made threadsafe by use of the OpenMP threadprivate direc-tive on Fortran common blocks. However, due to the use of computed go tos, we have not portedit to GPUs using OpenACC.

5.5—Overriding Parameter Defaults on a Network-by-Network Basis 39

5.4.5 VBDF

VBDF is a modern implementation of the methods in VODE, written by Matt Emmett. It supportsintegrating a vector of states, but we do not use that capability.

The error criteria is the same as VODE—separate relative, rtol, and absolute, atol, error toler-ances are specified for each variable that is being integrated. A weight is constructed as:

Wm =1

rtolm|ym|+ atolm(5.22)

where needed, the error, ε, is constructed by computing an L2 norm:

ε =

[1

N

∑m

(ymWm)2

]1/2

(5.23)

where m = 1, . . . , N indexes the ODE solution vector. With this weighting, ε < 1 means we’veachieved our desired accuracy.

5.4.6 Retries

5.5 Overriding Parameter Defaults on a Network-by-Network Ba-sis

Any network can override or add to any of the existing runtime parameters by creating aparameters file in the network directory (e.g., networks/triple alpha plus cago/ parameters).

As noted in Chapter , the fourth column in the parameter file definition is the priority. When aduplicate parameter is encountered by the scripts writing the extern probin module, the value ofthe parameter with the highest priority is used. So picking a large integer value for the priority ina network’s parameter file will ensure that it takes precedence.

CHAPTER 6

Transport Coefficients

6.1 Thermal Conductivity

Thermal conductivities are provided by the conductivity/ directory. At the moment, there is asingle version, stellar1 that is useful for stellar interiors.

Important: it is assumed that the state is thermodynamically consistent before callingthe conductivity routine. It may be necessary to do an EOS call first, to enforce the consistency.

1this code comes from Frank Timmes’ website, http://cococubed.asu.edu/code_pages/kap.shtml

41

http://cococubed.asu.edu/code_pages/kap.shtml

CHAPTER 7

OpenACC

7.1 General Ideas

7.2 Common Compiler Errors

7.2.1 PGI

To get more detailed about what kernels are launching, do:

export PGI_ACC_NOTIFY=1

Compilation errors

• Multiple exit statements

PGF90-S-0155-Compiler failed to translate accelerator region (see -Minfo messages):

Unexpected flow graph (../../integration/BS/stiff_ode.F90: 1)

single_step_rosen:

This results when you have multiple exit statements from a do-loop. You need to consolidateany error/convergence checking in a loop and have at most a single exit statement.

Note: sometimes a do while can help here, but there is a sense that while-loops do notperform optimally on GPUs.

• ACC routines not in Fortran modules

PGF90-S-0155-Procedures called in a compute region must have acc routine information:

dgefa (../../integration/BS/stiff_ode.F90: 711)

43

44 Chapter 7. OpenACC

PGF90-S-0155-Accelerator region ignored; see -Minfo messages

(../../integration/BS/stiff_ode.F90)

This occurs when a subroutine relies on another routine that is not part of a Fortran 90module. In this case, even if that routine already has

!$acc routine seq

we need to mark the calling routine as well, with:

!$acc routine(dgesl) seq

(e.g., for the Fortran routine dgesl).

Runtime errors

• Multi-d array copies

Unhandled builtin: 601 (pgf90_mzero8)

PGF90-F-0000-Internal compiler error. Unhandled builtin function.

0 (../../networks/triple_alpha_plus_cago/actual_rhs.f90: 146)

PGF90/x86-64 Linux 16.5-0: compilation aborted

This error results from doing a multi-d array copy (with Fortran notation) in GPU code. Thefix is to explicitly write out a loop over rows.

• Illegal memory access

call to cuMemcpyDtoHAsync returned error 700: Illegal address during kernel execution

call to cuMemFreeHost returned error 700: Illegal address during kernel execution

This indicates that you went out of bounds in memory access or, sometimes it seems, generatedsome NaNs.

7.3 Debugging

7.3.1 cuda-gdb

Basic debugging can be done using cuda-gdb. This will work just like gdb and can give you thename of a routine where a crash occurred, but generally doesn’t produce line numbers.

CHAPTER 8

Unit Tests

8.1 Comprehensive Unit Tests

There are 2 unit tests in Microphysics that operate on a generic EOS or reaction network. To allowthese to compile independent of any application code (e.g., MAESTRO or CASTRO), copies of theEOS driver eos.f90 and network interface network.f90 are provided in Microphysics/unit test/.These tests compile using the AMReX F90 build system. The file Microphysics/GMicrophysics.makprovides the macros necessary to build the executable. Runtime parameters are parsed in the samefashion as in the application codes, using the write probin.py script.

8.1.1 EOS test

Microphysics/unit test/test eos/ is a unit test for the equations of state in Microphysics. Itsets up a cube of data, with ρ, T , and Xk varying along the three dimensions, and then calls theEOS in each zone. Calls are done to exercise all modes of calling the EOS, in order:

• eos input rt: We call the EOS using ρ, T . this is the reference call, and we save the h, e, p,and s from here to use in subsequent calls.

• eos input rh: We call the EOS using ρ, h, to recover the original T . To give the root findersome work to do, we perturb the initial temperature.

We store the relative error in T in the output file.

• eos input tp: We call the EOS using T, p, to recover the original ρ. To give the root findersome work to do, we perturb the initial density.

We store the relative error in ρ in the output file.

45

46 Chapter 8. Unit Tests

• eos input rp: We call the EOS using ρ, p, to recover the original T . To give the root findersome work to do, we perturb the initial temperature.


• eos input re: We call the EOS using ρ, e, to recover the original T . To give the root findersome work to do, we perturb the initial temperature.


• eos input ps: We call the EOS using p, s, to recover the original ρ, T . To give the root findersome work to do, we perturb the initial density and temperature.

Note: entropy is not well-defined for some EOSs, so we only attempt the root find if s > 0.

We store the relative error in ρ, T in the output file.

• eos input ph: We call the EOS using p, h, to recover the original ρ, T . To give the root findersome work to do, we perturb the initial density and temperature.

We store the relative error in ρ, T in the output file.

• eos input th: We call the EOS using T, h, to recover the original ρ. To give the root findersome work to do, we perturb the initial density.

Note: for some EOSs, h = h(ρ) (e.g., and ideal gas), so there is no temperature dependence,and we do not do this test.

We store the relative error in ρ in the output file.

This unit test is marked up with OpenMP directives and therefore also tests whether the EOS isthreadsafe.

To compile for a specific EOS, e.g., helmholtz, do:

make EOS_DIR=helmholtz -j 4

Examining the output (a AMReX plotfile) will show you how big the errors are. You can use theAMReX/Tools/Postprocessing/ too fextrema to display the maximum error for each variable.

Note: an analogous test eos exists in MAESTRO.

8.1.2 Network test

Microphysics/unit test/test react/ is a unit test for the nuclear reaction networks in Micro-physics. It sets up a cube of data, with ρ, T , and Xk varying along the three dimensions (as a 163

domain), and then calls the EOS in each zone.

The state in each zone of our data cube is determined by the runtime parameters dens min,dens max, temp min, and temp max for (ρ, T ). Because each network carries different composi-tions, we specify explicitly the mass fraction of each species for every step in the compositiondimension in a file xin.* for each network. Note: it is up to the user to ensure that they speciesare in the proper order in that file and sum to 1. The name of the file to use is specified by theruntime parameter xin file.

8.2—Individual Network Tests 47

This test calls the network on each zone, running for a time tmax. The full state, including newmass fractions and energy release is output to a AMReX plotfile.

You can compile for a specific integrator (e.g., BS) or network (e.g., aprox13) as:

make NETWORK_DIR=aprox13 INTEGRATOR_DIR=BS -j 4

The loop over the burner is marked up for both OpenMP and OpenACC and therefore this testcan be used to assess threadsafety of the burners as well as to optimize the GPU performance ofthe burners.

8.2 Individual Network Tests

Many of the networks have a subdirectory test/ (e.g. Microphysics/networks/triple alpha plus cago/test/).There are usually 3 different drivers there that can be used to evaluate the network or Jacobian ona single state:

• eval.f90

• testburn.f90

• testjacobian.f90

These all use the F90 AMReX build system and the macros in GMicrophysics.mak to build theexecutable. To make individual tests you can use the programs variable, e.g.,

make programs=eval

8.3 burn cell

8.3.1 Getting Started

The burn cell codes are located in Microphysics/unit test/burn cell. To run a simulation,ensure that both an input file and an initial conditions file have been created and are in the samedirectory as the executable.

8.3.2 Input File

These files are typically named as inputs burn network where network is the network you wishto use for your testing.

The structure of this file is is fairly self-explanitory. The run prefix defined should be unique tothe tests that will be run as they will be used to identify all of the output files. Typically, the runprefix involves the name of the network being tested. The atol variables define absolute tolerancesof the ordinary differential equations and the rtol variables define the relative tolerances. Thesecond section of the input file collects the inputs that main.f90 asks for so that the user does nothave to input all 5+ parameters that are required everytime the test is run. Each input requiredis defined and initialized on the lines following &cellparams. The use of the parameters is definedin Table 8.1.

48 Chapter 8. Unit Tests

Name in main.f90 Definition

tmax Maximum Time (s)numsteps Number of time subdivisionsdensity State Density ( g

cm3 )temperature State Temperature (K)massfractions(i) Mass Fraction for element i

Table 8.1: The definition of parameters used in the burn cell unit tests and specified in the secondhalf of each inputs file.

8.3.3 Running the Code

To run the code, enter the burn cell directory and run ./main.Linux.gfortran.exe with theinputs file as an argument. For example: ./main.Linux.gfortran.exe inputs burn aprox13

For however many events are run, defined as numsteps in the inputs file, the code will outputthat many files into a new directory titled run prefix output where run prefix is the run prefixdefined in the inputs file. Each output file will be named using the run prefix defined in the inputsfile and the corresponding timestep.

Next, run burn cell.py using Python3 and listing the defined run prefix as an argument. Forexample: python3 burn cell.py react aprox13. The burn cell code will gather information fromall of the output files and compile them into three graphs explained below.

8.3.4 Graphs Output by burn cell.py

The file run-prefix logX.png and run-prefix logX.eps will display a graph of the chemicalabundances as a function of the time, both on logarithmic scales, for all species involved in thesimulation. An example of this graph is shown in Figure 8.1.

The file run-prefix ydot.png and run-prefix ydot.eps will display the Moller fraction (massfraction / atomic weight) as a function of time, both on logarithmic scales, for all species involvedin the code.

The file run-prefix T-edot.png and run-prefix T-edot.eps will display the Temperature andthe Energy Generation Rate as a function of time.

8.3—burn cell 49

Figure 8.1: An example of a plot output by the burn cell unit test. This is the logX outputcooresponding to the network aprox13.

CHAPTER 9

SDC

9.1 Introduction

SDC provides a means to more strongly couple the reactions to the hydrodynamics by evolving thereactions together with an approximation of the advection over the timestep.

We want to solve the coupled equations:

U t = A (U) + R(U) (9.1)

where U is the conserved state vector, U = (ρ, (ρXk), (ρU), (ρE))ᵀ, Xk are the mass fractionsconstrained via

∑kXk = 1, U is the velocity vector, and E is the specific total energy, related

to the specific internal energy, e, via E = e + |U|2/2. Here A (U) is the advective source term(including any hydrodynamical sources),

A (U) = −∇ · F(U) + Shydro (9.2)

and R(U) is the reaction source term.

9.2 Interface and Data Structures

9.2.1 sdc t

To accommodate the increased information required to evolve the coupled system, we introduce anew data type, sdc t. This is used to pass information to/from the integration routine from thehydrodynamics code.

51

52 Chapter 9. SDC

9.3 ODE system

The reactions don’t modify the total density, ρ, or momentum, ρU, so our ODE system is just:

d

dt

ρXk

ρEρe

=

[A (ρXk)]n+1/2

[A (ρE)]n+1/2

[A (ρe)]n+1/2

+

ρωkρS

ρS

(9.3)

where we include e in addition to E to provide additional thermodynamic information to help finda consistent T . Here the advective courses are piecewise-constant approximations to the change inthe state due to the hydrodynamics, computed with the during the hydro step.

However, to define the temperature, we need the kinetic energy (and hence momentum and density)at any intermediate time, t. We construct these as needed from

9.4 Interfaces

9.4.1 actual integrator

SDC integration provides its own implementation of the main entry point, actual integrator.

subroutine actual_integrator(state_in , state_out , dt, time)

type (sdc_t), intent(in ) :: state_in

type (sdc_t), intent(inout) :: state_out

real(dp_t), intent(in ) :: dt , time

The main difference here is that the type that comes in and out of the interface is no longer aburn t, but instead is an sdc t.

The flow of this main routine is simpler than the non-SDC version:

1. Convert from the sdc t type to the integrator’s internal representation (e.g., sdc to bs con-verts from a bs t for the BS integrator).

This copies the state variables and advective sources into the integration type. Since we onlyactually integrate (ρXk), (ρe), (ρE), the terms corresponding to density and momentum arecarried in an auxillary array (indexed through the rpar mechanism).

2. Call the main integration routine to advance the inputs state through the desired time interval,producing the new, output state.

3. Convert back from the internal representation (e.g., a bs t) to the sdc t type.

9.4.2 Righthand side wrapper

The manipulation of the righthand side is considerably more complex now. Each network onlyprovides the change in molar fractions and internal energy, but we need to convert these to the

note: molarfractions

conservative system we are integrating, including the advective terms.

9.4—Interfaces 53

1. Convert to a burn t type, for instance via bs to burn:

(a) call fill unevolved variables to update the density and momentum. Since thesedon’t depend on reactions, this is a simple algebraic update based on the piecewise-constant-in-time advective term:

ρ(t) = ρn + t · [A(ρ)]n+1/2 (9.4)

(ρU)(t) = (ρU)n + t · [A(ρU)]n+1/2 (9.5)

where here we assume that we are integrating in the ODE system starting with t = 0.

(b) compute the specific internal energy, e, from either the total minus kinetic energy orinternal energy carried by the integrator (depending on the value of T from eden).

(c) get the temperature from the equation of state

(d) convert to a burn t type, for instance via eos to burn:

2. Call the network’s actual rhs routine to get just the reaction sources to the update. Inparticular, this returns the change in molar fractions, Yk and the nuclear energy release, S.

3. Convert back to the integrator’s internal representation (e.g., a bs t, via rhs to bs)

(a) call fill unevolved variablesis this redundant?

(b) fill the ydot array in the integrator type (e.g., bs t) with the advective sources thatoriginally came into the intergrator through the sdc t.

(c) Add the reacting terms. This is done as:

yρXk= [A (ρXk)]

n+1/2 + ρAkYk (9.6)

yρe = [A (ρe)]n+1/2 + ρS (9.7)

yρE = [A (ρE)]n+1/2 + ρS (9.8)

References

[1] A. S. Almgren, J. B. Bell, A. Nonaka, and M. Zingale. Low Mach Number Modeling of TypeIa Supernovae. III. Reactions. ApJ, 684:449–470, September 2008.

[2] P. N. Brown, G. D. Byrne, and A. C. Hindmarsh. VODE: A variable coefficient ode solver.SIAM J. Sci. Stat. Comput., 10:1038–1051, 1989.

[3] D. A. Chamulak, E. F. Brown, F. X. Timmes, and K. Dupczak. The Reduction of the ElectronAbundance during the Pre-explosion Simmering in White Dwarf Supernovae. ApJ, 677:160–168, April 2008.

[4] Richard H. Cyburt, A. Matthew Amthor, Ryan Ferguson, Zach Meisel, Karl Smith, ScottWarren, Alexander Heger, R. D. Hoffman, Thomas Rauscher, Alexander Sakharuk, HendrikSchatz, F. K. Thielemann, and Michael Wiescher. The jina reaclib database: Its recent updatesand impact on type-i x-ray bursts. ApJS, 189(1):240, 2010.

[5] B. Fryxell, K. Olson, P. Ricker, F. X. Timmes, M. Zingale, D. Q. Lamb, P. MacNeice, R. Ros-ner, J. W. Truran, and H. Tufo. FLASH: An Adaptive Mesh Hydrodynamics Code for ModelingAstrophysical Thermonuclear Flashes. ApJS, 131:273–334, November 2000.

[6] C. M. Malone, M. Zingale, A. Nonaka, A. S. Almgren, and J. B. Bell. MultidimensionalModeling of Type I X-Ray Bursts. II. Two-dimensional Convection in a Mixed H/He Accretor.ApJ, 788:115, June 2014.

[7] W. H. Press, S. A. Teukolsky, W. T. Vetterling, and B. P. Flannery. Numerical recipes inFORTRAN. The art of scientific computing. 1992.

[8] C. Raskin, E. Scannapieco, G. Rockefeller, C. Fryer, S. Diehl, and F. X. Timmes. 56Ni Pro-duction in Double-degenerate White Dwarf Collisions. ApJ, 724:111–125, November 2010.

[9] F. X. Timmes and D. Arnett. The Accuracy, Consistency, and Speed of Five Equations ofState for Stellar Hydrodynamics. ApJS, 125:277–294, November 1999.

55

56 REFERENCES

[10] F. X. Timmes and F. D. Swesty. The Accuracy, Consistency, and Speed of an Electron-Positron Equation of State Based on Table Interpolation of the Helmholtz Free Energy. ApJS,126:501–516, February 2000.

[11] R. K. Wallace and S. E. Woosley. Explosive hydrogen burning. ApJS, 45:389–420, February1981.

[12] M. Zingale, A. S. Almgren, J. B. Bell, A. Nonaka, and S. E. Woosley. Low Mach NumberModeling of Type IA Supernovae. IV. White Dwarf Convection. ApJ, 704:196–210, October2009.

[13] M. Zingale, C. M. Malone, A. Nonaka, A. S. Almgren, and J. B. Bell. Comparisons of Two-and Three-Dimensional Convection in Type I X-Ray Bursts. ApJ, 807:60, July 2015.

[14] M. Zingale, A. Nonaka, A. S. Almgren, J. B. Bell, C. M. Malone, and S. E. Woosley. TheConvective Phase Preceding Type Ia Supernovae. ApJ, 740:8, October 2011.

Microphysics - bender.astro.sunysb.edu

Documents

Transcript of Microphysics - bender.astro.sunysb.edu