Harden host-side sparse index width and allocation safety

[LwhJesse]

Proposed Changes

Introduce su2_index_t as the host-side sparse index type:

using su2_index_t = std::uint64_t;

Use it through the host sparse-pattern path, including graph-toolbox aliases, geometry sparse-pattern accessors, CSysMatrix LDU metadata, CSysVector dimensions, and PaStiX sparse input handling.

Add checked arithmetic for sparse storage sizes and checked casts at external boundaries. CUDA device sparse indices remain su2uint; host indices are checked before upload.

This prevents silent overflow or truncation in large host-side sparse matrices. On LLP64 platforms, unsigned long is 32-bit, so products such as nnz_blocks * nVar * nEqn can wrap before allocation. For example, a 5 x 5 double block matrix crosses the 32-bit unsigned limit at:

171,798,692 * 25 = 4,294,967,300 entries
4,294,967,300 * 8 bytes = 34,359,738,400 bytes

The affected paths now fail explicitly instead of allocating with wrapped sizes.

Related Work

Keeps the LDU/custom-kernel direction discussed in #2838. This does not replace the current CUDA sparse backend with cuSPARSE.

Validation:

• git diff --check
• uvx --python 3.10 pre-commit run -a -v
• ninja -C build
• ninja -C build-verify-cuda
• ninja -C build-verify-pastix
• ninja -C build-harness-omp-cpu
• periodic2d OpenMP regression, SU2_CFD -t 2, passed at iteration 1400 within 1e-4
• fea_topology/quick_start/settings.cfg, SU2_CFD, completed with Exit Success

PR Checklist

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• 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.

[LwhJesse]

After #2816, I think the follow-up direction needs a policy decision before I move #2822 or the resource-cache draft further.

I currently have two related follow-ups:

• #2822 is the host-side sparse-index / allocation-safety draft.
• The #2816-based resource-cache draft is the cuSPARSE resource-lifetime follow-up.

The next steps depend on which CUDA sparse-backend direction the project prefers. I see four practical routes:

1. Modern cuSPARSE-only route: keep the generic cusparseSpMV() BSR path from #2816, require CUDA/cuSPARSE 13.1+ for that backend, add a clear configure/build guard for unsupported CUDA/cuSPARSE 13.0 or older versions, and move both host and device sparse indices to fixed 64-bit.

2. Transitional host-side hardening route: keep #2822 limited to host-side sparse-index hardening. Host indices become fixed 64-bit, while the current CUDA boundary keeps its existing index type with checked conversion.

3. Split-backend compatibility route: keep the modern generic cuSPARSE BSR path for CUDA/cuSPARSE 13.1+, but add a CUDA/cuSPARSE 13.0-or-older fallback. That fallback could be either the legacy int32 BSR API, or a corrected custom CUDA kernel.

4. Full custom-kernel route: move away from the generic cuSPARSE BSR path and maintain a corrected SU2 custom CUDA matvec kernel instead. This would avoid the CUDA/cuSPARSE 13.1+ requirement, but it would also change the direction of the #2816-based resource-cache draft.

My technical preference is route 1, because it gives the cleanest correctness story and the cleanest future GPU-resident Krylov path. If that is too large as the immediate next step, route 2 is a reasonable limited scope for #2822.

Could the maintainers confirm which direction they prefer before I mark #2822 ready or move the #2816-based resource-cache draft into the main project?

[pcarruscag]

I think both are going too deep into the software engineering weeds.
I would see an end-to-end linear solve on GPUs, product, preconditioner, vector-vector operations, before we start worrying about these portability and caching aspects.

[pcarruscag]

I think that the su2uint I introduced addresses this, and we have custom kernels for almost everything now, since we switched to the LDU format.
So this work is probably not needed anymore? What do you think?

[LwhJesse]

I think that the su2uint I introduced addresses this, and we have custom kernels for almost everything now, since we switched to the LDU format. So this work is probably not needed anymore? What do you think?

I checked the current develop again. The specific overflow risk this PR addresses still exists independently of the CUDA sparse backend.

su2uint fixes the sparse pattern index type at 32 bits, but the host-side storage size is still computed from expressions such as nnz_l * nVar * nEqn and passed through unsigned long. On Windows LLP64, unsigned long is 32-bit, so the block pattern itself can fit in 32 bits while the scalar-entry count overflows.

For example, 171,798,692 * 5 * 5 = 4,294,967,300, which is just above UINT32_MAX. That can wrap before allocation even though nnz_l itself is valid.

So the switch to LDU/custom CUDA kernels removes the old cuSPARSE-related concern, but it does not remove this host-side allocation/index-width issue.