Authoritative STATIC capability facts of the built _pops module (Spec 5 sec.13.12 / sec.13.12.1, criteria #36/#37). More...

This graph shows which files directly or indirectly include this file:

Classes
struct	pops::ModuleCapabilities
	The STATIC transport capabilities the built _pops module provides (Spec 5 sec.13.12). More...

Namespaces
namespace	pops

namespace	pops::detail

Enumerations
enum class	pops::CapabilityTarget { pops::kModule , pops::kProduction , pops::kAot }
	The lowering route whose static capabilities are queried. More...

Functions
ModuleCapabilities	pops::module_capabilities (CapabilityTarget target=CapabilityTarget::kModule)
	The module's STATIC capability facts for a given lowering route `target` (Spec 5 sec.13.12 / #36).

Variables
constexpr int	pops::kAbiVersion = 1
	Discrete, monotonic ABI revision of the module capability contract.

constexpr bool	pops::detail::kHasGpuBackend
	True iff this translation unit is compiled for a real GPU device backend.

constexpr bool	pops::detail::kHasMpi

Detailed Description

Authoritative STATIC capability facts of the built _pops module (Spec 5 sec.13.12 / sec.13.12.1, criteria #36/#37).

MOTIVATION. pops._capabilities.inspect_capabilities walks the inert Python descriptor catalog; that walk is "Python-derived, not authoritative" (Spec 5 sec.13.12). The transport capabilities a module actually provides – which backend it was compiled with, whether MPI / GPU is real, whether the route carries a stride, named aux fields, a partial IMEX mask – are decided by the C++ build, not by Python. This header sources those facts from the SAME compile-time tokens the module attrs already expose (POPS_HAS_KOKKOS / POPS_HAS_MPI in init_core.cpp) so the Python read side can cross-check its descriptor walk against the C++ truth and FAIL LOUD on a disagreement.

HONESTY (non-negotiable, Spec 5 sec.13.12). A capability is reported TRUE only when a C++ path backs it. supports_partial_imex_mask is FALSE: a tree-wide grep finds NO partial-IMEX-mask code path, so claiming it would be a lie. supports_gpu is TRUE only under Kokkos AND a real device backend token (CUDA/HIP); a Kokkos-Serial / OpenMP CPU build reports FALSE. supports_stride is route-dependent (the production / native route carries a stride; the AOT / prototype route hardcodes stride=1), so the facts are queried per target.

This is a pure free-function / POD header: no System state, no out-of-line definition (kept out of System::Impl on purpose, so the C++ MockImpl in tests/test_strang_splitting.cpp is untouched).

include/pops/runtime/module_capabilities.hpp File Reference¶

Classes

Namespaces

Enumerations

Functions

Variables

Detailed Description