Sparse direct solver in JS

[nikoscham]

Is there any chance in the roadmap to bring a sparse direct solver in native JS? Wishful thinking, something at the level of MUMPS! That would however require parallel capabilities for solving large linear systems. A solver like that would be a treasure for the development of FEAScript, or other computational libraries, for solving real-life cases.

Thanks to all the stdlib team for the amazing work!
Nikos

[kgryte]

@nikoscham That would be an interesting addition. And personally, I would love to explore sparse array support, but I think we are still a bit underwater at the moment just getting dense support over the finish line.

One of the main issues with sparse arrays is the multitude of formats, which essentially necessitate having a compiler. And shipping a compiler to web applications is a harder sell due to content security policies prohibiting the use of eval and new Function. The workaround is compiling to WebAssembly where it is possible to instantiate JIT'd kernels without violating CSP due to Wasm modules operating within a more secure sandbox.

One thing I am personally keeping an eye on is the development of finch-tensor in Python-land. One of its core advantages is the ability to accommodate arbitrary sparsity and array formats. Once that matures, I think it should be possible to explore porting to JavaScript with Wasm/C as a backend compilation target. However, that is a ways a way from becoming production ready.

Given this, I am loathe to prematurely "pick" a format in order to avoid potentially painful rewrites later. So, in short, having something like MUMPS would be awesome, but I don't think we have the bandwidth to add atm. :(

[kgryte]

Would a dense solver be enough for you to get by atm? If so, if there is a LAPACK routine we should target for prioritization, feel free to suggest.

[nikoscham]

Thanks for your answer, @kgryte. It is interesting that you consider the main issue with sparse arrays to be choosing the correct matrix format. I was thinking that the greatest issue would be how to make it run in parallel so as to be able to solve real-life cases (like ~a million DOF). I don't have, however, so much experience in software architecture as you do. Your perspective to think about the software architecture first is quite interesting and helpful also for the design of FEAScript. To be honest, I have started now giving more attention to unify all the matrix formats in my code.
Furthermore, regarding the active compiler solution you have proposed, to be honest, at first glance, it seemed like a somewhat unconventional approach (as I had never heard of this technique before). However, I am sure it will be very useful in many cases. Have you ever used that before in stdlib?
Finally, unfortunately, a dense solver is not appropriate for FEM applications. It would be too slow.
I will keep watching the stdlib progress (it's an amazing project) for sparse solver development, and I would be happy to contribute to that when you start building it.

Thanks again!