Interaction between Permutation and Reordering classes

[pratikvn]

When trying to run some experiments on the effects on reordering on SpMV performance and trying to add a new reordering class with metis (fill reduce ordering), I found a few things which were a bit unexpected:

1. Reordering outputs/stores a Permutation object. As it does not have an apply method (this was intentional), you need to call get_permutation()->apply(...). But by default, the permutation only permutes the rows. For the use cases I can think of (reducing fill-in, or improving cache hit rates or improving preconditioner quality), you need to additionally permute by columns as well. So, I think we should make the default mask for the permutation (row_permute | column_permute ).

2. Our RCM class and even the Metis API has options that compute an inverse permutation explicitly. Our permutation also has an option of doing an inverse_permute with a provided permutation array. We could technically remove the computation of the inverse permutation and just store one immutable array and create two permutation objects with different masks.

3. Another issue is reordering different objects. For CSR and our usual matrix objects, it makes sense to re-order columns, but for vectors, there is no real meaning in reordering columns ? Right now, we don't differentiate between MultiVector and Dense, so this might be something we will want to tackle when addressing Clarify the behavioral differences between a dense matrix and a multivector #796. For MultiVector, it might make sense to just do nothing when permuting through the reordering interface (there from the inputs, they are non-commutable, anyway).

[upsj]

Are you familiar with the reordering interface design for sparse direct solvers we are currently using? That would take care of 3. directly, and potentially also 2. I already discussed 1. in #940, and would suggest revamping the entire reordering/permutation setup in 2.0

[pratikvn]

@upsj, thanks. Looks like these issues have already been noted are are being worked on.

[upsj]

Yes, the new interface is under development right now.

[upsj]

Let's have a single place where we talk about this interface: #940