Adding Functionality needed by openCARP

[fritzgoebel]

So far, I think we are missing the following functionalities:

• diagonal scaling: openCARP needs to compute LMR where L and R are diagonal matrices. This could potentially be done with a new diagonal matrix format

• matrix axpy: openCARP needs to compute a * A + b * B. This is not trivial as it potentially changes the sparsity pattern, if new zero entries occur even to something else that the union of the sparsity patterns of A and B

• extract the diagonal from a matrix

• initialize a matrix with all zeros

Any ideas / comments on how to handle a diagonal matrix format?

[upsj]

Matrix axpy: For sparse matrices that's called spgeam and we already have an implementation hidden inside the HIP advanced spgemm and I could easily add it for the other executors as well. We only need to figure out how to represent/call it. If you call advanced Csr->apply(alpha, Identity, beta, Csr) maybe?

[fritzgoebel]

Matrix axpy: For sparse matrices that's called spgeam and we already have an implementation hidden inside the HIP advanced spgemm and I could easily add it for the other executors as well. We only need to figure out how to represent/call it. If you call advanced Csr->apply(alpha, Identity, beta, Csr) maybe?

Your representation makes sense, it would be awesome if you could add this :)

[pratikvn]

For diagonal scaling: I see two approaches:

1. Add a new diagonal matrix format as you suggest.
2. Add a diagonal scaling operation to all the matrix formats.

I personally think the second approach might be better because it would be easier to implement and I dont see any particular reason to add a new format for representing a diagonal matrix format. Additionally, you would also need to implement conversions from one diagonal to all other formats and vice versa which I am not sure is such a good idea. The diagonal scaling operation could look like :

auto mat = gko::matrix::Csr<>::create(...);
auto scaled_matmat = gko::matrix::Csr<>::create(...);
auto diag = gko::Array<>{exec, {values}};
mat->scale_diagonal(lend(diag), lend(scaled_mat));

You could similarly have a extract diagonal operation. I think we already have some similar kernels for the CSR format within the ParIX classes .

[upsj]

The reason I would prefer a diagonal matrix type is that it better matches with Ginkgo's position as a linear operator library. When we add special functions for these kinds of features, we can't use them within solvers, compositions, combinations etc.

[tcojean]

I agree with Tobias here, it's always nice to be able to combine things in a transparent fashion, whereas adding new interfaces somewhat destroy that workflow.

[pratikvn]

Okay, then I guess it might be better to add a diagonal matrix format. But in any case the extracting of the diagonal would need to be specific to the different matrix formats.

[fritzgoebel]

Okay, then I guess it might be better to add a diagonal matrix format. But in any case the extracting of the diagonal would need to be specific to the different matrix formats.

Yes, I started implementing the extraction of the diagonal.

[upsj]

This was all implemented with #563 and #580 and #702 (fill)