rocsparse_spsv not implemented for triangular matrices

[jakub-homola]

What is the expected behavior

The docs state, that "rocsparse_spsv_solve solves a sparse triangular linear system ...". Calling the rocsparse_spsv with a triangular sparse matrix (that is, a rocsparse_spmat_descr where I set the attribute rocsparse_spmat_matrix_type to rocsparse_matrix_type_triangular) should work without issues and not return an error.

What actually happens

The function exits with error 2, corresponding to rocsparse_status_not_implemented.

How to reproduce

Probably not needed, will provide simple example if necessary

Environment

all

The most probable cause is e.g. this line of code, which makes the function accept only general matrices, triangular matrices fail with the error. This is present in other functions too.

Hipyfying (or roc-ifying) from cuSPARSE, where the matrix_type and storage_mode attributes do not exist at all, it might make sense to also accept general matrices. But it is weird that only general matrices are accepted. When working just with rocsparse, this behaviour is very unexpected. Why does the matrix_type attribute even exist, when using it breaks the code?

[YvanMokwinski]

Hello Jakub,

We are aware of this restrictive condition and we are planning to remove it soon.

The matrix type indicates if the matrix is general, symmetric, hermitian or triangular https://github.com/ROCmSoftwarePlatform/rocSPARSE/blob/develop/library/include/rocsparse-types.h#LL251C1-L259C26

When using spsv the matrix type general implies that a lower triangular part, a upper triangular part and a diagonal matrix are stored in one general sparse matrix. Then with the use of an appropriate fill mode https://github.com/ROCmSoftwarePlatform/rocSPARSE/blob/develop/library/include/rocsparse-types.h#LL286C1-L290C23 and an appropriate diagonal type https://github.com/ROCmSoftwarePlatform/rocSPARSE/blob/develop/library/include/rocsparse-types.h#LL270C1-L274C23 the user has all the flexibility to use a triangular solver on a triangular matrix stored in this way.

We already have noticed it wasn't making sense of not accepting triangular matrices, your comment will raise the priority for solving this issue.

Thank you.