Library title and structure

[tbetcke]

Some thoughts about the structure of the library:

• sparse-traits: All interfaces and trait definitions
• sparse-core: Common sparse matrix implementations, vectors, etc. Essentially a minimum viable product of a sparse-matrix library
• sparse-algorithms (not yet there): Iterative solvers, etc. that can function by purely accessing the interfaces in sparse-traits. This allows the algorithms to be as generic as possible over the underlying structures.

@krishnakumarg1984 and I have started experimenting with implementations for sparse-core. One thing I'd like to do is for the library to be able to compile with or without MPI. For that I have created two modules distributed and local. Any code that relies on MPI is in distributed. Is this sensible?

Also, we need a good library name :-) Sandbox is not too promotional.

[jedbrown]

Yeah, MPI is a clumsy dependency, especially in Rust land. It's typical for a distributed sparse matrix to have two sequential matrices, one for the diagonal block and one for the off-diagonal block. For PDE-type applications, most everyone uses 1D decompositions (usually row partitioning), but for irregular operations (like social network graphs or bundle adjustment), there are benefits to supporting 2D decompositions (like CombBLAS uses, often in a randomized ordering, which gives up data locality in exchange for load balancing).

I'm not sure it's important at this time to have separate crates for traits and core. In any case, I think they should live in the same repository and we can decide later which crates to make public.