Fall back to ILU/IC sparselib algorithm with CPU executors

[upsj]

There is no reason to make the distinction between algorithms when we only have a single one available. This issue was found when running the custom multigrid example with OpenMP

[pratikvn]

The OMP tests need to be updated. Otherwise, LGTM

[yhmtsai]

I think we have decided to stay the behavior which throw the error when OMP does not have syncfree algorithm. It is also based on we keep sparselib algorithm although it is not from sparse library in fact.
Refer to the discussion #1684 (comment)

[upsj]

The current default does not support OpenMP, so either we change the default, or we fix the breakage. With the CSR strategies, we fall back to a different algorithm if it's unsupported - why the difference here? Both compute the same thing, and have only runtime performance implications.

[yhmtsai]

I had the same comments on that but it was still the decision we made.

[nbeams]

I actually think it would be better if syncfree were the default, because it supports OpenMP + CUDA/HIP, vs. sparselib which only supports CUDA/HIP. But that changes the default behavior for anyone who was already using CUDA/HIP, perhaps in a "silent" way that could be easy to miss, which I think was the main reason not to do it. The current setup has the same default behavior as pre-#1684 for all three affected backends (use cuSPARSE/hipSPARSE or throw a not implemented error for OpenMP), except with the new error message for OpenMP, letting the user know that another option is available now.

[MarcelKoch]

IMO the approach is reasonable. Another alternative which doesn't change the current default, would be to introduce a new enum value, probably default, which defers to sparselib on gpu and syncfree on CPU. But maybe that is a bit overkill.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud