<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Linear solvers | TC</title><link>https://www.cimic.fr/tag/linear-solvers/</link><atom:link href="https://www.cimic.fr/tag/linear-solvers/index.xml" rel="self" type="application/rss+xml"/><description>Linear solvers</description><generator>Wowchemy (https://wowchemy.com)</generator><language>en-us</language><lastBuildDate>Sat, 21 Feb 2026 00:00:00 +0100</lastBuildDate><image><url>https://www.cimic.fr/media/icon_hud7622ce574d3dba24d69684c2b50c81e_82098_512x512_fill_lanczos_center_3.png</url><title>Linear solvers</title><link>https://www.cimic.fr/tag/linear-solvers/</link></image><item><title>KokkosECG</title><link>https://www.cimic.fr/project/ecg/</link><pubDate>Sat, 21 Feb 2026 00:00:00 +0100</pubDate><guid>https://www.cimic.fr/project/ecg/</guid><description>&lt;p>KokkosECG is a C++ implementation of the &lt;strong>Enlarged Conjugate Gradient&lt;/strong> (ECG) method on top of &lt;a href="https://github.com/kokkos/kokkos" target="_blank" rel="noopener">Kokkos&lt;/a>, so that the same solver code can run on CPUs and GPUs.&lt;/p>
&lt;h2 id="why-ecg">Why ECG?&lt;/h2>
&lt;p>The classical Conjugate Gradient (CG) method for a sparse symmetric positive definite system is dominated by sparse matrix-vector products and dot products. On current hardware these operations are limited by memory bandwidth, and every dot product is a global reduction, which is expensive in a distributed setting.&lt;/p>
&lt;p>ECG, introduced by Grigori, Moufawad and Nataf, replaces the single search direction of CG by a block of &lt;code>t&lt;/code> directions. The sparse matrix-vector product becomes a sparse matrix times a block of vectors, and the scalar coefficients of CG become small &lt;code>t x t&lt;/code> dense matrices. This gives:&lt;/p>
&lt;ul>
&lt;li>a higher arithmetic intensity, because the matrix is read once for &lt;code>t&lt;/code> vectors,&lt;/li>
&lt;li>fewer synchronisation points per iteration, because the global reductions are done on blocks,&lt;/li>
&lt;li>a richer Krylov subspace, hence potentially fewer iterations.&lt;/li>
&lt;/ul>
&lt;p>With &lt;code>t = 1&lt;/code> the method is exactly CG. ECG is a method I already worked with during my PhD at INRIA, on linear solvers for the map-making problem (see &lt;a href="https://www.cimic.fr/project/b3dcmb/">B3DCMB&lt;/a>).&lt;/p>
&lt;h2 id="what-the-code-does">What the code does&lt;/h2>
&lt;p>The implementation follows the Block CG Orthomin variant with A-CholQR orthogonalisation, wrapped in the ECG framework. The initial residual is split into &lt;code>t&lt;/code> vectors with contiguous, disjoint supports, and the A-orthogonalisation is done through the &lt;code>t x t&lt;/code> Gram matrix of the search directions, factorised once per iteration with a Cholesky decomposition.&lt;/p>
&lt;p>The library is organised around a small class hierarchy, which makes it simple to add other Krylov variants:&lt;/p>
&lt;ul>
&lt;li>&lt;code>IterativeMethod&lt;/code>, the abstract base class (iteration limit, tolerance, convergence history),&lt;/li>
&lt;li>&lt;code>ConjugateGradient&lt;/code>, the BLAS-2 baseline,&lt;/li>
&lt;li>&lt;code>EnlargedConjugateGradient&lt;/code>, the block version with a sparse-matrix-times-block product and BLAS-3 kernels.&lt;/li>
&lt;/ul>
&lt;p>All vectors and matrices are &lt;code>Kokkos::View&lt;/code>, and the sparse matrices are stored in CRS format and handled with KokkosKernels. The build uses CMake with C++20, and the repository enforces formatting, static analysis and tests through a pre-commit hook.&lt;/p>
&lt;p>The preconditioned variants, a benchmark suite against plain CG and a CI pipeline are still on the roadmap. The details are in the &lt;a href="https://gitlab.com/thibaultcimic/kokkosecg" target="_blank" rel="noopener">repository&lt;/a>.&lt;/p>
&lt;h2 id="reference">Reference&lt;/h2>
&lt;p>L. Grigori, S. Moufawad, F. Nataf, &lt;em>Enlarged Krylov Subspace Conjugate Gradient Methods for Reducing Communication&lt;/em>, SIAM Journal on Matrix Analysis and Applications, 37(2), 744-773, 2016.&lt;/p></description></item></channel></rss>