BoundaryCondition.hpp
2 // See LICENSE.txt for details.
3
4 #pragma once
5
6 #include <cstddef>
7 #include <pup.h>
8
10 #include "Domain/BoundaryConditions/BoundaryCondition.hpp"
12 #include "Utilities/Registration.hpp"
13 #include "Utilities/TMPL.hpp"
14
15 namespace elliptic {
16 /// Boundary conditions for elliptic systems
17 namespace BoundaryConditions {
18
19 /*!
20  * \brief Base class for boundary conditions for elliptic systems
21  *
22  * Boundary conditions for elliptic systems derive from this abstract base
23  * class. This allows boundary conditions to be factory-created from input-file
24  * options. Specific systems may implement further abstract base classes that
26  *
27  * Each derived class represents one kind of boundary conditions. For example,
28  * one derived class might implement homogeneous (zero) Dirichlet or Neumann
29  * boundary conditions, another might implement Dirichlet fields procured from
30  * an analytic solution, and yet another might set the boundary fields as a
31  * function of the dynamic variables on the domain boundary (e.g. Robin-type
32  * boundary conditions).
33  *
34  * Note that almost all boundary conditions are actually nonlinear because even
35  * those that depend only linearly on the dynamic fields typically contribute
36  * non-zero field values. For example, a standard Dirichlet boundary condition
37  * \f$u(x=0)=u_0\f$ is nonlinear for any \f$u_0\neq 0\f$. Boundary conditions
38  * for linear systems may have exactly this nonlinearity (a constant non-zero
39  * contribution) but must depend at most linearly on the dynamic fields.
40  * Boundary conditions for nonlinear systems may have any nonlinearity. Either
41  * must implement their linearization as a separate function (see below). For
42  * linear systems the nonlinear (constant) contribution is typically added to
43  * the fixed-source part of the discretized equations and the linearized
44  * boundary conditions are being employed throughout the solve so the
45  * discretized operator remains linear. For nonlinear systems we typically solve
46  * the linearized equations repeatedly for a correction quantity, so we apply
47  * the linearized boundary conditions when solving for the correction quantity
48  * and apply the nonlinear boundary conditions when dealing with the nonlinear
49  * fields that are being corrected (see e.g.
50  * NonlinearSolver::newton_raphson::NewtonRaphson).
51  *
52  * Derived classes are expected to implement the following compile-time
53  * interface:
54  *
55  * - They are option-creatable.
56  * - They have type aliases argument_tags, volume_tags,
57  * argument_tags_linearized and volume_tags_linearized. Those aliases list
58  * the tags required for computing nonlinear and linearized boundary
59  * conditions, respectively. The tags are always taken to represent quantities
60  * on the _interior_ side of the domain boundary, i.e. whenever normal vectors
61  * are involved they point _out_ of the computational domain. The
62  * volume_tags list the subset of the argument_tags that are _not_
63  * evaluated on the boundary but taken from the element directly.
64  * - They have apply and apply_linearized member functions that take these
65  * arguments (in this order):
66  *
67  * 1. The dynamic fields as not-null pointers.
68  * 2. The normal-dot-fluxes corresponding to the dynamic fields as not-null
69  * pointers. These have the same types as the dynamic fields.
70  * 3. The types held by the argument tags.
71  *
72  * For first-order systems that involve auxiliary variables, only the
73  * non-auxiliary ("primal") variables are included in the lists above. For
74  * example, boundary conditions for a first-order Poisson system might have an
75  * apply function signature that looks like this:
76  *
77  * \snippet Elliptic/BoundaryConditions/Test_BoundaryCondition.cpp example_poisson_fields
78  *
79  * The fields and normal-dot-fluxes passed to the apply and apply_linearized
80  * functions hold data which the implementations of the functions can use, and
81  * also serve as return variables. Modifying the fields means applying
82  * Dirichlet-type boundary conditions and modifying the normal-dot-fluxes means
83  * applying Neumann-type boundary conditions. Just like the arguments evaluated
84  * on the boundary, the normal-dot-fluxes involve normal vectors that point
85  * _out_ of the computation domain. Note that linearized boundary conditions, as
86  * well as nonlinear boundary conditions for linear systems, may only depend
87  * linearly on the field data, since these are the fields the linearization is
88  * performed for.
89  */
90 template <size_t Dim, typename Registrars>
92  private:
94
95  public:
96  static constexpr size_t volume_dim = Dim;
97  using registrars = Registrars;
98
99  BoundaryCondition() = default;
100  BoundaryCondition(const BoundaryCondition&) = default;
102  BoundaryCondition& operator=(const BoundaryCondition&) = default;
103  BoundaryCondition& operator=(BoundaryCondition&&) = default;
104  ~BoundaryCondition() override = default;
105
106  /// \cond
107  explicit BoundaryCondition(CkMigrateMessage* m) noexcept : Base(m) {}
108  WRAPPED_PUPable_abstract(BoundaryCondition); // NOLINT
109  /// \endcond
110
111  using creatable_classes = Registration::registrants<registrars>;
112 };
113
114 } // namespace BoundaryConditions
115 } // namespace elliptic
CharmPupable.hpp
domain::BoundaryConditions::BoundaryCondition
Base class from which all system-specific base classes must inherit.
Definition: BoundaryCondition.hpp:18
DataBox.hpp
cstddef
elliptic::BoundaryConditions::BoundaryCondition
Base class for boundary conditions for elliptic systems.
Definition: BoundaryCondition.hpp:91
elliptic
Functionality related to solving elliptic partial differential equations.
Definition: InitializeAnalyticSolution.hpp:29
Registration::registrants
tmpl::transform< tmpl::remove_duplicates< RegistrarList >, detail::registrant< tmpl::pin< tmpl::remove_duplicates< RegistrarList > >, tmpl::_1 > > registrants
Transform a list of registrars into the list of associated registrants. This is usually used to defin...
Definition: Registration.hpp:65
TMPL.hpp