@@ -73,11 +74,13 @@ Note that in this second case the subdomain-specific tables must be initialized
The two approaches can be mixed and the subdomain-specific variables take priority on the whole-domain function.
The solver expects that the callbacks for materials have 4 parameters:
-`tag`: the current subdomain tag
-`x`, `y` and `z`: the current coordinates at which the material needs to be evaluated. Note that currently the materials are assumed to be piecewise constant and that the material is evaluated in the barycenter of the element.
### Volumetric sources
Current sources in volumes can be specified by providing a function that evaluates the current density field in a given subdomain. For example the following code defines a volumetric source in the subdomain with tag `4`:
```
function J_source(tag, x, y, z, t)
local Ex = 0
...
...
@@ -93,12 +96,14 @@ sources[4] = J_source
Boundary conditions are specified for each surface with tag `tag` via the table `bndconds`. If a surface does not have an entry in `bndconds` it is assumed to be PEC.
For example, to specify an impedance boundary condition on the surface with tag `4`, one proceeds as following:
```
bndconds[4] = {}
bndconds[4].kind = "impedance"
```
There are also nonhomogeneous boundary conditions, as the plane wave condition. A plane wave described in terms of electric field is configured as
-`"impedance"`: Impedance condition, actual impedance value is computed using the material parameters of the adjacent element.
The available nonhomogeneous conditions are:
-`"E_field"`: electric field. Not implemented yet.
-`"H_field"`: magnetic field. Not implemented yet.
-`"surface_current"`: surface current.
...
...
@@ -125,7 +132,9 @@ The available nonhomogeneous conditions are:
The interface conditions follow the exact same logic as boundary conditions, except that they are applied on internal interfaces. The table in this case is `ifaceconds`.
Currently, only a surface current condition is available:
-`"surface_current"`: surface current.
### Callable functions
None.
...
...
@@ -144,10 +153,12 @@ None.
### Debug and validation
The solver has some facilities to allow validation and comparison with analytical solutions. Those facilities are accessed via the `debug` table. In the current implementation the `debug` table is undefined by default, so it must be initialized explicitly in the configuration with a statement `debug = {}`. Possible members of the `debug` table are:
-`analytical_solution`: a function `f(tag, x, y, z, t)` defining the analytical solution of the problem. If defined, it can be used to compare the numerical solution with the analytical solution during the timestepping. The function has to return 6 values, namely `Ex`, `Ey`, `Ez`, `Hx`, `Hy` and `Hz`.
-`dump_cell_ranks` (bool): if true, and if the solver has MPI support compiled in, add to the Silo output a variable named `cell_ranks` showing the cell-to-rank mapping.
The analytical solution is compared with the current numerical solution via the `compute_error()` function (available only on CPU and CPU/MPI for now). For example (see previous section for the description of `on_timestep`)
```
function on_timestep(ts)
e = compute_error()
...
...
@@ -157,6 +168,7 @@ computes the error at each timestep and places it in the variable `e`. This vari
### Postprocessing
The export of the fields E, H and J to Silo is controlled using the appropriate sections in the `postpro` table.
-`postpro["E"].silo_mode` controls the export of the electric field E. Possible values are `"none"` (no export), `"nodal"` (export as a Silo nodal variable) and `"zonal"` (export as a Silo zonal variable)
-`postpro["H"].silo_mode` controls the export of the magnetic field H. Possible values are `"none"` (no export), `"nodal"` (export as a Silo nodal variable) and `"zonal"` (export as a Silo zonal variable)
-`postpro["J"].silo_mode` controls the export of the current density field J. Possible values are `"none"` (no export), `"nodal"` (export as a Silo nodal variable) and `"zonal"` (export as a Silo zonal variable)
...
...
@@ -168,7 +180,9 @@ Zonal variables represent the field as a piecewise-constant field evaluated in t
Default mode is `"nodal"`.
Misc functions:
-`compute_energy()`: this functions provides the energy stored in the six fields at the current time (available only on CPU and CPU/MPI for now). For example (see previous section for the description of `on_timestep`)
