---
title: 'Ginkgo: Disambiguation in HPC, ASP, & Botany'
url: https://www.emergentmind.com/topics/ginkgo
type: topic
---

# Ginkgo: Disambiguation in HPC, ASP, & Botany

Searching arXiv for recent papers on “Ginkgo” to ground the article in the cited literature.
In current arXiv literature, **Ginkgo** is a polysemous research term rather than a single object. It most extensively denotes a modern C++ sparse numerical linear algebra library organized around a linear-operator abstraction for heterogeneous high-performance computing, but it also names an ASP-based system for invariant discovery in planning, a library for cut-element integration with parametric interfaces, and a probabilistic generative model for jets. In a separate botanical sense, **Ginkgo biloba** appears as the subject of studies on urban biomass valorization, delayed luminescence imaging, forest inventory, and chromatographic purification. A technically accurate account of the term therefore requires explicit disambiguation across these distinct research lineages [2006.16852] [1905.03196] [2501.03854] [2105.10512].

## 1. Disambiguation across research domains

The term is used in several unrelated ways in the cited literature.

| Usage of “Ginkgo” | Technical role | Representative papers |
|---|---|---|
| Ginkgo library | Linear operator algebra framework for sparse HPC | [2006.16852], [2011.08879] |
| ginkgo system | Automatic invariant discovery in ASP planning | [1905.03196] |
| Ginkgo library | Parametric cut-element quadrature / isogeometric analysis | [2501.03854] |
| Ginkgo model | Probabilistic generative model for jets | [2105.10512] |
| Ginkgo biloba | Experimental subject in biomass, imaging, forestry, and chromatography | [2507.20683], [2501.01173], [1702.02235], [2601.03702] |

A common misconception is to treat all occurrences as references to the same software artifact. The cited papers do not support that reading. Instead, they describe distinct systems with different mathematical objects, implementation stacks, and scientific purposes. The numerical linear algebra library is the best characterized meaning in the corpus and is the one most often embedded in broader HPC workflows [2509.16081].

## 2. Linear-operator algebra framework for sparse high-performance computing

In the HPC literature, Ginkgo is a modern C++ math library for scientific high-performance computing whose defining design choice is to elevate **linear operators** above matrices and vectors as the primary software abstraction. The key interface is `LinOp`, which treats several objects uniformly: a matrix-vector product as \(L_A : z \mapsto Az\), a solver with fixed matrix as \(S_A : b \mapsto A^{-1}b\), and a preconditioner as \(P_M : u \mapsto M^{-1}u\). The library therefore models matrices, solvers, and preconditioners with the same `apply(b, x)` interface. In exact arithmetic this corresponds to the standard linearity condition, while in floating-point arithmetic Ginkgo explicitly allows an error term \(E\) in \(L(\alpha x + \beta y) = \alpha L(x) + \beta L(y) + E\) [2006.16852].

This operator-first viewpoint is extended by `LinOpFactory`, which represents higher-order mappings from one operator to another, such as a solver factory \(\Sigma : L_A \mapsto S_A\) or a preconditioner factory \(\Phi : L_A \mapsto P_A\). This permits nested composition: an iterative refinement factory can contain a CG factory, which can itself contain a Jacobi factory. The result is an algebraic software model in which factorization, preconditioning, direct and iterative solves, and matrix-free operators can be composed without changing the outer interface [2006.16852].

The library’s current focus is sparse linear algebra on accelerators, especially GPUs. It provides Krylov methods including BiCG, BiCGSTAB, CG, CGS, FCG, and GMRES, fixed-point methods, sparse triangular solves, and preconditioners such as block-Jacobi and ILU-type methods. The paper reporting the core design emphasizes that the polymorphic overhead is very small, with measured time per iteration at most about \(1.5\,\mu s\) across the listed Krylov solvers, and presents SpMV and solver results near hardware bandwidth limits on contemporary GPUs [2006.16852].

## 3. Portability, backend architecture, and software integration

Ginkgo’s architectural center is the **Executor** abstraction, which separates algorithmic structure from hardware-specific kernels. In the 2020 design paper, the supported executors are `CudaExecutor` for NVIDIA GPUs, `HipExecutor` for AMD GPUs, `OmpExecutor` for multicore CPUs, and `ReferenceExecutor` for sequential correctness checking. Later portability work extends this model to a DPC++ backend for Intel GPUs, keeping the algorithmic core stable while changing backend kernels and runtime device selection [2006.16852] [2011.08879].

The portability strategy is explicitly **native-backend** rather than fully delegated to a single portability layer. The library “radically separates” the core from backend kernels, and later porting papers describe how this was realized for HIP and DPC++. For AMD support, a shared `common` folder was introduced for kernels identical across CUDA and HIP except for configuration details such as warp size or launch bounds; the backend-specific wrappers then inject the platform parameters. That reorganization avoided duplicating about 4,000 lines of code. In the HIP-on-NVIDIA comparison over more than 2,800 SuiteSparse matrices, mean performance ratios were slightly below \(1.0\), 50% of test cases had less than 3% difference, and 90% had less than 10% difference relative to native CUDA [2006.14290].

The Intel GPU port uses SYCL and extends Ginkgo’s batched iterative solvers for workloads of the form \(A_i x_i = b_i\), \(i=1,\dots,n\). The implementation maps one linear system to one SYCL work-group, packs the whole batch into a single kernel, and dynamically dispatches among matrix formats, solvers, stopping criteria, and subgroup options. On Intel GPU Max 1550 hardware, the resulting production-oriented batched solvers for PeleLM inputs surpass the previous CUDA implementation on H100 GPUs by an average factor of 2.4x, while preserving Ginkgo’s broader performance-portability agenda [2308.08417].

The integration literature presents Ginkgo as a sustainable building block for large applications. It is described as originating in the Exascale Computing Project, exposing sparse solvers, preconditioners, reorderings, sparse matrices, dense vectors, and array storage through a runtime-selectable execution model across CUDA, HIP, and SYCL backends. The papers emphasize loose-coupling integration patterns in Sundials/PeleLM, HiOP/ExaSGD, openCARP, and OpenFOAM via OGL, using `Executor`, `LinOp`, smart-pointer ownership, and transparent array views to reduce copying and localize dependencies [2509.16081].

## 4. Mixed precision, Krylov methods, and Ginkgo as backend or baseline

A major research theme around Ginkgo is **precision-aware sparse iterative computation**. In “compressed basis GMRES,” the orthogonal Krylov basis is stored in reduced-precision or fixed-point formats while GMRES arithmetic remains in double precision. The paper studies `<float32>`, `<float16>`, `<int32>`, and `<int16>` basis storage, exploits the boundedness of orthonormal basis entries, and implements datatype conversion through a memory accessor in Ginkgo. On an NVIDIA V100, 32-bit compressed formats preserve convergence well, while 16-bit formats often degrade it; the reported median speedup is about 1.4× for `GMRES<float32>`, with favorable outliers reaching about 1.75× and up to 50% speedup over standard double-precision GMRES [2009.12101].

Mixed precision also appears in multigrid and time integration. For multigrid V-cycles with incomplete Cholesky smoothing, Ginkgo is the GPU implementation platform on an NVIDIA H-100 GPU because it supports the required mixed-precision combinations. The experiments show that IC smoothing can be applied in lower precision than the residual, restriction, prolongation, and correction path; on a 3D Poisson problem with 493,039 DoF, the best IR-V-cycle-IC variant `d-s-h-sh` achieved 1.4307× speedup and 0.7140 relative energy, while the analogous PCG configuration achieved 1.4339× speedup and 0.7160 relative energy [2511.04566]. In mixed-precision Runge–Kutta PDE solvers, Ginkgo supplies the sparse linear algebra, Krylov solvers, and custom preconditioner infrastructure on an NVIDIA A100 40GB GPU and a two-socket AMD EPYC Milan 7763 CPU node; the study reports full-solver speedups up to about 1.4× for the heat equation on GPU and mostly around 1.8× to 2.0× for advection, with solver tolerance and kernel quality determining whether reduced precision yields net gains [2412.16638].

External papers often use Ginkgo as a **strong general-purpose baseline** rather than as the algorithm under study. In the MERBIT SpMV paper, Ginkgo appears alongside cuSPARSE and academic kernels as a mainstream, highly optimized reference implementation. The benchmarks use 50 large irregular SuiteSparse matrices on an RTX 4090 with CUDA 12.4, compare Ginkgo CSR, COO, and HYB, and define “Ginkgo” in aggregated plots as the best per-dataset throughput among those variants. In that workload, Ginkgo attains the lowest throughput on the majority of datasets, while MERBIT reports geometric mean speedups over cuSPARSE COO of 1.27× and 1.25× in single and double precision; the corresponding Ginkgo variants range from 0.79× to 1.02× in single precision and 0.83× to 0.99× in double precision [2605.07391].

A similar pattern appears in radiation therapy dose calculation. There, Ginkgo is one of the state-of-the-art GPU sparse-matrix libraries used as a comparison point for a custom SpMV kernel, but the paper states that Ginkgo and cuSPARSE do not support the required mixed-precision mode with matrix entries in half precision and vectors in double precision. The comparison is therefore single precision only, and the custom CUDA cooperative-groups kernel is reported as comparable to or better than Ginkgo on the evaluated matrices [2103.09683]. These studies suggest that Ginkgo is best understood as a high-quality general sparse linear algebra framework whose performance envelope can nevertheless be exceeded by domain-specialized kernels when the data format, irregularity pattern, or precision regime is unusually constrained.

## 5. Ginkgo in ASP planning and invariant discovery

In a separate research lineage, **ginkgo** is a system for **discovering invariants automatically in ASP-based planning**. It addresses a limitation of modern ASP solving: conflict learning is effective, but learned constraints are usually instance-specific. The system therefore extracts propositional conflict constraints from a variant of `clasp`, generalizes them beyond the current instance, validates them as true invariants, and reuses them as integrity constraints in future solving. The paper characterizes this as a “framework featuring an integrated feedback loop” that continuously extends the input program with automatically discovered invariants [1905.03196].

Methodologically, ginkgo operates in a learn–generalize–prove–reuse loop. Learned constraints are first generalized over the temporal domain in planning encodings, then checked for invariance using automated proofs implemented entirely in ASP with meta encodings. The focus is planning domains represented in PDDL, and the discovered properties are domain-level restrictions that remain valid across planning instances rather than ad hoc lemmas for a single run. The paper presents this as a successful proof of concept for reusing learned conflict constraints in ASP planning by means of generalization [1905.03196].

This work is also positioned within a broader software lineage. The paper states that plasp 3 emerged from the author’s work with ASP-based planning in the ginkgo system, while anthem addresses verification of ASP programs against formal specifications via translation to first-order logic and theorem proving. Ginkgo, plasp 3, and anthem are therefore complementary rather than interchangeable: automatic invariant discovery and reuse, improved ASP planning infrastructure, and formal verification, respectively [1905.03196].

## 6. Other technical uses: cut-element integration and probabilistic jet modeling

In computational geometry and isogeometric analysis, **Ginkgo** is an open-source library for **cut-element integration when the interface is given parametrically**. The comparison study on cut elements uses Ginkgo for parametric curves and Algoim for implicitly defined interfaces. For the Ginkgo side, the interface is described by a NURBS curve,
\[
\mathbf{C}(\xi)=\sum_{j=1}^n R_{j,p}(\xi)\mathbf{c}_i,
\]
and cut elements are handled by reparametrizing the trimmed domain; if a cut element cannot be represented by a single B-spline surface, it is split into tiles that can each be reconstructed using B-spline surfaces. Across area-computation tests, moving-interface robustness tests, and 2D elasticity benchmarks in GeoPDEs, the paper concludes that neither the parametric interface description used with Ginkgo nor the implicit description used with Algoim is preferable with respect to integration quality; the choice depends on the application and on how the geometry is available [2501.03854].

In jet physics, **Ginkgo** names a simplified **probabilistic generative model for jets** designed to expose the latent-variable structure of parton showers. The model defines a tractable joint likelihood
\[
p(x,z \mid \theta) = p(x \mid z_{\text{leaves}},\theta)\prod_{s \in \text{splittings}} p(z_{s,L}, z_{s,R} \mid z_{s,P}, \theta),
\]
with momentum conservation, permutation invariance, and a running splitting scale. The paper uses it to recast jet reconstruction, Monte Carlo tuning, matrix element–parton shower matching, and constrained event generation as problems of marginalization, MAP inference, and posterior sampling over latent shower histories [2105.10512].

The combinatorics are explicit: the number of binary clustering trees for \(N\) leaves grows as \((2N-3)!!\), motivating exact and approximate search procedures. The paper reviews a hierarchical cluster trellis whose exact dynamic programming complexity is about \(\mathcal{O}(3^N)\), as well as dynamic programming for MAP clustering, A* search over partial hierarchies, and reinforcement-learning formulations in which merge actions are rewarded by log splitting likelihood. In this context, Ginkgo serves as a controlled benchmark that connects jet physics with statistics, probabilistic programming, hierarchical clustering, combinatorial optimization, and reinforcement learning [2105.10512].

## 7. Ginkgo biloba as an experimental subject in applied research

In the botanical and applied-science literature, **Ginkgo** refers to **Ginkgo biloba**, but even here the cited studies span several unrelated technical contexts. In urban biomass valorization, pruning residues from Ginkgo biloba trees are converted to charcoal by slow pyrolysis after oven drying at 105 °C for 72 h. Over 400–600 °C, the reported mass yield decreases from 32.05% to 26.41%, while the higher heating value increases from 20.76 to 34.26 MJ kg\(^{-1}\). The paper estimates roughly 29,676.22 metric tons per year of Ginkgo pruning biomass in Korean urban areas, reports that G550 and G600 meet the Korean first-grade charcoal standard, and identifies heavy-metal contamination—especially Zn—as the principal deployment constraint [2507.20683].

In plant photophysics, delayed-luminescence imaging with a qCMOS camera shows that Ginkgo leaves have the highest initial DL intensity and the slowest decay among the tested species. Reported initial intensities at 30 s are 0.5353 for Ginkgo leaf, 0.3037 for *Hydrocotyle vulgaris*, 0.2736 for *Arabidopsis* plant, and 0.2258 for *Arabidopsis* leaf. Under mechanical injury, Ginkgo rises from 0.4297 to 0.6693 after 5 min; under 3% \(H_2O_2\), it rises from 0.4555 in control to 0.7675 at 25 min; under different light qualities, white light yields 0.4819, red 0.2814, and blue 0.2256. The decay curves are fit with an exponential model \(y = a \times \exp(bx)\), and the paper interprets Ginkgo’s behavior as a strong and persistent oxidative-response signal [2501.01173].

In forest inventory, an automated low-cost terrestrial laser scanner called BEE was evaluated in an artificial forest in Beijing composed mainly of ginkgo trees with a small number of pine trees. Across four 10 m × 10 m plots scanned once from near the center, the overall trunk detection rate was 92.75%, DBH estimation had RMSE 1.27 cm, and tree-height estimation had RMSE 0.24 m. The study attributes some missed detections to shadowing, proximity to pine trees, and outliers affecting the fitted circle, but concludes that the system can efficiently estimate structure parameters in small ginkgo plantation plots [1702.02235].

In chromatographic process development, Ginkgo biloba leaf extract is the case study for an LLM-driven platform called ChromR. The purification target is enrichment of flavonoid glycosides and terpene trilactones under the 2025 Chinese Pharmacopoeia requirements \(FG \ge 24.0\%\) and \(TT \ge 6.0\%\). ChromR recommends AB-8 macroporous adsorption resin, 20% aqueous ethanol washing, 75% aqueous ethanol elution, and a bed height-to-diameter ratio of 12:1; it then performs DOE generation, automated execution, stepwise-regression modeling, and NSGA-II/III optimization. The paper states that the Ginkgo process was developed within about one week, approximately one-seventh of the conventional timeline of about seven weeks [2601.03702].

Taken together, these papers show that **Ginkgo** in contemporary research is not a unitary topic but a cluster of technically unrelated entities linked only by name. The most mature and widely reused sense is the sparse linear algebra library for heterogeneous HPC, yet the same label also denotes a planning system, a geometric quadrature library, a jet-physics model, and the biological subject Ginkgo biloba in several measurement and process-engineering studies [2006.16852] [2509.16081].

Source: https://www.emergentmind.com/topics/ginkgo