| ... | ... | @@ -782,7 +782,7 @@ for the type of coordinate system. |
|
|
|
- `12` (`_C.testfields`)
|
|
|
|
|
|
|
|
- `_C.testfields`: number of testfield equations associated with
|
|
|
|
the code functionality TESTFIELDS.
|
|
|
|
the code functionality TESTFIELDS.
|
|
|
|
|
|
|
|
- `13` (`NN`, `NN`, `_C.energy_reactions`, `_C.mean_molecular_weight`,
|
|
|
|
`_C.mean_ionization`)
|
| ... | ... | @@ -944,7 +944,7 @@ divergence-free setup: |
|
|
|
\(1\) computation of cell-face-averaged magnetic field components via
|
|
|
|
exact integration of the analytical expressions. The so discretized
|
|
|
|
field is per se cell-wise divergence-free. For a grid cell
|
|
|
|
(`ix`,`iy`,`iz`) on superblock `g` this means
|
|
|
|
(`ix`,`iy`,`iz`) on superblock `g` the discritized components read
|
|
|
|
|
|
|
|
|
|
|
|
The numerical expressions for the cell face contents are:
|
| ... | ... | @@ -1289,7 +1289,7 @@ physics guide |
|
|
|
non-periodic BC. The combination of periodic BC at one domain boundary
|
|
|
|
with non-periodic BC at another domain boundary is not supported.*
|
|
|
|
|
|
|
|
### User-defined coefficients for dissipative processes
|
|
|
|
## User-defined coefficients for dissipative processes
|
|
|
|
|
|
|
|
The modules `viscosityCoeffUser.c`, `conductionCoeffUser.c` and
|
|
|
|
`diffusionCoeffUser.c` serve as templates for a user-defined coefficient
|
| ... | ... | @@ -1423,7 +1423,7 @@ User-defined Ohmic diffusion is enabled by appropriate choice in the |
|
|
|
parameter interface `nirvana.par` under the category
|
|
|
|
`PHYSICS SPECIFICATIONS` (code parameter: `_C.diffusion`).
|
|
|
|
|
|
|
|
### User-defined coefficient for ambipolar diffusion
|
|
|
|
## User-defined coefficient for ambipolar diffusion
|
|
|
|
|
|
|
|
The module `APdiffusionCoeffUser.c` serves as template for a
|
|
|
|
user-defined ambipolar diffusion coefficient. Ambipolar diffusion enters
|
| ... | ... | @@ -1467,11 +1467,11 @@ User-defined ambipolar diffusion is enabled by appropriate choice in the |
|
|
|
parameter interface `nirvana.par` under the category
|
|
|
|
`PHYSICS SPECIFICATIONS` (code parameter: `_C.APdiffusion`).
|
|
|
|
|
|
|
|
### User-defined body force
|
|
|
|
## User-defined body force
|
|
|
|
|
|
|
|
The module `forceUser.c` serves as template for coding a user-defined
|
|
|
|
*specific* body force **f** (force per mass in units
|
|
|
|
*N* ⋅ *k**g*<sup> − 1</sup>). The body force then enters the momentum
|
|
|
|
N⋅kg<sup>−1</sup>). The body force then enters the momentum
|
|
|
|
equation and energy equation as source term.
|
|
|
|
|
|
|
|
In the call of `forceUser()` the function arguments are the superblock
|
| ... | ... | @@ -1506,17 +1506,17 @@ The body force is enabled by specification in the parameter interface |
|
|
|
`nirvana.par` under the category `PHYSICS SPECIFICATIONS` (code
|
|
|
|
parameter: `_C.force`).
|
|
|
|
|
|
|
|
### User-defined cooling/heating function
|
|
|
|
## User-defined cooling/heating function
|
|
|
|
|
|
|
|
The modules `sourceCoolingUser.c` and `sourceHeatingUser.c` serve as
|
|
|
|
templates for coding a user-defined cooling function,
|
|
|
|
*L*<sub>*c**o**o**l*</sub> ≤ 0, and heating function,
|
|
|
|
*L*<sub>*h**e**a**t*</sub> ≥ 0, respectively. Both functions are allowed
|
|
|
|
*L*<sub>*cool*</sub> ≤ 0, and heating function,
|
|
|
|
*L*<sub>*heat*</sub> ≥ 0, respectively. Both functions are allowed
|
|
|
|
to depend on temperature *T* and density 𝜚. The net heatloss, i.e. the
|
|
|
|
sum
|
|
|
|
*L*<sub>*c**o**o**l*</sub>(*T*, 𝜚) + *L*<sub>*h**e**a**t*</sub>(*T*, 𝜚)
|
|
|
|
*L*<sub>*cool*</sub>(*T*, 𝜚) + *L*<sub>*heat*</sub>(*T*, 𝜚)
|
|
|
|
of both functions, enters as a source term in the energy equation.
|
|
|
|
*L*<sub>*c**o**o**l*</sub> and *L*<sub>*h**e**a**t*</sub> are measured
|
|
|
|
*L*<sub>*cool*</sub> and *L*<sub>*heat*</sub> are measured
|
|
|
|
in units *J* ⋅ *s*<sup> − 1</sup> ⋅ *m*<sup> − 3</sup>.
|
|
|
|
|
|
|
|
In the call of `sourceCoolingUser()` (`sourceHeatingUser()`) the
|
| ... | ... | @@ -1529,12 +1529,12 @@ the pointer `deriv` to the derivatives flag and the 2-element vector |
|
|
|
f=sourceHeatingUser(T,rho,deriv,dfh);
|
|
|
|
|
|
|
|
The user must define the return value
|
|
|
|
`f` = *L*<sub>*c**o**o**l*</sub>(`T``,` `r``h``o`)
|
|
|
|
(*L*<sub>*h**e**a**t*</sub>(`T``,` `r``h``o`)) in `sourceCoolingUser.c`
|
|
|
|
`f` = *L*<sub>*cool*</sub>(`T``,` `rho`)
|
|
|
|
(*L*<sub>*heat*</sub>(`T``,` `rho`)) in `sourceCoolingUser.c`
|
|
|
|
(`sourceHeatingUser.c`). The `deriv`-flag is thought to indicate the
|
|
|
|
calling function whether a user provides the derivatives of
|
|
|
|
*L*<sub>*c**o**o**l*</sub>(*T*, 𝜚) and
|
|
|
|
*L*<sub>*h**e**a**t*</sub>(*T*, 𝜚) with respect to *T* and 𝜚 himself.
|
|
|
|
*L*<sub>*cool*</sub>(*T*, 𝜚) and
|
|
|
|
*L*<sub>*heat*</sub>(*T*, 𝜚) with respect to *T* and 𝜚 himself.
|
|
|
|
The `deriv`-flag is preset to `NO` when entering the code function. If
|
|
|
|
the user sets
|
|
|
|
|
| ... | ... | @@ -1542,9 +1542,9 @@ the user sets |
|
|
|
|
|
|
|
the derivatives must be stored by the user in the 2-element vector `dfc`
|
|
|
|
(`dfh`) with `dfc[0]` (`dfh[0]`) storing the derivative
|
|
|
|
∂*L*<sub>*c**o**o**l*</sub>/∂*T* (∂*L*<sub>*h**e**a**t*</sub>/∂*T*) and
|
|
|
|
∂*L*<sub>*cool*</sub>/∂*T* (∂*L*<sub>*heat*</sub>/∂*T*) and
|
|
|
|
`dfc[1]` (`dfh[1]`) storing the derivative
|
|
|
|
∂*L*<sub>*c**o**o**l*</sub>/∂𝜚 (∂*L*<sub>*h**e**a**t*</sub>/∂𝜚).
|
|
|
|
∂*L*<sub>*cool*</sub>/∂𝜚 (∂*L*<sub>*heat*</sub>/∂𝜚).
|
|
|
|
Otherwise derivatives are automatically computed by a finite difference
|
|
|
|
approximation.
|
|
|
|
|
| ... | ... | @@ -1559,7 +1559,7 @@ User-defined cooling/heating is enabled by appropriate choice in the |
|
|
|
parameter interface `nirvana.par` under the category
|
|
|
|
`PHYSICS SPECIFICATIONS` (code parameter: `_C.heatloss`).
|
|
|
|
|
|
|
|
### User-defined equation of state
|
|
|
|
## User-defined equation of state
|
|
|
|
|
|
|
|
#### Analytic EOS
|
|
|
|
|
| ... | ... | @@ -1724,7 +1724,7 @@ A tabulated EOS is enabled by appropriate choice in the parameter |
|
|
|
interface `nirvana.par` under category `PHYSICS SPECIFICATIONS` (code
|
|
|
|
paramter: `_C.eos`).
|
|
|
|
|
|
|
|
### User-defined initial/restricted mesh refinement
|
|
|
|
## User-defined initial/restricted mesh refinement
|
|
|
|
|
|
|
|
For certain problems it may be advantageous to start a simulation with a
|
|
|
|
pre-refined mesh in some parts of the computational domain or to retrict
|
| ... | ... | @@ -1835,7 +1835,7 @@ the requested refinement control parameter. |
|
|
|
An example can be found in the testproblem
|
|
|
|
`/nirvana/testproblems/GRAVITY/problem3`.
|
|
|
|
|
|
|
|
### Specification of NCCM parameters
|
|
|
|
## Specification of NCCM parameters
|
|
|
|
|
|
|
|
The parameter file `NCCM.par` serves as user interface to the
|
|
|
|
multi-species framework/NCCM. `NCCM.par` is grouped into the category
|
| ... | ... | @@ -1987,7 +1987,7 @@ A thermal process is activated (deactivated) by specifying the value Y |
|
|
|
(N). Every text in a line following the ’`>`’-character is ignored by
|
|
|
|
the parser and serves for comments.
|
|
|
|
|
|
|
|
### User-controllable macros
|
|
|
|
## User-controllable macros
|
|
|
|
|
|
|
|
Besides the parameters collected in the user interfaces `nirvana.par`
|
|
|
|
and `NCCM.par` there are a number of further parameters which can be
|
| ... | ... | |
