include/pops/numerics/elliptic/interface/elliptic_interface.hpp File ReferenceΒΆ
|
adc_cpp 0.3.0
Model-free C++23 core for coupled hyperbolic-elliptic systems on adaptive (AMR) meshes, with MPI and GPU (Kokkos) backends
|
C++20 concepts NAMING the common contracts of the elliptic stage: EllipticOperator (operator role), LinearSolver (iterative subset), FieldPostProcessor (field derivation). More...
#include <pops/core/foundation/types.hpp>#include <pops/mesh/geometry/geometry.hpp>#include <pops/mesh/storage/multifab.hpp>#include <pops/mesh/boundary/physical_bc.hpp>#include <pops/numerics/elliptic/interface/elliptic_problem.hpp>#include <pops/numerics/elliptic/interface/elliptic_solver.hpp>#include <concepts>
Include dependency graph for elliptic_interface.hpp:Go to the source code of this file.
Namespaces | |
| namespace | pops |
Concepts | |
| concept | pops::EllipticOperator |
| concept | pops::LinearSolver |
| concept | pops::FieldPostProcessor |
Detailed Description
C++20 concepts NAMING the common contracts of the elliptic stage: EllipticOperator (operator role), LinearSolver (iterative subset), FieldPostProcessor (field derivation).
Layer: include/pops/numerics/elliptic/interface. Role: PURELY DESCRIPTIVE header (host metaprogramming). It formalizes as concepts the contracts ALREADY coded by the existing elliptic classes and PROVES it via static_assert. No floating-point logic, no existing class touched: the device-validated elliptic stack stays bit-identical. Reuses (does not redefine) the EllipticSolver concept from elliptic_solver.hpp. Contract: three concepts – EllipticOperator (geom/bc + stencil coefficient pointers for a matvec consistent with the MG residual, modeled by GeometricMG), LinearSolver (EllipticSolver + a tolerance variant solve(rel_tol, max_iters) with a non-void return), FieldPostProcessor (callable deriving the field from phi, signature of field_postprocess).
Invariants:
- the concepts are COMPILE-TIME predicates, with no device impact (neither kernel nor extended lambda);
- LinearSolver is DELIBERATELY separated from EllipticSolver: the DIRECT solvers (PoissonFFTSolver, DistributedFFTSolver, PolarPoissonSolver) model EllipticSolver but NOT LinearSolver (no notion of iterative tolerance), and that is correct;
- none of the elliptic classes is modified to satisfy a concept (deliberate refusal).
Generated by