3-NIRVANA-user-guide/3.2-User-interfaces.md

@@ -1620,10 +1620,10 @@ logarithm of mass density 𝜚 and the logarithm of thermal energy density
 generated by cubic interpolation from user-specified sampling data. The
 sampling data {(log *p*)<sub>*ij*</sub>}
 ({(log *T*)<sub>*ij*</sub>}) on the grid
-{(log𝜚)<sub>*i*</sub>} × {(log*ε*)<sub>*j*</sub>} has to be defined by
+{(log 𝜚)<sub>*i*</sub>} × {(log *ε*)<sub>*j*</sub>} has to be defined by
 the user in the interface `eosTabPressureUser.c`
 (`eosTabTemperatureUser.c`). The discretizations in log𝜚-space and
-log*ε*-space, {(log𝜚)<sub>*i*</sub>; i=0,`n1`-1} and {(log *ε*)<sub>*j*</sub>; j=0,`n2`-1}, must be equidistant
+log *ε*-space, {(log 𝜚)<sub>*i*</sub>; i=0,`n1`-1} and {(log *ε*)<sub>*j*</sub>; j=0,`n2`-1}, must be equidistant
 where `n1` and `n2` are the number of sampling points.
 
 Actually, in `eosTabPressureUser()` (`eosTabTemperatureUser()`) the user
@@ -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` &lt; 0) it tells the calling function that the
+(`level` &lt; 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` &gt; 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` &gt; 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`