[GSoC] Feature: Jacobi preconditioner on GPU and CUDA Unified preconditiong matrix

[ddg93]

Proposed Changes

This draft PR introduces CUDA Unified memory allocation and management for the preconditioning matrix inside the Jacobi preconditioner.

The Jacobi preconditioner calculations are performed on GPU through a new custom CUDA kernel through the preconditioner abstraction.
The preconditioning matrix is selected to test CUDA Unified Memory allocation and asynchronous prefetching to the GPU.
For simplicity, the double CPU/GPU pointer is still maintained in the current logic, although the device pointer reduces to an alias for the Unified Memory pointer when this kind of allocation is adopted.

This strategy introduces a simple context to test the CUDA Unified Memory usage and study the possibility of overlapping memory transfers and calculations without the need to introduce CUDA streams.

Concretely, this PR:

• introduces new CUDA Unified Memory allocation methods and asynchronous prefetching;
• introduces the GPU logic for the Jacobi preconditioner;

This work is part of my ongoing contribution during the Google Summer of Code 2026 program.

Validation

Validated locally with:

• serial CUDA build compilation
• serial CPU build compilation
• CPU/GPU numerical comparison on 1 representative case (rae2822) tested with LINEAR_SOLVER_PREC=JACOBI.

Nsys profiling was performed to confirm the asynchronous prefetching of the CUDA Unified Memory preconditioning matrix on my local GPU. Partial prefetching is observed, although page faults were reported during the preconditioner CUDA kernel, indicating that the calculations were slowed down by the prefetching matrix still being transferred to the GPU. This overlap is expected to largely improve on more modern hardware; tests are ongoing in the cloud.

Related Work

The Jacobi preconditioner kernels come from the PR #2825.

Observed Issues

Some issues were observed during this first period of GSoC:

• PR Add initial end-to-end CUDA FGMRES solver path #2825 compiles with CUDA 13.3 but CUSPARSE calls raise an unknown operation at the first matrix-vector product.
• the build.meson file has a hard-coded CUDA arch.
• the HAVE_MPI flag is not being passed to the nvcc compiler in the develop branch. This raises a linking error if MPI operations are included within the *.cu files. That is not the case in the master branch.

Next steps

I propose to continue working on the following steps:

• perform further testing on the asynchronous prefetching of the preconditioning matrix;
• extend the CUDA Unified Memory allocation to the CSysVector class and, possibly the CSysMatrix class;
• I observe that CSysMatrixVectorProduct object in the FGMRES solver is the Jacobian matrix. If the Jacobian preconditioner is applied, the preconditioning matrix is also calculated from the Jacobian matrix. It would then be convenient to issue the transfer of the Jacobian matrix to the GPU inside the building of the preconditioner and perform the preconditioning matrix calculations on the GPU (sparse matrix inversion based on the current LU decomposition). Then, the preconditioning matrix would already be on the GPU, reducing by one the number of transfers from CPU to GPU. This is not the current case as both the Jacobian matrix and the preconditioning matrix are being transferred to device.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• [ X] I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• [X ] My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

[bigfooted]

That's great!
Can you run pre-commit to fix the code style/formatting?

[pcarruscag]

I think Areen looked into unified memory a bit.
Do you have some performance measurements? I imagine we save on the data transfer but suffer a little on the kernel performance?
Does unified memory introduce a significant restriction in terms of the required compute capability?