Handle runtime scheme policy #46
Description
Hi guys,
.
Firstly, I would like to tell you that the work you have already done is very interesting. I read the paper about the different format mentioned in #21 . It gives nice ideas to drive the architecture.
I also read the sources, the notion of scheme is a great way to customize the different storage models. However, when using such a design in, for instance, a FE code, some drawbacks can arise.
Typically, it is natural to build the matrix of the linear system using a map scheme. Then, according to the solver of the linear system, one needs to convert to either CSR, COO or another format. This is not quite difficult. But in case of the choice of the solver is done at runtime, using the current design is not possible since you don't know at compile time the type of scheme you need to tackle the solver that will be used.
This is the same drawback that led to conceive the std polymorphic allocator. You don't want to recompile the code every time you need to change the allocation policy. It is the same problem with the sparse scheme. In our experience, we realized that it was the solver that drives in general the scheme policy.
In terms of architecture, it is of course much involved. The sparse array or tensor can be composed by an abstract scheme (no more template parameter is needed I think) implemented by the concrete schemes but you then need abstract nz iterators which can lead to a lack of performance. However, it is still possible to "extract" the concrete scheme when performance is required.
We did a similar design few years ago in the context of distributed sparse linear algebra (in the sense of MPI). It would be great to see how this former work could fit with your brand new architecture.
See you,
Cheers,
Thibaud.