| ... | ... | @@ -1638,11 +1638,11 @@ structure elements `V` must be defined by the user: | 
| 
 | 
 | 
| `n2`            | number of sampling points in log *ε*                                                   |
 | 
| 
 | 
 | 
| `u1_lo`,`u1_up` | lower,upper value of log 𝜚-range                                                       |
 | 
| 
 | 
 | 
| `u2_lo`,`u2_up` | lower,upper value of log *ε*-range                                                     |
 | 
| 
 | 
 | 
| `dt2[i][j]`     | 2D array for sampling data {(log *p*)<sub>*i**j*</sub>} ({(log *T*)<sub>*i**j*</sub>}) |
 | 
| 
 | 
 | 
| `dt2[i][j]`     | 2D array for sampling data {(log *p*)<sub>*ij*</sub>} ({(log *T*)<sub>*ij*</sub>}) |
 | 
| 
 | 
 | 
 | 
| 
 | 
 | 
The subsequent example taken from testproblem
 | 
| 
 | 
 | 
`/nirvana/testproblem/MHD/problem1B` provides sampling data for
 | 
| 
 | 
 | 
tabulation of the caloric EOS *p* = (*γ* − 1)*ε*.
 | 
| 
 | 
 | 
tabulation of the caloric EOS *p*=(*γ* − 1)*ε*.
 | 
| 
 | 
 | 
 | 
| 
 | 
 | 
    UTAB eosTabPressureUser(void)
 | 
| 
 | 
 | 
    /**
 | 
| ... | ... | @@ -1709,7 +1709,7 @@ First, the number of sampling points `ut.n1` in (log 𝜚)-direction and | 
| 
 | 
 | 
`ut.n2` in (log *ε*)-direction are set followed by the ranges
 | 
| 
 | 
 | 
\[`ut.u1_lo`,`ut.u1_up`\] for log 𝜚 and \[`ut.u2_lo`,`ut.u2_up`\] for
 | 
| 
 | 
 | 
log *ε*, respectively. Then, the 2D array `ut.dt2` is allocated and
 | 
| 
 | 
 | 
sampling data {(log *p*)<sub>*i**j*</sub>} is assigned. The returned
 | 
| 
 | 
 | 
sampling data {(log *p*)<sub>*ij*</sub>} is assigned. The returned
 | 
| 
 | 
 | 
`ut` is used by the calling function to finally create the public
 | 
| 
 | 
 | 
look-up table `_TABLP`. A corresponding user definition for log *T* in
 | 
| 
 | 
 | 
`eosTabTemperatureUser.c` provides the input for the public look-up
 | 
| ... | ... | @@ -1742,7 +1742,7 @@ coordinates of a testpoint (`x`,`y`,`z`): | 
| 
 | 
 | 
 | 
| 
 | 
 | 
The user must return the mesh refinement level (`level`) with which the
 | 
| 
 | 
 | 
vicinity of the given testpoint should be resolved with the limitation
 | 
| 
 | 
 | 
\|`l``e``v``e``l`\| ≤ `_``C``.``i``m``r` where code paramter `_C.imr` is
 | 
| 
 | 
 | 
\|`level`\| ≤ `_C.imr` where code paramter `_C.imr` is
 | 
| 
 | 
 | 
the maximum allowed initial mesh refinement level specified by the user
 | 
| 
 | 
 | 
in the parameter interface `nirvana.par` under the category
 | 
| 
 | 
 | 
`MESH REFINEMENT`. In practice, the user defines spatial domains in
 | 
| ... | ... | @@ -1750,7 +1750,7 @@ in the parameter interface `nirvana.par` under the category | 
| 
 | 
 | 
testpoint is contained and then returns the requested refinement level.
 | 
| 
 | 
 | 
The following code fragment illustrates the procedure for a spherical
 | 
| 
 | 
 | 
interface at radius 0.1 relative to the center
 | 
| 
 | 
 | 
(*x*, *y*, *z*) = (0.3, 0, 0) to be resolved with refinement level 4:
 | 
| 
 | 
 | 
(*x*, *y*, *z*)=(0.3, 0, 0) to be resolved with refinement level 4:
 | 
| 
 | 
 | 
 | 
| 
 | 
 | 
    int initDomainUser(double x, double y, double z)
 | 
| 
 | 
 | 
    /**
 | 
| ... | ... | @@ -1804,7 +1804,7 @@ situation, in the testproblem `/nirvana/testproblems/GRAVITY/problem1`. | 
| 
 | 
 | 
User-specified refined domains are normally subject to subsequent
 | 
| 
 | 
 | 
derefinement according to the standard refinement criteria. However, if
 | 
| 
 | 
 | 
the returned refinement level is given a negative sign
 | 
| 
 | 
 | 
(`l``e``v``e``l` < 0) it tells the calling function that the
 | 
| 
 | 
 | 
(`level` < 0) it tells the calling function that the
 | 
| 
 | 
 | 
user-specified domain should be regarded as statically refined. This
 | 
| 
 | 
 | 
implies that there is no subsequent derefinement of this domain during
 | 
| 
 | 
 | 
runtime.
 | 
| ... | ... | @@ -1820,10 +1820,10 @@ Function arguments are the coordinates of a testpoint (`x`,`y`,`z`): | 
| 
 | 
 | 
 | 
| 
 | 
 | 
The user must return the refinement control parameter `level`
 | 
| 
 | 
 | 
(initialized to 0) for the vicinity of the testpoint (`x`,`y`,`z`). A
 | 
| 
 | 
 | 
return value `l``e``v``e``l` = 0 has no effect on mesh refinement. A
 | 
| 
 | 
 | 
return value `l``e``v``e``l` =  − 1 prohibits mesh refinement. A return
 | 
| 
 | 
 | 
value `l``e``v``e``l` > 0 forces mesh refinement up to refinement
 | 
| 
 | 
 | 
level `level` with the limitation `l``e``v``e``l` ≤ `_``C``.``a``m``r`
 | 
| 
 | 
 | 
return value `level` = 0 has no effect on mesh refinement. A
 | 
| 
 | 
 | 
return value `level` =  − 1 prohibits mesh refinement. A return
 | 
| 
 | 
 | 
value `level` > 0 forces mesh refinement up to refinement
 | 
| 
 | 
 | 
level `level` with the limitation `level` ≤ `_C.amr`
 | 
| 
 | 
 | 
where code parameter `_C.amr` is the maximum allowed mesh refinement
 | 
| 
 | 
 | 
level specified by the user in the parameter interface `nirvana.par`
 | 
| 
 | 
 | 
under category `MESH REFINEMENT`. Like in the `initDomainUser.c`
 | 
| ... | ... |  |