Public Types | Public Member Functions | Static Public Attributes | List of all members
elliptic::BoundaryConditions::BoundaryCondition< Dim, Registrars > Class Template Reference

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
BoundaryConditionoperator= (const BoundaryCondition &)=default
BoundaryConditionoperator= (BoundaryCondition &&)=default
- Public Member Functions inherited from domain::BoundaryConditions::BoundaryCondition
 BoundaryCondition (BoundaryCondition &&) noexcept=default
BoundaryConditionoperator= (BoundaryCondition &&) noexcept=default
 BoundaryCondition (const BoundaryCondition &)=default
BoundaryConditionoperator= (const BoundaryCondition &)=default
 BoundaryCondition (CkMigrateMessage *const msg) noexcept
 WRAPPED_PUPable_abstract (BoundaryCondition)
virtual auto get_clone () const noexcept -> std::unique_ptr< BoundaryCondition >=0

Static Public Attributes

static constexpr size_t volume_dim = Dim

Detailed Description

template<size_t Dim, typename Registrars>
class elliptic::BoundaryConditions::BoundaryCondition< Dim, Registrars >

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 factory-created from input-file 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. Robin-type boundary conditions).

Note that almost all boundary conditions are actually nonlinear because even those that depend only linearly on the dynamic fields typically contribute non-zero 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 non-zero 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 fixed-source 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 compile-time interface:

The documentation for this class was generated from the following file:
T apply(T... args)
Tensor< T, Symmetry<>, index_list<> > Scalar
Definition: TypeAliases.hpp:21
Require a pointer to not be a nullptr
Definition: ReadSpecThirdOrderPiecewisePolynomial.hpp:13