Crate maintenance

[vbarrielle]

As mentioned in https://github.com/vbarrielle/sprs/issues/278#issuecomment-820984278, I'm currently lacking the time to work on this crate, and I'm unsure when I'll have the time and motivation again.

I think it's probably a good time for me to ensure this crate can remain maintained. In the past year, @mulimoen has produced amazing work to enhance the usability and stability of the crate, so if you're ok, I'd like to ask you to take over the maintenance while I cannot work on this crate. It may be a good idea to move this crate under an organization to reflect the maintenance change?

[mulimoen]

I'm afraid I have little time for major developments on this crate, but I'd be happy to squeeze in some time for pull requests and smaller issues.

I don't actively use the crate myself, it would be nice to get some feedback from users, and maybe some new contributors. This might be easier if we move the crate to a new organization.

[aujxn]

Hello @vbarrielle @mulimoen ---

Thank you both for all the work you have put into this crate, it's been a pleasure to work with for my undergraduate research and I plan on using it heavily throughout PhD. As part of my research commitments I'd like to provide some time to helping maintain this code as my work will depend on it's health.

My Rust knowledge and library development experience is limited so I wont be able to take over as a primary maintainer as it sounds like is needed but the API seems fairly stable at this point anyway. I am currently researching adaptive algebraic multigrid methods that will hopefully be useful for anisotropic meshes common in finite element methods and am developing a partner crate that will include various iterative methods and preconditioners. Would you be interested in hosting that crate inside this repository as well?

For my PhD thesis I am considering implementing a distributed linear algebra package in pure rust that doesn't depend on all the standard tools like MPI and LAPACK to investigate how Rust could be used for HPC, which would also potentially make use of this crate. I doubt it will turn into a tool people will use but it will be valuable for me to learn about HPC programming at the systems level.

Looking through the issue tracker I found a few issues that I would be capable of starting on. If you have suggestions on what issues you think are most critical please let me know, having a small roadmap in the readme might be a nice idea. For now, I think that #117 is important to have so I'll start there. I'd also like to start creating a 'cheat book' quick reference so people can get started using the crate easily.

[mulimoen]

Thanks @aujxn for your interest in this project. Such preconditioners and optimisers would be very nice to have in a companion crate, and I would be glad to include this in the crate if it makes sense. If you wish to help in the development in the library #296 would be a good start. This issue covers perf analysis and some lower level details of sprs, and @tomtung has done most of the legwork in finding the weak points in the current approach.

[aujxn]

Ok I'll take a look at that! Looks like a good issue to start studying the internals. Would it be worth it to bring in criterion as a bench dependency or would you prefer to stick with bencher? I can start making some benchmarks using some matrices from the suitesparse collection if that seems like a reasonable way to start working on this issue.

The solvers and preconditioners I'm developing are still very much in the draft stage, hardly tested and nothing is generic, so it will probably be a little bit before it's cleaned up enough to publish at all. The repo is amg_match on my profile.

[mulimoen]

Both criterion and iai are worth examining for benchmarking. Using suitesparse matrices sounds like a great way to compare solutions across implementations in C++/Fortran/Rust

[StefanUlbrich]

Hi! I'd love to contribute but I am still quite new to rust and its eco system. What would be a good start to revive the project?

[mulimoen]

@StefanUlbrich That depends a bit on your interests. If you are interested in using sprs from python you could consider #200. If you want to do some implementation work then maybe #174 could be a good start. Otherwise you can find something you feel is missing or should be more ergonomic and start playing around!

[aujxn]

Hi @StefanUlbrich, let me know if you have any questions/suggestions as I am just starting to get involved with this crate

[StefanUlbrich]

@aujxn, I am currently working on a PR for an interpolation crate and to update its dependencies. I want to use it in a (not-only) toy project to learn Rust. My biggest problem is #293.

In general, I am more of a consumer of numerical libraries but it feels as if the success of well-designed packages like this and ndarray is crucial for using Rust in a scientific context (so is HPC)–so I would be glad if I could support the maintainers.

[StefanUlbrich]

293 is still open despite only missing publishing to crates.io.

Would it make sense to reach out to the ndarray project or an organization like numfocus to conserve the progress?

[mulimoen]

I have not been able to contact @vbarrielle. At this point I can not add any members to this organisation and only have publish right to some of the crates. Perhaps it is necessary to fork at this time

[mulimoen]

I have been given access to publish all sprs* crates and an organisation has been created to house sprs

[StefanUlbrich]

I have been given access to publish all sprs* crates and an organisation has been created to house sprs

That’s great news! Thank you