SpECTRE
v2021.12.06

Base class for boundary conditions for elliptic systems. More...
#include <BoundaryCondition.hpp>
Public Types  
using  registrars = Registrars 
using  creatable_classes = Registration::registrants< registrars > 
Public Member Functions  
BoundaryCondition (const BoundaryCondition &)=default  
BoundaryCondition (BoundaryCondition &&)=default  
BoundaryCondition &  operator= (const BoundaryCondition &)=default 
BoundaryCondition &  operator= (BoundaryCondition &&)=default 
Public Member Functions inherited from domain::BoundaryConditions::BoundaryCondition  
BoundaryCondition (BoundaryCondition &&)=default  
BoundaryCondition &  operator= (BoundaryCondition &&)=default 
BoundaryCondition (const BoundaryCondition &)=default  
BoundaryCondition &  operator= (const BoundaryCondition &)=default 
BoundaryCondition (CkMigrateMessage *const msg)  
WRAPPED_PUPable_abstract (BoundaryCondition)  
virtual auto  get_clone () const > std::unique_ptr< BoundaryCondition >=0 
Static Public Attributes  
static constexpr size_t  volume_dim = Dim 
Base class for boundary conditions for elliptic systems.
Boundary conditions for elliptic systems derive from this abstract base class. This allows boundary conditions to be factorycreated from inputfile options. Specific systems may implement further abstract base classes that derive from this class and add additional requirements.
Each derived class represents one kind of boundary conditions. For example, one derived class might implement homogeneous (zero) Dirichlet or Neumann boundary conditions, another might implement Dirichlet fields procured from an analytic solution, and yet another might set the boundary fields as a function of the dynamic variables on the domain boundary (e.g. Robintype boundary conditions).
Note that almost all boundary conditions are actually nonlinear because even those that depend only linearly on the dynamic fields typically contribute nonzero field values. For example, a standard Dirichlet boundary condition \(u(x=0)=u_0\) is nonlinear for any \(u_0\neq 0\). Boundary conditions for linear systems may have exactly this nonlinearity (a constant nonzero contribution) but must depend at most linearly on the dynamic fields. Boundary conditions for nonlinear systems may have any nonlinearity. Either must implement their linearization as a separate function (see below). For linear systems the nonlinear (constant) contribution is typically added to the fixedsource part of the discretized equations and the linearized boundary conditions are being employed throughout the solve so the discretized operator remains linear. For nonlinear systems we typically solve the linearized equations repeatedly for a correction quantity, so we apply the linearized boundary conditions when solving for the correction quantity and apply the nonlinear boundary conditions when dealing with the nonlinear fields that are being corrected (see e.g. NonlinearSolver::newton_raphson::NewtonRaphson
).
Derived classes are expected to implement the following compiletime interface:
argument_tags
, volume_tags
, argument_tags_linearized
and volume_tags_linearized
. Those aliases list the tags required for computing nonlinear and linearized boundary conditions, respectively. The tags are always taken to represent quantities on the interior side of the domain boundary, i.e. whenever normal vectors are involved they point out of the computational domain. The volume_tags
list the subset of the argument_tags
that are not evaluated on the boundary but taken from the element directly.They have apply
and apply_linearized
member functions that take these arguments (in this order):
For firstorder systems that involve auxiliary variables, only the nonauxiliary ("primal") variables are included in the lists above. For example, boundary conditions for a firstorder Poisson system might have an apply
function signature that looks like this:
The fields and normaldotfluxes passed to the apply
and apply_linearized
functions hold data which the implementations of the functions can use, and also serve as return variables. Modifying the fields means applying Dirichlettype boundary conditions and modifying the normaldotfluxes means applying Neumanntype boundary conditions. Just like the arguments evaluated on the boundary, the normaldotfluxes involve normal vectors that point out of the computation domain. Note that linearized boundary conditions, as well as nonlinear boundary conditions for linear systems, may only depend linearly on the field data, since these are the fields the linearization is performed for.