gouarin
commented
4 years ago Hi @tkloczko,
thanks for your message!
Each scheme should be able to give the sparse N-D array in another scheme. I agree with you it's generally the solver which gives you the scheme to use. But since we have conversion tools, we should be able to communicate with the different layers that you can find in linear algebra. There are a lot of libraries in linear algebra (umfpack, superlu, hypre, ...) and it's a difficult topic. So the idea is not to write linear solvers but to build interfaces to these libraries with the good scheme and the good memory layer.
Let me know if I don't well understand your message.
tkloczko
JohanMabille
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.