Alessandro Carraro

Tile-Low-Rank Matrices in NextLA.jl

2026-08-20T00:00:00+00:00

This post summarizes my Google Summer of Code 2026 work on NextLA.jl, mentored by Rabab Alomairy and Qinglei Cao. The project introduced the Tile-Low-Rank (TLR) matrix format and GPU-accelerated operations, including matrix multiplication with both dense and compressed output.

Introduction
My contribution
Two TLR variants
Packing variable-rank tiles
Compression with ARA
GEMM on compressed operands
1. Workspace is part of the schedule
2. Returning a compressed result
Results
Using the implementation
References

Introduction

A dense $32{,}768 \times 32{,}768$ Float64 matrix costs 8.6 GB to store, and operations such as factorization still scale cubically in the matrix dimension. But many matrices that appear in scientific computing do not contain that much independent information. Boundary element discretizations, Gaussian process covariance matrices, and kernel matrices from radial basis functions often have smooth interactions between well-separated groups of points. Smooth interactions are numerically low rank, so after blocking the matrix, most off-diagonal tiles have singular values that decay after only a small number of terms.

The storage arithmetic is already enough to motivate the format. Tile the $32{,}768 \times 32{,}768$ matrix into $1024 \times 1024$ blocks. The 32 diagonal tiles stay dense, while the remaining 992 off-diagonal tiles are stored as rank-16 factor pairs. The dense diagonal costs 268 MB, and the off-diagonal factors cost about 260 MB. The result is 528 MB instead of 8.6 GB, about a 16x reduction.

Tile-Low-Rank (TLR) uses that observation directly. Cut the matrix into a flat grid of tiles. Keep the diagonal dense, since it represents the near field and is usually genuinely full rank. Replace each off-diagonal tile with two skinny factors,

\[A_{ij} \approx U_{ij}V_{ij}^{T}, \qquad U_{ij}\in\mathbb{R}^{b_i\times r_{ij}}, \quad V_{ij}\in\mathbb{R}^{b_j\times r_{ij}},\]

where $r_{ij}$ is much smaller than the tile size. Unlike a global low-rank factorization, each tile gets its own rank. Unlike $\mathcal{H}$-matrices or HODLR, there is no tree and no recursion: one level, one tile size, and one regular grid. That gives up some compressibility, but it produces a layout that is far easier to schedule on a GPU, which is fundamental for performance in real applications.

Each tile has its own low-rank factorization and rank.

During the Google Summer of Code I implemented the TLR module in NextLA.jl, a Julia library aiming to provide next-generation dense linear algebra: mixed precision, low-rank formats, and multiple hardware backends behind one API, on CPU and GPU without hardware-specific code paths. This post describes the TLR module we added.

My contribution

The code is available in NextLA.jl and was introduced in pull request #20.

The main result is an end-to-end public pipeline for working with TLR matrices. Starting from ordinary dense matrices, NextLA can now build compressed representations,

\[A \longrightarrow A_{\mathrm{tlr}}, \qquad B \longrightarrow B_{\mathrm{tlr}},\]

where each object stores the matrix by tiles rather than as one dense array. The API exposes two variants: TLRMatrix, which keeps the diagonal tiles dense, and CompressedFTLRMatrix, where every tile is stored in compressed form.

Once the matrices are compressed, they can be used directly in BLAS-like products,

\[C \leftarrow \alpha\,\operatorname{op}(A_{\mathrm{tlr}}) \operatorname{op}(B_{\mathrm{tlr}}) + \beta C,\]

with support for TLR × TLR, TLR × dense, and dense × TLR. There is also an allocation-returning path where the output remains compressed,

\[C_{\mathrm{tlr}} \leftarrow \operatorname{gemm}(A_{\mathrm{tlr}}, B_{\mathrm{tlr}}),\]

so the product does not have to be materialized as a dense matrix. The API also exposes the controls needed for real workloads: transpose combinations, mixed-precision compute modes, workspace limits, and workspace reuse.

Below we illustrate some implementation details and provide a small tutorial to show how to construct the TLR matrices, multiply them, and choose how much precision and memory to spend.

Two TLR variants

We implemented two versions of the format. TLRMatrix follows the usual scientific-computing layout [1]: diagonal tiles are dense and off-diagonal tiles are compressed. CompressedFTLRMatrix stores every tile, including the diagonal, as a factor pair. The second format is useful when there is no clear dense near field, which is common for blockwise-compressed machine-learning matrices [4].

Packing variable-rank tiles

Storing every factor at an operand-wide maximum rank would make the arrays regular, but it would also bring back arithmetic and memory that compression was supposed to remove. NextLA instead stores each tile using its discovered logical rank.

The two factors use complementary traversal orders. The $U$ factors are packed by tile row, while the $V$ factors are packed by tile column. This makes a row panel of $U$ and a column panel of $V$ available as contiguous views at the same time. Transposition only exchanges the two roles, so the same storage works for every N/T operand combination without keeping another copy.

Logical ranks and factor offsets describe two complementary packed arrays.

Some low-precision kernels, including grouped GEMM, require aligned factor addresses and dimensions. The rank_multiple option meets this requirement by padding each factor’s stored capacity without changing its logical rank, error estimate, or numerical result. On current CUDA hardware, use rank_multiple=8 for FP16 and BF16 factors.

Alignment padding is local to each factor instead of using one maximum rank for the whole matrix.

Compression with ARA

The tile ranks are outputs of the compression, not inputs. We use Adaptive Randomized Approximation (ARA) [2] to sample a batch of tiles and grow an orthogonal basis until each tile meets the requested tolerance or reaches maxrank.

Tiles in one batch do not necessarily converge together. The implementation therefore keeps separate progress and stopping state for every tile. On each pass it projects a fresh sample against the existing basis, performs two-pass Cholesky QR, and checks the new projected columns. Finished tiles retire while the others continue. A final small SVD chooses the stored rank and records the remaining error.

From the user side, this is just a constructor:

A_tlr = TLRMatrix(A, 256;
                  maxrank=64,
                  tol=1f-5,
                  rel=true,
                  r_required=10)

Here r_required controls how many consecutive negligible samples ARA needs before declaring a tile converged. Compression workspaces can also be reused when several matrices have the same shape and tiling.

GEMM on compressed operands

The dense-output interface follows BLAS:

\[C \leftarrow \alpha\,\operatorname{op}(A)\operatorname{op}(B)+\beta C, \qquad \operatorname{op}(X)\in\{X,X^T\}.\]

The API covers two compressed operands as well as mixed dense/compressed products. TLRMatrix also carries dense diagonal tiles and smaller boundary tiles, so its GEMM combines the compressed off-diagonal product with the two dense-diagonal cross terms and the diagonal product.

The interesting part is the product of two compressed tiles. Write

\[A_{i\ell}=U_{i\ell}V_{i\ell}^{T}, \qquad B_{\ell j}=W_{\ell j}Z_{\ell j}^{T}.\]

Then one output tile is

\[C_{ij}=\sum_{\ell} U_{i\ell}\underbrace{\left(V_{i\ell}^{T}W_{\ell j}\right)}_{S_{i\ell j}} Z_{\ell j}^{T}.\]

Computing that expression tile by tile gives many tiny GEMMs and repeatedly loads and stores $C_{ij}$. Most of the GEMM work went into avoiding that. The packed factors let us fuse adjacent tile rows and columns into larger views, and the product is lowered in three stages:

form the small coupling matrices $S_{i\ell j}$;
multiply $S$ by one side’s factors;
fold the sum over $\ell$ into the reduction dimension of a final GEMM.

Stage 1 forms the coupling matrices. Output columns are fused into each GEMM, while the contraction tiles are submitted as a batch.

Stage 2 builds the intermediate factors with grouped GEMMs over the contraction and output-column indices.

Stage 3 folds the complete sum over ℓ into the GEMM reduction dimension, producing an output row with one final GEMM.

There are two valid contraction orders. FoldRight computes $U(SZ^T)$; FoldLeft computes $(US)Z^T$. Their temporary sizes and operation counts depend on the ranks in the current rows and columns. The scheduler looks at that rank metadata and chooses the cheaper feasible direction instead of imposing one order on the entire matrix.

Workspace is part of the schedule

The temporary workspace determines how many output tiles can be fused in one run. With more memory, the scheduler builds wider operations. With less, it splits the output into smaller row and column ranges while staying inside the requested byte limit.

NextLA exposes minimum and maximum workspace queries. For fully compressed operands, gemm_workspace_bytes(A, B; runs=n) chooses the smallest workspace that meets a target number of runs. The symbolic schedule and prepared grouped-GEMM descriptors can be cached and reused when the matrix dimensions and rank distribution stay the same.

This makes the memory/performance tradeoff explicit. A caller can use the fastest schedule when memory is available or deliberately trade some fusion for a smaller peak allocation.

Returning a compressed result

The allocation-returning gemm(A_tlr, B_tlr; ...) keeps the result compressed. This is a different problem from the dense-output path: the rank of each output tile is unknown until the product has been sampled. We cannot allocate its final packed offsets in advance, and forming a dense tile just to compress it would lose most of the benefit.

For one output tile, define

\[X_{ij}=\alpha\sum_{\ell} A_{i\ell}B_{\ell j} =\alpha\sum_{\ell} U^A_{i\ell}S_{i\ell j}(V^B_{\ell j})^T, \qquad S_{i\ell j}=(V^A_{i\ell})^TU^B_{\ell j}.\]

The coupling matrices $S_{i\ell j}$ depend on the input factors but not on the random samples, so they are computed once for a run and reused. A right sample of the complete tile is then

\[X_{ij}\Omega =\alpha\sum_{\ell}U^A_{i\ell}S_{i\ell j} \left((V^B_{\ell j})^T\Omega\right).\]

This is evaluated as three GEMM contractions: project the random block through $V^B$, apply the small coupling matrices, and reduce all $\ell$ contributions through the packed $U^A$ row. The wide $b_m\times b_n$ tile $X_{ij}$ never exists in memory. If left sampling is cheaper, the implementation applies the transpose expression instead. Complementary packing provides the contiguous row or column stack needed by either direction and by all four transpose combinations.

ARA repeats this implicit apply with fresh random blocks and grows a basis $Q$ until the tile converges. It then applies the complementary operator once,

\[Z_{ij}=X_{ij}^TQ_{ij}, \qquad X_{ij}\approx Q_{ij}Z_{ij}^T,\]

and performs a small final SVD to select the output rank and split the result into its two stored factors. In contrast to sequential recompression, the whole sum over $\ell$ is compressed once rather than after every contraction tile.

The output grid is processed with a rolling workspace. A byte budget determines how many ARA slots are available. A fixed-row or fixed-column run fills those slots; when some tiles converge, they are moved to a retired suffix, truncated, and copied to output staging. Pending tiles immediately reuse the freed slots. Workspace therefore scales with the chosen concurrency rather than with the number of output tiles.

During this pass, staging factors have a uniform width of maxrank. Once every logical rank is known, NextLA allocates the final exact-rank offsets, applies rank_multiple if alignment is requested, and copies only the active factor columns. This is why compressed-output GEMM returns a newly allocated matrix instead of accepting a finalized packed destination through gemm!.

The main controls are:

Keyword	Role in compressed-output GEMM
`maxrank`	Upper bound for every discovered output rank and the temporary staging width
`tol`, `rel`	Absolute or relative error target used by final truncation
`eps_rel`	Sampling tolerance for the adaptive range finder; defaults from `tol` and the numerical stopping floor
`block`	Number of random columns drawn in one ARA pass
`r_required`	Consecutive negligible samples required before a tile retires
`workspace`	Optional byte budget; larger values allow more simultaneous ARA slots
`rank_multiple`	Alignment quantum for the final stored capacities, without changing logical ranks

The current compressed-output entry point accepts two CompressedFTLRMatrix operands on a regular tile grid. It supports NN, NT, TN, and TT, plus the same mixed-precision compute modes as the dense-output implementation.

Results

We evaluated the dense-output GEMM on an NVIDIA H100 with both uniform and skewed tile-rank distributions. A direct comparison with KBLAS is necessarily limited: KBLAS supports FP32 and FP64 and uses one common rank for every tile in an operand. NextLA additionally supports BF16, FP16, and TF32 on CUDA, and executes each tile at its own rank.

For constant-rank FP32 problems, NextLA reached 92.1% of the ceiling obtained by scaling dense-GEMM time by the executed-FLOP ratio. On the configurations shared with KBLAS, it was 1.44 times faster in geometric mean and up to 2.58 times faster. The advantage is larger for variable ranks because NextLA does not pad every tile to one operand-wide rank.

Constant-rank FP32 GEMM with tile size $$b=N/16$$ and tile rank $$r=b/16$$. The arithmetic ceiling scales dense-GEMM time by the executed-FLOP ratio.

The constant-rank experiment above provides the like-for-like KBLAS comparison. The next experiment uses the feature that the padded baseline cannot represent directly: different ranks for different tiles. Each matrix has eight tiles per axis, hence 64 tiles in total, with tile size $b=N/8$ and ranks varying between $b/16$ and $b/8$. The bars report speedup over the corresponding dense GEMM for several matrix sizes and compute modes.

Speedup over dense GEMM for matrices with an $8\times8$ tile grid, $b=N/8$, and per-tile ranks in $[b/16,b/8]$. NextLA uses the exact rank of each tile. KBLAS pads the varying ranks to one common rank and is shown only for its supported FP32 comparison.

The missing KBLAS bars in the BF16, FP16, and TF32 panels are therefore not omitted measurements; those execution modes are not supported by KBLAS. The NextLA speedup increases with matrix size as the fused compressed operations become large enough to use the GPU efficiently.

The workspace experiments show the other side of the design. One FP16 configuration was 6.34 times faster than dense GEMM while using 17.8% of the dense-input memory. In the largest reported FP16 case, $N=65{,}536$ completed in 81.8 ms, 9.57 times faster than the dense baseline while using 10.7% of its operand memory.

Using the implementation

Assume A and B are dense Matrix{Float32} inputs. The same compressed operands can then be used with both GEMM output modes:

using NextLA

# A and B are dense matrices with compatible dimensions. For compressed-output
# GEMM, each dimension must also be a multiple of the tile size.
b, maxrank = 256, 64

A_tlr = CompressedFTLRMatrix(A, b; maxrank, tol=1f-5, rel=true)
B_tlr = CompressedFTLRMatrix(B, b; maxrank, tol=1f-5, rel=true)

# Dense accumulation: C_dense is an ordinary dense matrix.
C_dense = zeros(Float32, size(A, 1), size(B, 2))
dense_workspace = gemm_maximum_workspace_bytes(A_tlr, B_tlr)
gemm!(C_dense, A_tlr, B_tlr;
      workspace=dense_workspace,
      alpha=1,
      beta=0)

# Compressed accumulation: ranks are discovered before C_tlr is packed.
C_tlr = gemm(A_tlr, B_tlr;
             maxrank,
             tol=1f-5,
             rel=true,
             r_required=10)

# Expand a compressed matrix whenever a conventional dense array is needed.
C_uncompressed = similar(C_dense)
uncompress!(C_uncompressed, C_tlr)

C_dense stores the product directly in dense form. C_tlr keeps each output tile compressed, while C_uncompressed is its dense reconstruction.

On CUDA, FP16 and BF16 storage can use rank_multiple=8; FP32 can select Tensor Core execution with compute=TF32().

References

[1] K. Akbudak, H. Ltaief, A. Mikhalev, and D. Keyes. Tile Low Rank Cholesky Factorization for Climate/Weather Modeling Applications on Manycore Architectures. ISC High Performance, 2017.

[2] W. Boukaram, G. Turkiyyah, and D. Keyes. Hierarchical Matrix Operations on GPUs. SIAM Journal on Scientific Computing 41(4), 2019.

[3] A. Charara, D. Keyes, and H. Ltaief. Tile Low-Rank GEMM Using Batched Operations on GPUs. Euro-Par, 2018.

[4] P.-H. Chen, S. Si, Y. Li, C. Chelba, and C.-J. Hsieh. GroupReduce: Block-Wise Low-Rank Approximation for Neural Language Model Shrinking. NeurIPS, 2018.

TLR Matrix Multiplication

2026-07-03T00:00:00+00:00

Introduction: TLR GEMM
Fixed Rank GEMM: dense ← TLR × TLR
1. Regular TLR GEMM
  1. The easy terms
  2. The $O_A O_B$ terms

Introduction: TLR `GEMM`

Let $A \in \mathbb{R}^{N \times N}$ be a square matrix stored in tile low-rank (TLR) format. We partition $A$ into an $n \times n$ grid of tiles,

\[A = \begin{bmatrix} A_{11} & \widetilde A_{12} & \cdots & \widetilde A_{1n} \\ \widetilde A_{21} & A_{22} & \cdots & \widetilde A_{2n} \\ \vdots & \vdots & \ddots & \vdots \\ \widetilde A_{n1} & \widetilde A_{n2} & \cdots & A_{nn} \end{bmatrix}.\]

The diagonal tiles $A_{ii}$ are stored densely; each off-diagonal tile ($i \neq j$) is stored in compressed low-rank form

\[\widetilde A_{ij} = U_{ij} V_{ij}^{T}, \qquad U_{ij} \in \mathbb{R}^{b_i \times r_{ij}}, \quad V_{ij} \in \mathbb{R}^{b_j \times r_{ij}},\]

where $r_{ij}$ is the tile rank. Interior tiles are $b \times b$; boundary tiles are smaller when $N$ is not a multiple of $b$.

We want the generalized product

\[C \leftarrow \alpha \operatorname{op}(A)\operatorname{op}(B) + \beta C, \qquad \operatorname{op}(X) \in \{X, X^{T}\},\]

where each of $A$, $B$, $C$ may be stored densely or in TLR format. The tile factors can be stored padded to occupy $b\times r_{\max}$ even if the efefctive rank $r_{ij} < r_{\max}$ or with variable storage such that each tile only takes $r_{ij}$. The second one requires more complex scheduling. We develop the general GEMM $\mathrm{TLR}\times \mathrm{TLR}\rightarrow \mathrm{TLR}$ in three steps, from the easiest to the most complex, building on each other.

\[\begin{aligned} &\text{1. fixed rank:} \qquad &&\text{dense} \leftarrow \text{TLR} \times \text{TLR}, \\ &\text{2. fixed rank:} \qquad &&\text{TLR} \leftarrow \text{TLR} \times \text{TLR}, \\ &\text{3. variable rank:} \qquad &&\text{TLR} \leftarrow \text{TLR} \times \text{TLR}. \end{aligned}\]

This post describes stage 1, the fixed-rank dense-output case; the TLR-output cases extend it.

Fixed Rank `GEMM`: $\mathrm{ dense} \leftarrow \mathrm{TLR}\times \mathrm{TLR}$

The goal of the first implementation stage is to compute

\[C \leftarrow AB,\]

where both $A$ and $B$ are stored in fixed-rank TLR format and $C$ is stored densely. The main implementation objective is to express the computation in terms of vendor-optimized BLAS primitives, in particular GEMM and batched GEMM variants.

To expose regular operations, we need to analyse the memory storage. TLR matrix can be stored using three buffers, one for the dense diagonal tile, represented by a 3d array of size $b\times b \times n$ such that each tile is written in memory in the (Julia standard) column major storage. Similarly the factors $U$ and $V$ can also be written in memory in two distinct buffers, where each factor is laid out column major and the factors are stored linearized according to either a tile row major or tile col major ordering. In the case where the tiles have the same blocksize $b$ and rank $r_{\max}$, there is a constant stride among consecutive factors and can be written as a 3d array as well.

In the more general case, where we store the arrays with variable ranks, we also hold an array with the ranks $r$ and compute its starting location in the buffer by prefix sum.

For the case the global matrix dimension $N$ is not an exact multiple of the nominal tile size $b$. Let

\[N = mb + b_{\mathrm{rem}},\]

where $m = \lfloor N/b \rfloor$ and $0 \leq b_{\mathrm{rem}} < b$. If $b_{\mathrm{rem}} = 0$, all tiles have size $b \times b$. Otherwise, the last block row and last block column contain boundary tiles with smaller dimensions. In that case, the interior part of the matrix has dimension $mb \times mb$, while the boundary block has size $b_{\mathrm{rem}}$.

For this reason, it is convenient to decompose the matrix into a regular interior TLR (sub)matrix and then three boundary panels. When $b_{\mathrm{rem}} > 0$, we write

\[A = \begin{bmatrix} A_{\mathrm{int}} & u_A \\ v_A^{T} & \gamma_A \end{bmatrix},\]

where

\[A_{\mathrm{int}} \in \mathbb{R}^{mb \times mb}, \qquad u_A \in \mathbb{R}^{mb \times b_{\mathrm{rem}}}, \qquad v_A \in \mathbb{R}^{mb \times b_{\mathrm{rem}}}, \qquad \gamma_A \in \mathbb{R}^{b_{\mathrm{rem}} \times b_{\mathrm{rem}}}.\]

Here, $A_{\mathrm{int}}$ denotes the regular TLR sub-matrix formed by the full-size tiles, while $u_A$, $v_A^{T}$, and $\gamma_A$ collect the boundary column, boundary row, and bottom-right corner block, respectively. So the storage becomes as in the figure below

The right operand $B$ in the TLR GEMM can have the same structure. Then the product $C = AB$ can be written as

\[\begin{aligned} C &= \begin{bmatrix} A_{\mathrm{int}} & u_A \\ v_A^{T} & \gamma_A \end{bmatrix} \begin{bmatrix} B_{\mathrm{int}} & u_B \\ v_B^{T} & \gamma_B \end{bmatrix} \\ &= \begin{bmatrix} A_{\mathrm{int}} B_{\mathrm{int}} & A_{\mathrm{int}} u_B \\ v_A^{T} B_{\mathrm{int}} & v_A^{T} u_B \end{bmatrix} + \begin{bmatrix} u_A v_B^{T} & u_A \gamma_B \\ \gamma_A v_B^{T} & \gamma_A \gamma_B \end{bmatrix}. \end{aligned}\]

This decomposition separates the computation into four output regions:

\[C = \begin{bmatrix} C_{\mathrm{int}} & C_{\mathrm{right}} \\ C_{\mathrm{bottom}} & C_{\mathrm{corner}} \end{bmatrix}.\]

This structure is allows to split the matrix-multiplication across terms with a regular structure, which maps well to (batched) GEMMs. The bulk of the work is the update of the interior block $A_{\mathrm{int}} B_{\mathrm{int}}$. Moreover since, the the four ouput regions are dijsoint they can be updated concurrently on separate streams.

We explain the machinery developed to compute the interior product $A_{\mathrm{int}} B_{\mathrm{int}}$, as this is the most computationally intensive operation and the most general. The same ideas are reused for the other products

Regular TLR `GEMM`

From here on we drop the $\mathrm{int}$ subscript and work with two square interior TLR sub-matrices. The storage naturally splits each operand into its dense diagonal and its low-rank off-diagonal part, $A = D_A + O_A$ and $B = D_B + O_B$, so that

\[C \leftarrow \beta C + \alpha (D_A + O_A)(D_B + O_B) = \beta C + \alpha\big(D_A D_B + O_A D_B + D_A O_B + O_A O_B\big).\]

The four products touch different parts of $C_{\mathrm{int}}$:

$D_A D_B$ writes only the diagonal tiles of $C$;
$O_A D_B$ and $D_A O_B$ write only the off-diagonal tiles;
$O_A O_B$ writes both, and usually accounts for the dominant part of the work

Because the diagonal group and the off-diagonal group touch disjoint tiles, they can run concurrently on separate streams

The scaling by $\beta$ is fused into the first GEMM that writes each tile of $C$. For a diagonal tile $C_{ii}$, the first writer is $D_A D_B$, so that GEMM performs

\[C_{ii} \leftarrow \beta C_{ii} + \alpha A_{ii}B_{ii}.\]

For an off-diagonal tile $C_{ij}$, the first writer is either the $O_A D_B$ update or the $D_A O_B$ update. That first off-diagonal GEMM uses the original $\beta$. Every later contribution to the same tile uses accumulation mode, i.e. it is launched with $\beta = 1$.

The easy terms

The first three products are mapped to strided batched GEMMs. The diagonal product is a batch of independent dense tile GEMMs:

\[(D_A D_B)_{ii} = A_{ii}B_{ii}, \qquad i = 1,\dots,m.\]

Thus it is implemented as one strided batched GEMM with matrix size $b \times b$ and batch size $m$.

The product $O_A D_B$ can be written as

\[(O_A D_B)_{ij} = U_{ij}\big(V_{ij}^{T}D_{jj}\big), \qquad i\neq j,\]

and is therefore evaluated in two batched GEMM stages. Consider first the products $V_{ij}^{T}D_{jj}$ over all off-diagonal tiles. The GEMM grouping depends on the layout of the low-rank factors. If the factors of $A$ are stored tile-column major, then for each fixed $j$ the matrices $V_{ij}^{T}$, $i\neq j$, are contiguous and can be stacked into one tall matrix. Thus the $m-1$ products associated with column $j$ are computed by one GEMM of size $((m-1)r)\times b$ times $b\times b$. Repeating this for all $j$ gives $m$ such GEMMs, which can be launched as one strided batched GEMM. If the factors of $A$ are stored row-wise instead, the factors needed for a fixed $j$ are not contiguous, so this aggregation is not available; the stage is then implemented as one small GEMM per off-diagonal tile, for a total of $m(m-1)$ GEMMs of size $r\times b$ times $b\times b$.

By symmetry, the opposite holds for the product $D_A * O_B$.

The $O_A O_B$ terms

Here both operands are low-rank. With $\widetilde A_{ik} = U_{ik} V_{ik}^{T}$ and $\widetilde B_{kj} = W_{kj} Z_{kj}^{T}$, the $(i,j)$ output block is

\[(O_A O_B)_{ij} = \sum_{k\neq i,j} U_{ik}\,\bigl(V_{ik}^{T}W_{kj}\bigr)\,Z_{kj}^{T}.\]

We first compute the common intermediate

\[\text{Stage 1:}\qquad S_{ikj}=V_{ik}^{T}W_{kj} \in\mathbb{R}^{r_A\times r_B}.\]

The remaining contractions are ordered to minimize the size of the intermediate matrix. Specifically,

If $r_A\le r_B$,

\[\begin{aligned} \text{Stage 2:}\qquad &T_{ikj}=S_{ikj}Z_{kj}^{T} &&\in\mathbb{R}^{r_A\times b},\\ \text{Stage 3:}\qquad &C_{ij}=\sum_k U_{ik}T_{ikj} &&\in\mathbb{R}^{b\times b}. \end{aligned}\]

If $r_B<r_A$,

\[\begin{aligned} \text{Stage 2:}\qquad &T_{ikj}=U_{ik}S_{ikj} &&\in\mathbb{R}^{b\times r_B},\\ \text{Stage 3:}\qquad &C_{ij}=\sum_k T_{ikj}Z_{kj}^{T} &&\in\mathbb{R}^{b\times b}. \end{aligned}\]

Thus, after forming $S_{ikj}$, the multiplication order is chosen according to $\min(r_A,r_B)$, ensuring that the intermediate matrix $T_{ikj}$ is as small as possible.

Each stage is a collection of small GEMMs indexed by three tile indices: the output row $i$, the output column $j$, and the contraction tile $k$. As in the previous section, the number and size of the GEMM depends on the layout of the factors. Every index can be handled in three cases:

Fused into a GEMM dimension (M, N, or K): several tiles are glued into one larger matrix operand and handled by a single large GEMM. This is fastest, but requires the tiles along a given axis to be contiguous in memory
Batched: many independent, equal-shaped GEMMs issued in one batched-GEMM call. This works for any layout, but each GEMM stays small.
Looped serially, one GEMM per value of the index.

Fusing is best (biggest GEMMs, fewest launches), batching is the fallback for scattered data, and looping is reserved for a case we will see is unavoidable. The axes which can be fused depends on the ordering of the factors: tile column or tile major order.

The stride-1 axis

The factors are stored as $[b, r, n_{\text{off}}]$ arrays. Tiles are contiguous in memory only along the stride-1 axis, which depends on the tile layout.

Operand	Tile-column-major	Tile-row-major
$A_{ik}$	$i$	$k$
$B_{kj}$	$k$	$j$

This gives four possible layout combinations, which determines the optimization lever.

Lever 1: $A$’s layout determines how the $k$-sum is performed

First consider one fixed output tile $C_{ij}$. Its low-rank update has the form

\[C_{ij} \mathrel{+}= \sum_{k\neq i,j} U_{ik}T_{ikj},\]

where $T_{ikj}$ is the intermediate produced by the previous stage. The important point is that all values of $k$ contribute to the same output tile $C_{ij}$. There are two ways to handle this sum:

If the factors $U_{ik}$ are contiguous in $k$, we can fold the $k$-sum into the GEMM contraction dimension. Namely, for fixed $(i,j)$ we form the block products as

\[C_{ij} \mathrel{+}= \underbrace{ \begin{bmatrix} U_{i1} & U_{i2} & \cdots \end{bmatrix} }_{b\times K_r} \underbrace{ \begin{bmatrix} T_{i1j}\\ T_{i2j}\\ \vdots \end{bmatrix} }_{K_r\times b},\]

where $K_r$ is the sum of the ranks over the contributing $k$ indices. In this case one GEMM computes the full sum over $k$ and writes $C_{ij}$ once. In this case the GEMM has the schematic form. This is the write-once case for $C_{ij}$.

If the factors $U_{ik}$ are not contiguous in $k$, folding the reduction into one GEMM would require packing or copying the $U$ panels. Without such packing, the implementation loops over $k$:

\[\begin{cases} C_{ij} \leftarrow U_{ik}T_{ikj} + \beta C_{ij} && k=1 \\ C_{ij} += U_{ik}T_{ikj} && k=2, \dots, n-1 \end{cases}\]

Now each contribution is a separate GEMM, and the same tile $C_{ij}$ is updated repeatedly. This is the accumulate case.

Thus:

If $A$ is stride-1 in $k$, then the $U_{ik}$ panels needed for one $C_{ij}$ are contiguous. The $k$-sum can be folded into the GEMM contraction dimension, and each output tile $C_{ij}$ is written once.
If $A$ is stride-1 in $i$, then the $U_{ik}$ panels needed for one $C_{ij}$ are scattered as $k$ varies. The implementation loops over $k$ and accumulates into $C_{ij}$ multiple times.

This statement concerns one fixed output tile. Across many output tiles, we still batch or loop over the remaining free indices. For example, if the $k$-sum has been folded for each $(i,j)$, then different output tiles $C_{ij}$ are independent and can be handled as a batch of write-once GEMMs. If the $k$-sum is not folded, then the implementation typically loops over $k$, and for each fixed $k$ updates a batch of output tiles $C_{ij}$ with accumulation.

This is why the two scheduling families differ in their traffic to $C$. In the write-once family, each $C_{ij}$ tile is formed by a GEMM that already includes the full $k$-sum. In the accumulate family, each $C_{ij}$ tile is read and written once per contributing $k$. Since Stage 3 operates on full $b\times b$ tiles, reducing the number of updates to $C$ is usually the dominant consideration.

Lever 2: $B$’s layout determines whether Stage 1 fuses over $j$

Stage 1 computes $S_{ikj}=V_{ik}^{T}W_{kj}$. For fixed $(i,k)$, the left operand $V_{ik}^{T}$ is reused for all output columns $j$, while the right operand $W_{kj}$ changes with $j$. Therefore, if the $W_{kj}$ factors are contiguous as $j$ varies, the products over $j$ can be fused into the $N$ dimension of one larger GEMM.

If $B$ is stride-1 in $j$, then the row-$k$ panel

\[\begin{bmatrix} W_{k j_1} & W_{k j_2} & \cdots \end{bmatrix}\]

is contiguous, and Stage 1 can compute

\[\begin{bmatrix} S_{ikj_1} & S_{ikj_2} & \cdots \end{bmatrix} = V_{ik}^{T} \begin{bmatrix} W_{k j_1} & W_{k j_2} & \cdots \end{bmatrix}.\]

Thus $j$ is fused into the GEMM $N$ dimension. This replaces many small $r_A\times r_B$ products by one wider GEMM.

If $B$ is stride-1 in $k$, then the factors $W_{kj}$ needed for fixed $k$ and varying $j$ are scattered. The fusion over $j$ is not available without packing, so Stage 1 remains tilewise and is implemented as a batched GEMM.

The same idea applies to the $i$ direction. For fixed $k$ the factors $V_{ik}^{T}$ are contiguous as $i$ varies, then stage 1 can then fuse $i$ into the GEMM $M$ dimension.

Combining the two levers gives the four layouts:

$A$ stride-1 axis	$B$ stride-1 axis	$k$-reduction	Stage-1 fusion	# (batched) GEMMs
$k$	$j$	folded into $K$; write-once	$j\to N$	$3$
$k$	$k$	folded into $K$; write-once	none; tilewise	$3$
$i$	$k$	looped over $k$; accumulate	$i\to M$	$2+n$
$i$	$j$	looped over $k$; accumulate	$i\to M,\ j\to N$	$2+n$

Here $n_k$ is the number of contraction tiles. The count refers to batched-GEMM launches for the $O_AO_B$ term. In the write-once family, the computation uses three batched GEMM stages: one for Stage 1, one for Stage 2, and one for the final update to $C$. In the accumulate family, the first two stages can still be grouped, but the final update must be performed once per contraction tile $k$, giving $2+n_k$ GEMM launches.

Output traversal and workspace budget

The previous discussion determines how the computation should be traversed. For each output tile $C_{ij}$, the intermediates $S_{ikj}$ and $T_{ikj}$ must be stored, or at least produced in a workspace large enough to feed the next GEMM stage. With a limited workspace budget for $S$ and $T$, the goal is to choose the largest panel of output tiles that can be processed without spilling or excessive packing.

The best traversal depends on whether the $k$-reduction can be folded into the final GEMM.

In the write-once family, $A$ is stride-1 in $k$. For fixed output row $i$, the factors $U_{ik}$ are contiguous as $k$ varies, so the whole $k$-sum can be folded into the GEMM contraction dimension. Thus, for a fixed row $i$ and a block of output columns $J$, Stage 3 has the form

\[C_{iJ} \mathrel{+}= \underbrace{ \begin{bmatrix} U_{ik_1} & U_{ik_2} & \cdots \end{bmatrix} }_{b\times K_r} \underbrace{ \begin{bmatrix} T_{ik_1J}\\ T_{ik_2J}\\ \vdots \end{bmatrix} }_{K_r\times |J|b},\]

where $K_r$ is the total rank over the contributing $k$ indices. Increasing $J$ increases the $N$ dimension of this GEMM and improves throughput. Thus the natural traversal order for $C$ is row by row. If the workspace is large enough, then several output rows $i\in I$ can be processed at once, giving a batched GEMM over the row block $I$.

In the accumulate family, $A$ is stride-1 in $i$. The axis $k$ is fused in Stage 1 and to increase the size of the GEMM we can compute $S_{Ikj}$ for a set of rows $I$, so the computation proceeds column-by-column. Here the key workspace decision is different. Since the final update is serial in $k$, a deeper block of contraction indices increases the number of times the same $C$ tile is read and written before moving on. Consequently, under a limited workspace budget, it is more effective to keep the active $k$-block small and allocate the remaining workspace to enlarging the free output dimension $J$. In practice, this means fixing a single $k$ at a time and partially updating as many $C_{ij}$ tiles as possible, processing tile columns first

Pseudocode

The write-once (row) family, at full budget:

# A stride-1 in k  ⇒  U_ik, V_ik contiguous over k for a fixed row i
# scratch:  S[r, r, n, |J|, |I|]     T[r, n, b, |J|, |I|]

for run (block of rows I × columns J) sized to the budget:

    # Stage 1 — S_ikj = V_ik^T W_kj,  batched over (i, k, j)
    #   B stride-1 j: j fused into N   |   B stride-1 k: tilewise
    batched_gemm('T','N',  1, V[i,k], W[k,j],  0, S[i,k,j])

    # Stage 2 — T_ikj = S_ikj Z_kj^T,  batched over (i, k, j)
    batched_gemm('N','T',  1, S[i,k,j], Z[k,j],  0, T[i,k,j])

    # Stage 3 — fold k into K: one write per output row i, batched over i
    for i in I:                                 # collected into ONE batched call
        Ustack_i = [ U_i1 | U_i2 | … | U_in ]   #  b × n·r   (contiguous view)
        Tstack_i = reshape(T[i, :, :, J])       #  n·r × |J|·b
    batched_gemm('N','N',  α, Ustack, Tstack,  β=1, C[I, J])

The accumulate (column) family, at full budget:

# A stride-1 in i  ⇒  V_ik contiguous over i  (i fuses into M)
# k cannot fold into K, so it is a serial loop in Stage 3

for run (block of contraction tiles K × columns J) sized to the budget:

    # Stage 1 — batched over (k, j); i fused into M (and j into N if B stride-1 j)
    batched_gemm('T','N',  1, Vpanel[k], W[k,j],  0, S[k,j])

    # Stage 2 — batched over (k, j)
    batched_gemm('N','T',  1, S[k,j], Z[k,j],  0, T[k,j])

    # Stage 3 — the reduction: loop k, accumulate (β=1); batch the free axes (i,j)
    for k in K:
        batched_gemm('N','N',  α, U[:,k], T[k],  β=1, C[:, :])   # distinct (i,j) tiles

Benchmark

The benchmark below (not exhaustive) shows indeed that A tile-row major and B tile column major (the ij Stride-1 axis combination) results in the largest speedup

Matrix size	Tile size $b$	Rank $r$	Dense (ms)	kj (ms)	kk (ms)	ik (ms)	ij (ms)
$1024 \times 1024$	64	16	21.878	15.892	30.210	13.131	9.101
$2048 \times 2048$	64	16	147.426	119.235	238.657	96.963	66.572
$3072 \times 3072$	64	24	493.884	585.493	939.301	484.963	364.823
$2048 \times 2048$	128	32	148.391	82.159	100.250	74.737	64.758
$4096 \times 4096$	256	64	1181.113	488.826	489.062	479.816	480.066
$2048 \times 2048$	32	8	149.807	405.434	585.653	323.768	226.776

Parametric Reachability Analysis in Julia

2025-08-21T00:00:00+00:00

Hey! This post summarizes my GSoC 2025 work with the JuliaReach organization on ReachabilityAnalysis.jl under the guidance of mentors Christian Schilling and Marcelo Forets.

Outline and Motivation
Example
Contributions Overview
References
Appendix

Outline and Motivation

In many safety-critical systems, it is often impossible to predict exactly how the system will behave due to uncertainties in initial states, inputs, or dynamics. Reachability analysis addresses this challenge by computing flowpipes that enclose all possible behaviors over time, allowing engineers to rigorously verify safety.

For example, imagine an autonomous car faced with a pedestrian suddenly stepping onto the road. Depending on its exact speed, distance to the pedestrian, and reaction delay, the car may need to brake immediately or steer around the obstacle, while also accounting for sensor errors. One could try to sample a range of initial speeds and positions and simulate the resulting trajectories to guide the decision. However, because the car’s dynamics are nonlinear, even small variations in initial conditions can lead to drastically different behaviors. Simulation alone therefore cannot provide the rigorous guarantees required for safety.

In the ReachabilityAnalysis.jl package, several algorithms are available to compute these enclosures for different types of dynamical systems with uncertain inputs and initial states, including hybrid systems.

During my project, I focused on a fundamental class of models: linear time-invariant (LTI) systems with uncertain parameters.
An LTI system describes the evolution of the state vector $x(t)$ under a fixed matrix $A$:

\[x' = A x\]

where $x \in \mathbb{R}^n$.

Such systems are widely used because they arise naturally when linearizing nonlinear models. In practice, however, the dynamics are rarely known exactly. Parameters in $A$ may be uncertain due to modeling errors, noisy measurements, and other sources of uncertainty. To capture this, we consider a parametric LTI system of the form:

\[x' = A x, \quad x(0) \in X_0, \quad A \in \mathcal{A}\]

Here:

$X_0$ is the set of possible initial states, reflecting uncertainty at $t=t_0$.
$\mathcal{A}$ is a set of possible system matrices, representing parameter uncertainty.

The goal is to compute a tight over-approximation of all trajectories that can arise from any choice of initial state in $X_0$ and any admissible dynamics in $\mathcal{A}$. This is significantly more challenging than the classical case with a fixed $A$, since the solution space must account for both state uncertainty and dynamics uncertainty simultaneously.

Huang et al. [1] introduced a dedicated algorithm for these parametric LTI systems with uncertain dynamics, which combines two modern set representations: matrix zonotopes for modeling uncertainty in the system matrix and sparse polynomial zonotopes (SPZs) for representing the reachable states.
The motivation for this choice becomes clear when we compare possible uncertainty models for $A$ and discuss how to best enclose the evolving states.

Why Matrix Zonotopes Instead of Interval Matrices?

A classical way to represent uncertainty in $A$ is through an interval matrix:

\[\mathcal{A} = \{ A \mid a_{ij} \in [\underline{a}_{ij}, \overline{a}_{ij}] \}\]

This representation assumes that each entry of the matrix can vary independently within its interval. While simple and well studied, this independence assumption can be overly conservative: it includes combinations of parameters that may never actually occur in practice, often resulting in loose over-approximations of the reachable set.

To address this, Althoff [2] introduced matrix zonotopes, which generalize standard zonotopes to matrices:

\[\mathcal{Z} = \{ A_0 + \sum_{i=1}^p A_i \alpha_i \;\mid\; \alpha_i \in [-1,1] \}\]

Here, $A_0$ is the center matrix, and the $A_i$ are generator matrices. Matrix zonotopes preserve correlations between matrix entries, unlike interval matrices that treat them as independent. This leads to significantly tighter enclosures for uncertain dynamics, making them a more accurate and efficient choice in reachability analysis.

Why Sparse Polynomial Zonotopes?

Once the dynamics are modeled with matrix zonotopes, the reachable states need a representation that can handle the resulting complexity without becoming overly conservative.
Huang et al. use sparse polynomial zonotopes for this task.

SPZs extend zonotopes with polynomial terms, allowing them to capture non-convex sets while remaining closed under Minkowski sums and linear maps: two core operations in many reachability algorithms.

For a more detailed description of SPZs, see [3]. For a friendly introduction, see Luca’s previous GSoC blog post.

Example

Now let’s test the algorithm with a simple 2D dynamical system:

\[x' = A x, \quad x(0) \in X_0, \quad A = \begin{bmatrix} -1 & -5 \\ -1 & -1 \end{bmatrix}.\]

In this case the origin is a stable focus, since the eigenvalues are

\[\lambda = -1 \pm i\sqrt{5},\]

so given an initial set $X_0$ the trajectories should rotate and shrink toward the origin.

We then compare two cases:

the dynamics are known exactly,
the dynamics are uncertain.

For the uncertain case, assume that we are unsure about one of the entries of $A$:

\[A \in \begin{bmatrix} [-1.1, -0.9] & -5 \\ 1 & -1 \end{bmatrix}.\]

This can be expressed as a matrix zonotope:

\[\mathcal{A} = \begin{bmatrix} -1 & -5 \\ 1 & -1 \end{bmatrix} + c \begin{bmatrix} 0.1 & 0 \\ 0 & 0 \end{bmatrix}, \quad c \in [-1,1].\]

Now we will set up the reachability problem using LazySets and ReachabilityAnalysis:

Step 1: Import the packages

using ReachabilityAnalysis
import IntervalMatrices   # required for internal calculations
using Plots

Step 2: Define the system matrices

# Nominal matrix
A0 = [-1.0 -5.0;
       1.0 -1.0]

# Matrix zonotope with one generator
AS = MatrixZonotope(A0, [N[0.1 0.0; 0.0 0.0]])

Step 3: Define the initial set

We initialize the initial conditions as a sparse polynomial zonotope:

X0 = SparsePolynomialZonotope(
    [1.0, 1.0], # center 
    0.1 * [2.0 0.0 1.0; 1.0 2.0 1.0], # independent generators
    0.1 * reshape([1.0, 0.5], 2, 1), # dependent generators
    [1 0 1; 0 1 3] # exponent
)

Step 4: Define the IVP

We can use the convenient macro @ivp to specify the initial states and uncertain dynamics:

prob1 = @ivp(x' = A * x, x(0) ∈ X0, A ∈ AS)

Step 5: Configure the reachability algorithm

We use the HLBS25 algorithm for systems with uncertain parameters:

# Time step and horizon
δ = 3 / 200
T = 3.0

# Algorithm setup
alg = HLBS25(
    δ = δ,
    approx_model = CorrectionHullMatrixZonotope(),
    max_order = 5,
    taylor_order = 5,
    reduction_method = LazySets.GIR05(),
    recursive = false,
)

Main parameters of HLBS25:

δ – time step
approx_model – discretization model (default: CorrectionHullMatrixZonotope)
max_order – maximum order of the SPZ (trade-off between accuracy and complexity)
taylor_order – truncation order of the Taylor expansion of the exponential
reduction_method – strategy to reduce the complexity of matrix zonotopes
recursive – whether to compute the exponential recursively or directly

For a full description of these options, refer to the documentation.

Step 6: Solve and visualize

# Solve
sol1 = solve(prob1, alg; T = T)

# Plot
p = plot(X0, title="Reachable Set")
for X in sol1
  plot!(set(X), vars=(1,2))
end

This produces the flowpipe, showing how trajectories evolve while accounting for both the initial uncertainty and the uncertainty in the dynamics.

To compare with the exact case, we can repeat the experiment with a matrix zonotope that has no generators, which corresponds to a fixed matrix $A$. The fully worked-out code can be found at the end of this page in the Appendix.

Figure 1: Reachable set over time for exact and uncertain dynamics. Every third reach set is plotted.

A Not-So-Successful Example

For small uncertainty the algorithm behaves well, but with larger uncertainty the over-approximation deteriorates. For example, if we choose a matrix zonotope with large uncertainty such as:

\[\mathcal{A} = \begin{bmatrix} -1 & -5 \\ -1 & -1 \end{bmatrix} + c \begin{bmatrix} 0.1 & 0.1 \\ 0.1 & 0.1 \end{bmatrix}, \quad c \in [-1,1].\]

The results look quite bad:

Figure 2: Reachable set over time for exact and uncertain dynamics. Every third reach set is plotted.

In this case we observe a strange behavior: the reach sets quickly bloat, growing faster than they contract around the fixed point. Interestingly, increasing the maximum order parameter seems to mitigate the bloating somewhat.

What is going wrong?

Together with my mentors, I investigated this issue for several weeks. The problem appears to stem from the repeated use of the reduce_order method. Keeping it brief, at each step the algorithm computes and applies the matrix zonotope exponential $e^{\mathcal{A}}$ to propagate the state set forward in time. This increases the number of generators in the SPZ, forcing order reduction to keep the complexity manageable. However, repeated reduction seems to discard generators that capture important information, while the remaining ones grow excessively under successive exponentials.

This is quite puzzling, since reduce_order works well in other parts of the library. At this point it is still unclear to us whether this instability reflects a deeper stability issue, perhaps some relationship between the amount of uncertainty and the step size, similar to time-stepping constraints in ODE solvers, or whether it comes from a subtle bug in the implementation of one of the many building blocks. What is certain is that the issue seems specific to this algorithm, which is still very new and, before our work, had only been implemented in the library CORA.

What’s next?

After GSoC, we made a plan to further investigate the problem and eventually turn the algorithm into a stable release. I have also implemented the non-homogeneous case $x' = \mathcal{A}x + \mathcal{B}u$. However, it is not ready for release yet, since some implementation details still require further discussion with the mentors.

Contributions Overview

In the tables below I summarize my contributions to the different packages in the JuliaReach ecosystem to implement the reachability algorithm described above.

1. `LazySets.jl`: Matrix Zonotopes

PR Title	PR #	Category
Add `overapproximate` for matrix zonotope exponential	#4000	Feature
Add operations on matrix zonotopes	#3999	Feature
Add `overapproximate` for matrix zonotope multiplication	#3996	Feature
Preserve `indexvector` in linear map for MZ	#3985	Fix
Extend `ExponentialMap` to support `MatrixZonotope`s	#3970	Feature
Add `linear_map` between MatrixZonotope and SPZ	#3969	Feature
Fix in-place scaling for `MatrixZonotope`	#3967	Fix
Add methods and type for `MatrixSets`	#3966	Feature
Add `norm` and `overapproximate_norm` for matrix zonotope	#3941	Feature
Refactor and extend `MatrixSets` module	#3933	Refactor

2. `LazySets.jl`: General improvements and fixes

PR Title	PR #	Category
Optimize `remove_redundant_generators`	#3998	Feature
Improve `remove_redundant_generators` for `SPZ`	#3986	Improvement
Add `overapproximate` for exponential map for `SPZ` and `Zonotope`	#3979	Feature
Fix `isuniversal` and constructor for `Polygon`	#3978	Fix
Preserve ID in `minkowski_sum` and `cartesian_product` between `SPZ` and `Zonotope`	#3977	Improvement
Make `overapproximate` of ASPZ with `UnionSetArray{Zonotope}` more robust	#3972	Improvement
Add overapproximation of the l1 norm of a `Zonotope`	#3925	Feature
Faster l1 norm for `AbstractZonotope`	#3924	Improvement
Add `scale` for `SPZ`	#3908	Feature
Add `merge_id` and generalize `exact_sum` for `SPZ`	#3905	Feature
Add sampler for sparse polynomial zonotopes	#3847	Feature

3. `MathematicalSystems.jl` and `ReachabilityAnalysis.jl`

PR Title	PR #	Notes
Add `parametric` systems	#332	Feature
Add HLBS25 algorithm for linear parametric systems	#931	Feature

References

[1] Yushen Huang, Ertai Luo, Stanley Bak, Yifan Sun, Reachability analysis for linear systems with uncertain parameters using polynomial zonotopes, Nonlinear Analysis: Hybrid Systems, Volume 56, 2025, 101571, ISSN 1751-570X. DOI

[2] Matthias Althoff, Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars, PhD thesis, Technische Universität München, July 2010.

[3] Niklas Kochdumper, Matthias Althoff, Sparse Polynomial Zonotopes: A Novel Set Representation for Reachability Analysis, IEEE Transactions on Automatic Control, Vol. 66, No. 9, Sept. 2021, pp. 4043–4058. DOI

Appendix

using ReachabilityAnalysis
import IntervalMatrices
using Plots
N = Float64

A0 = N[-1 -5;
        1 -1]
AS = MatrixZonotope(A0, [zeros(2,2)]) 

# Initial set
X0 = SparsePolynomialZonotope(
    N[1.0, 1.0],
    N(0.1) * N[2.0 0.0 1.0; 1.0 2.0 1.0],
    N(0.1) * reshape(N[1.0, 0.5], 2, 1),
    [1 0 1; 0 1 3]
)

# Two problems: no variation vs. small generator variation
prob1 = @ivp(x' = A * x, x(0) ∈ X0, A ∈ AS)

AS = MatrixZonotope(A0, [N[0.1 0.1; 0.1 0.1]])
prob2 = @ivp(x' = A * x, x(0) ∈ X0, A ∈ AS)

δ = N(3) / 200
T = 3.0

alg = HLBS25(
    δ = δ,
    approx_model = CorrectionHullMatrixZonotope(),
    max_order = 5,
    taylor_order = 5,
    reduction_method = LazySets.GIR05(),
    recursive = false,
)

sol1 = solve(prob1, alg; T = T)
sol2 = solve(prob2, alg; T = T)

# plotting function
function plot_flowpipe(sets, X0; kwargs...)
    p = plot(; kwargs...)
    for (i,s) in enumerate(sets)
        if i%3 ==0
            plot!(p, set(s); vars=(1,2), alpha=0.3, lw=0.5)
        end
    end
    return p
end

p1 = plot_flowpipe(sol1, X0,
    title = "Flowpipe: exact A",
    xlabel = "x₁", ylabel = "x₂",
    legend = true)

p2 = plot_flowpipe(sol2, X0, 
    title = "Flowpipe: uncertain A ",
    xlabel = "x₁", ylabel = "x₂",
    legend = true)

# common limits for better comparison
xlims_common = (min(xlims(p1)..., xlims(p2)...), max(xlims(p1)..., xlims(p2)...))
ylims_common = (min(ylims(p1)..., ylims(p2)...), max(ylims(p1)..., ylims(p2)...))
plot!(p1; xlims=xlims_common, ylims=ylims_common)
plot!(p2; xlims=xlims_common, ylims=ylims_common)

plot(p1, p2, layout=(1, 2), size=(1000, 420))
savefig("reach_comp.png")

Operand	Tile-column-major	Tile-row-major
\(A_{ik}\)	\(i\)	\(k\)
\(B_{kj}\)	\(k\)	\(j\)

\(A\) stride-1 axis	\(B\) stride-1 axis	\(k\)-reduction	Stage-1 fusion	# (batched) GEMMs
\(k\)	\(j\)	folded into \(K\); write-once	\(j\to N\)	\(3\)
\(k\)	\(k\)	folded into \(K\); write-once	none; tilewise	\(3\)
\(i\)	\(k\)	looped over \(k\); accumulate	\(i\to M\)	\(2+n\)
\(i\)	\(j\)	looped over \(k\); accumulate	\(i\to M,\ j\to N\)	\(2+n\)

Matrix size	Tile size \(b\)	Rank \(r\)	Dense (ms)	kj (ms)	kk (ms)	ik (ms)	ij (ms)
\(1024 \times 1024\)	64	16	21.878	15.892	30.210	13.131	9.101
\(2048 \times 2048\)	64	16	147.426	119.235	238.657	96.963	66.572
\(3072 \times 3072\)	64	24	493.884	585.493	939.301	484.963	364.823
\(2048 \times 2048\)	128	32	148.391	82.159	100.250	74.737	64.758
\(4096 \times 4096\)	256	64	1181.113	488.826	489.062	479.816	480.066
\(2048 \times 2048\)	32	8	149.807	405.434	585.653	323.768	226.776

Alessandro Carraro

Tile-Low-Rank Matrices in NextLA.jl

Table of Contents

Introduction

My contribution

Two TLR variants

Packing variable-rank tiles

Compression with ARA

GEMM on compressed operands

Workspace is part of the schedule

Returning a compressed result

Results

Using the implementation

References

TLR Matrix Multiplication

Table of Contents

Introduction: TLR GEMM

Fixed Rank GEMM: \(\mathrm{ dense} \leftarrow \mathrm{TLR}\times \mathrm{TLR}\)

Regular TLR GEMM

The easy terms

The \(O_A O_B\) terms

The stride-1 axis

Lever 1: \(A\)’s layout determines how the \(k\)-sum is performed

Lever 2: \(B\)’s layout determines whether Stage 1 fuses over \(j\)

Output traversal and workspace budget

Pseudocode

Benchmark

Parametric Reachability Analysis in Julia

Table of Contents

Outline and Motivation

Why Matrix Zonotopes Instead of Interval Matrices?

Why Sparse Polynomial Zonotopes?

Example

Step 1: Import the packages

Step 2: Define the system matrices

Step 3: Define the initial set

Step 4: Define the IVP

Step 5: Configure the reachability algorithm

Step 6: Solve and visualize

A Not-So-Successful Example

What is going wrong?

What’s next?

Contributions Overview

1. LazySets.jl: Matrix Zonotopes

2. LazySets.jl: General improvements and fixes

3. MathematicalSystems.jl and ReachabilityAnalysis.jl

References

Appendix

Introduction: TLR `GEMM`

Fixed Rank `GEMM`: \(\mathrm{ dense} \leftarrow \mathrm{TLR}\times \mathrm{TLR}\)

Regular TLR `GEMM`

1. `LazySets.jl`: Matrix Zonotopes

2. `LazySets.jl`: General improvements and fixes

3. `MathematicalSystems.jl` and `ReachabilityAnalysis.jl`