A system of elliptic equations in first-order "flux" formulation. More...

#include <FirstOrderSystem.hpp>

Classes
struct	test

Detailed Description

A system of elliptic equations in first-order "flux" formulation.

Classes conforming to this protocol represent a set of elliptic partial differential equations in first-order "flux" formulation:

\begin{equation}-\partial_i F^i_\alpha + S_\alpha = f_\alpha(x) \end{equation}

in terms of fluxes \(F_\alpha^i\), sources \(S_\alpha\) and fixed-sources \(f_\alpha(x)\) [73]. It resembles closely formulations of hyperbolic conservation laws but allows the fluxes \(F_\alpha^i\) to be higher-rank tensor fields. The fluxes and sources are functionals of the system variables \(u_\alpha(x)\) and their derivatives. The fixed-sources \(f_\alpha(x)\) are independent of the system variables. See the Poisson::FirstOrderSystem and the Elasticity::FirstOrderSystem for examples.

Note that this formulation has been simplified since [73] : We assume that the fluxes are linear in the fields and their derivatives and removed the notion of "auxiliary variables" from the formulation altogether. In the language of [73] we always just choose the partial derivatives of the fields as auxiliary variables.

Conforming classes must have these static member variables:

size_t volume_dim: The number of spatial dimensions.

Conforming classes must have these type aliases:

primal_fields: A list of tags representing the primal fields. These are the fields we solve for, e.g. \(u\) for a Poisson equation. (we may rename this to just "fields" since we removed the notion of "auxiliary fields")
primal_fluxes: A list of tags representing the primal fluxes \(F_\alpha^i\). These are typically some linear combination of the derivatives of the system fields with raised indices, e.g. \(v^i = g^{ij} \partial_j u\) for a curved-space Poisson equation on a background metric \(g_{ij}\). They must have an upper-spatial first index, because their divergence defines the elliptic equation.
background_fields: A list of tags representing the variable-independent background fields in the equations. Examples are a background metric, associated fixed geometry quantities such as Christoffel symbols or the Ricci scalar, or any other fixed field that determines the problem to be solved such as matter sources in the Einstein constraint equations.
inv_metric_tag: The tag that defines the background geometry, i.e. the the geometry that the elliptic equations are formulated on. This is the metric responsible for normalizing one-forms, such as face normals.
fluxes_computer: A class that defines the fluxes \(F_\alpha^i\). Must have an argument_tags type alias and an apply function that takes these arguments in this order:
1. The primal_fluxes as not-null pointer
2. The argument_tags
3. If is_discontinuous is true (see below): const ElementId<Dim>& element_id
4. The primal_fields
5. The partial derivatives of the primal_fields
The function can assume the output buffers are already correctly sized, but no guarantee is made on the values that the buffers hold at input.

The fluxes_computer must also have an apply function overload that is evaluated on faces of DG elements. It computes the same fluxes \(F_\alpha^i\), but with the field derivatives replaced by the the face normal times the fields, and with the non-principal (non-derivative) terms set to zero. Having this separate function is an optimization to take advantage of the face normal remaining constant throughout the solve, so it can be "baked in" to the flux. The function takes these arguments in this order:
1. The primal_fluxes as not-null pointer
2. The argument_tags
3. If is_discontinuous is true (see below): const ElementId<Dim>& element_id
4. The const tnsr::i<DataVector, Dim>& face_normal ( \(n_i\))
5. The const tnsr::I<DataVector, Dim>& face_normal_vector ( \(n^i\))
6. The primal_fields
The fluxes_computer class must also have the following additional type aliases and static member variables:
- volume_tags: the subset of argument_tags that will be retrieved directly from the DataBox, instead of retrieving it from the face of an element, when fluxes are applied on a face.
- const_global_cache_tags: the subset of argument_tags that can be retrieved from any element's DataBox, because they are stored in the global cache.
- bool is_trivial: a boolean indicating whether the fluxes are simply the spatial metric, as is the case for the Poisson equation. Some computations can be skipped in this case.
- bool is_discontinuous: a boolean indicating whether the fluxes are potentially discontinuous across element boundaries. This is true for systems where the equations on both sides of the boundary are different, e.g. elasticity with different materials on either side of the boundary. An additional element_id argument is passed to the apply functions in this case, which identifies on which side of an element boundary the fluxes are being evaluated.
sources_computer: A class that defines the sources \(S_\alpha\). Must have an argument_tags type alias and an apply function that adds the sources to the equations. It takes these arguments in this order:
1. The types of the primal_fields as not-null pointer. These are the primal equations.
2. The argument_tags
3. The primal_fields
4. The partial derivatives of the primal_fields
5. The primal_fluxes
The function is expected to add the sources \(S_\alpha\) to the output buffers. It must also have the following alias:
- const_global_cache_tags: the subset of argument_tags that can be retrieved from any element's DataBox, because they are stored in the global cache.
The sources_computer may also be void, in which case \(S_\alpha=0\).
boundary_conditions_base: A base class representing the supported boundary conditions. Boundary conditions can be factory-created from this base class. Currently this should be a specialization of elliptic::BoundaryConditions::BoundaryCondition.
modify_boundary_data (optional, can be void): A class that can modify boundary data received from a neighboring element, e.g. to transform from one variable to another across element boundaries. This can be used to solve for different variables in some regions of the domain to absorb singularities. For example, when solving \(-\Delta u = f\) we could define \(u=u_R + u_P\) in some region of the domain with a known (often singular) field \(u_P\) and solve only for the regular field \(u_R\) in this region. So, when receiving boundary data from outside this region, we subtract \(u_P\), and when receiving boundary data from inside this region, we add \(u_P\). We also add \(\Delta u_P\) to the volume fixed sources \(f\) inside the regularized region.

The modify_boundary_data must have an argument_tags type alias and an apply function that takes these arguments in this order:
1. The primal fields and the normal-dot-fluxes on the mortar as not-null pointer. These hold the received data from the neighbor and can be modified. Note: the normal-dot-fluxes have been computed with the neighbor's normal, so from the perspective of the receiving element they are \(-n_i F^i\) where \(n_i\) is the face normal of the receiving element.
2. The const DirectionalId<Dim>& mortar_id identifying the mortar.
3. The argument_tags.
Currently, modification made by this function must not depend on the variables, meaning that the modification can only be adding or subtracting a precomputed field. This is a simplification so the linearized operator is not modified at all and can be relaxed if needed (then we also need modify_boundary_data_linearized).

The documentation for this struct was generated from the following file:

src/Elliptic/Protocols/FirstOrderSystem.hpp