Dear all,

I would like introduce FSPARSE, which is a library I started to put together for facilitating handling sparse matrices with a minimal OOP touch for data-containment in a pure Fortran environment.

While the project is still very much a **work in progress** it already contains:

- Types for COO/CRS/CSC/ELLPACK formats
- Several matvec kernels, including for some symmetric representations
- Transformation between dense<>COO ; COO<>CSR

Before pushing any further I decided to announce it in order to get some early feedback on the architecture, and see if there are some interested contributors that would like to join and help get this in shape for the rest of the community

The idea(s) Iām striving for:

- It shall be a modern approach such that any new comer to the topic can come here to learn (in a Fortranic manner) how to manipulate sparse matrices. Meaning: first use it, then learn how it works. (Ć la scipy.sparse from where I got a lot of inspiration)
- It shall contain kernels that are performant enough such that it can be used as is, yet easy enough that it can be readable and understandable ā¦ Not always easy but well, one can always try ā¦ extendable such that one can chose to use any of the already available libraries out there to replace/bypass the kernels ( Eigen, PSBLAS, PETSc, etc ). So, to use the library as a data-descriptor and let other libs do the heavy-lifting.

This idea is being discussed on the stdlib side as well, I just felt such a project would benefit from some āfreedomā for testing ideas and once a higher maturity is reached, make the migration to stdlib.

There are several TODOs, from which I thought about a few that would be very helpful:

- Discuss the OOP design (not the fact of using OOP please, but the chosen architecture and how to minimize pitfalls and maximize user-friendliness maintaining performance ā¦ the current design comes from a working implementation I already use for HPC code and that has proven quite versatile but Iām looking for challenging it)

Ex: as you will see in the readme, I decided to create several types per matrix like:

```
|Matrix type |no data|float |double |
|COO |`COO_t`|`COOr32_t`|`COOr64_t`|
```

Why a āno dataā? some times one just wants to do āgraphā or topological transformations without needing to worry about attributes, if so, this āno dataā offers a light-weight container with only the connectivity. Does it look reasonable? Would you have done differently?

- Include in the lib a modern version of the MatrixMarket and Harwell-Boeing files formats: This would then enable using for instance the http-client for easy benchmarking, and unit-testing.
- Suggestions for the unit tests.
- Complete the conversion between types. Yet to implement for instance COO<>ELL.
- Add basic (modernized) renumbering algorithms (CM / RCM / GPS)
- Other ideas?

As mentioned in the title, this is a call for contributors, so you are very much welcome

Looking forward to your comments and contributions