Extensions — taxonomy#
Ginkgo’s extensions/ tree holds optional integrations with third-party libraries. Each
extension is opt-in at build time via a CMake flag, and lives in its own namespace
under gko::ext. None of them are required by the core library; they exist so that
Ginkgo can plug into ecosystems where users already have data, executors, or solvers.
This page surveys the available extensions and points to their dedicated pages.
What lives in extensions/#
Extension |
Header |
Namespace |
Purpose |
|---|---|---|---|
Kokkos interop |
|
|
Wrap Kokkos execution spaces as Ginkgo executors and map Ginkgo containers to Kokkos |
cuDSS direct solver |
|
|
Sparse direct solver wrapper around NVIDIA’s cuDSS library. |
JSON / YAML config |
|
|
Parse solver configurations from JSON or YAML files. See Configuration from JSON files for the user-facing interface. |
The first two each have their own page below. The config extension is documented in its own concept page because configuration is a first-class user-facing topic, not just a build-time integration.
Build-time enablement#
Each extension is opt-in at build time, but the activation mechanism is not the same across them:
Extension |
How to enable |
|---|---|
Kokkos interop |
Configure with |
cuDSS |
Build Ginkgo with |
JSON / YAML config |
Configure with |
If the dependency cannot be found or the flag is off, the corresponding header is not installed and the extension’s namespace is not available.
Per-extension pages#
Extensions
See also
Configuration from JSON files — the user-facing wrapper around the config extension.
API reference:
gko::ext