gko::ext::cuda::solver::Cudss#

Wraps NVIDIA’s cuDSS sparse direct solver as a Ginkgo LinOp. The factorisation is computed during generate() and reused across subsequent apply() calls; the factorisation data is opaque and held inside the cuDSS handle.

Only runs on CudaExecutor, and only supports float, double, std::complex<float>, and std::complex<double> value types. The matrix_type and matrix_view factory parameters must be set consistently with how the input CSR is stored — see the parameter docs below for the details and the matrix_type warning.

For an introduction to the extension, see the cuDSS extension page.

template<typename ValueType, typename IndexType = int32>
class Cudss #

Inherits from

A direct solver using NVIDIA’s cuDSS library.

This solver is only supported on the CudaExecutor. It wraps the cuDSS sparse direct solver, performing analysis, factorization, and solve phases. The factorization is computed during construction (generate) and reused across apply calls.

The solver is opaque — factorization data is stored internally in cuDSS-native format and cannot be extracted.

Template Parameters:

  • ValueType – the value type of the system matrix and vectors

  • IndexType – the index type of the system matrix

Public Functions

Cudss(const Cudss&)#

Creates a copy of the solver (shares factorization state).

Cudss(Cudss&&) noexcept#

Moves from the given solver, leaving it empty.

void refactorize(std::shared_ptr<const LinOp> new_matrix)#

Re-run the numeric factorization with updated matrix values.

The new matrix must have the same sparsity pattern (dimensions and number of non-zeros) as the matrix used in generate(). Only the numeric factorization phase is re-executed; the symbolic analysis from the initial generate() is reused.

Parameters:

new_matrix – the updated system matrix (same sparsity pattern)

Public Static Functions

static parameters_type parse(
const config::pnode &config,
const config::registry &context,
const config::type_descriptor &td_for_child = config::make_type_descriptor<ValueType, IndexType>(),
)#

Parse parameters from a configuration property tree.

static config::configuration_map get_config_map()#

Returns a configuration_map for registering this type with a config::registry. Users can pass this to the registry constructor to enable JSON/YAML configuration of Cudss.

struct parameters_type #

Inherits from

Public Members

int matrix_type#

cuDSS matrix type, mapping to cudssMatrixType_t:

  • 0 = GENERAL (unsymmetric)

  • 1 = SYMMETRIC (real symmetric)

  • 2 = HERMITIAN (complex Hermitian)

  • 3 = SPD (symmetric positive definite)

  • 4 = HPD (Hermitian positive definite)

Warning

Ginkgo’s gko::matrix::Csr stores the full matrix. cuDSS expects that when matrix_type is SYMMETRIC / HERMITIAN / SPD / HPD, the supplied CSR contains only the triangle indicated by matrix_view (plus the diagonal). Passing a fully-stored symmetric matrix with one of these types is not the documented input contract and can produce incorrect results. To use the symmetric factorizations, extract the upper or lower triangle into a new CSR before constructing the solver. For a fully-stored matrix, use GENERAL (0) together with matrix_view = FULL (0).

int matrix_view#

cuDSS matrix view, mapping to cudssMatrixViewType_t:

  • 0 = FULL (entire matrix stored in CSR)

  • 1 = LOWER (only strictly-lower + diagonal stored in CSR)

  • 2 = UPPER (only strictly-upper + diagonal stored in CSR)

This tells cuDSS what the CSR data actually contains; it is not a filter applied to a fully-stored matrix. Use FULL (0) for unsymmetric matrices and when passing a fully-stored symmetric matrix with matrix_type = GENERAL. Use LOWER / UPPER only when the CSR itself stores just that triangle (in combination with matrix_type SYMMETRIC / HERMITIAN / SPD / HPD). See the matrix_type warning above.

int reordering_alg#

Reordering algorithm. 0=default.

bool hybrid_execute#

Enable hybrid host/device execution.

bool hybrid_memory#

Enable hybrid CPU+GPU memory.