Clarify domain names and functional boundaries in oneMKL spec

[vmalia]

Problem Description

When I started looking into #561, there were more questions about how to name Sparse domain correctly.

Investigation

1. It was discovered that SPBLAS and SPARSESOLVERS seem to be 2 major distinctions in how sparse functionality is developed (and consumed?).
2. It was also found that the oneAPI specification currently mentions a mix of both these terminologies, mostly interchangeably, which does not seem to be desirable as per the above point.

Recommendation/Suggestion

1. Rename and/or split sparse domain into SPARSESOLVERS and SPBLAS.
2. Explicitly define the boundary between these domains.
3. Explicitly define the naming that should be used across headers, macros, namespaces or any other alignment purpose for these domains. If this is required for other oneMKL domains too, then it needs to be discussed and understood.

[spencerpatty]

To me it is rather clear

Sparse linear algebra consists of two domains: sparse blas and sparse solvers. Each is a oneMKL domain and at least to me, the differences between the two domains is clear. It is similar to BLAS vs LAPACK on dense side. One consists of basic fundamental kernels involving a sparse matrix and other dense vectors/dense matrices/sparse vectors/sparse matrices. The other consists of many different kind of (direct, eigen, iterative) - solvers that use one or more sparse matrices as the standard operand.

The namespace for both sparse blas and sparse solvers domains is currently chosen to be "oneapi::mkl::sparse::" which lends to them being separate but interoperable ( we don't benefit from common pointer array or mdspan definition of sparse matrix, like dense linear algebra does, so we must define an object for the sparse matrix) and both could be used in an algorithm on the same sparse matrices. There is some suggestion that we call the namespace "spblas" for both sparse blas and sparse solvers because sparse is rather generic, but within the "oneapi::mkl::sparse" heirarchy, there is little chance of name collision using generic term "sparse", so it is acceptable to me as a representative namespace for both domains to share in.

What else needs to be clarified ?

[spencerpatty]

In reality, we might separate it into three domains in Sparse Linear Algebra:

• sparse blas -- fundamental kernels involving at least one sparse matrix and other dense matrices, sparse vectors and/or dense vectors. (sometimes is extended to include a single step application of basic preconditioners like GMRES, SSOR, ILU etc for a sparse matrix system "Ax=b")
• iterative sparse solvers (algorithms like PCG, GMRES, krylov solvers, etc that converge to true solution to sparse matrix system "Ax=b" or eigen system "Ax = lambda Bx" over time (with repeated application of algorithm)
• direct sparse solvers (algorithms like LU, cholesky, QR, etc) that compute the solution directly through some clever algorithm application of matrix elimination the solution to a sparse matrix system "Ax=b" or eigensystem "Ax = lambda B x". (sometimes is followed up with some iterative refinement for better accuracy and stability)

and there may come a time when we want to distinguish between all of these in the specification and product as different domains, but they should all be interoperable in practice, so it makes sense to share a namespace and to me, "oneapi::mkl::sparse" is as good as any other name to do so.

[vmalia]

@spencerpatty that helps a lot. I believe that we have sparse blas available in the description in the spec: https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.3-rev-1/elements/onemkl/source/domains/domains#sparse-linear-algebra but the two types of solvers are not, which is fine. It can be an extension later on in the spec, as required.
Thank you!

[vmalia]

Sorry, reopened. It also came up that the statistics domain does not have a namespace. @paveldyakov can you please help understand?

[paveldyakov]

Sorry, reopened. It also came up that the statistics domain does not have a namespace. @paveldyakov can you please help understand?

I think it is also covered by #577 (comment)
We will fix it