Using `scikit-fem` on pip: solver remark

Although this is tangentially related to scikit-fem since the primary objective of scikit-fem is assembly and not solving the resulting systems, it maybe important to note that when working with a default pip installation on Windows, there is a significant performance degradation in solving, since the default sparse solver is SuperLU which is super slow. I think the conda installation may not suffer from this since the default solver is UMFPACK (?) which can be faster. There maybe further improvements possible when numpy is compiled against an optimized BLAS but that is something most users wouldn’t care for.

I managed to get Pardiso working on Windows and with pypardiso things are significantly faster. See the timings on example 36 with nthreads=8 (and Mesh.refined(3)) and a slight addition at https://github.com/kinnala/scikit-fem/blob/c07ff9f6d6a51e62eac2777351b20b4549027ada/skfem/utils.py#L102

namely simply calling pypardiso.spsolve

def solver_direct_pypardiso(**kwargs) -> LinearSolver:
    """Linear solver provided by Pardiso."""

    def solver(A, b):
        return pypardiso.spsolve(A, b)

    return solver

Timings

Pardiso

Solve time: 0.3992440700531006
1, norm_du: 45.481410024640475, norm_dp: 14.934126744945504
Solve time: 0.31940722465515137
2, norm_du: 16.15926762709032, norm_dp: 20.93859584370273
Solve time: 0.3229987621307373
3, norm_du: 3.2471798205287667, norm_dp: 15.053533831714226
Solve time: 0.35599684715270996
4, norm_du: 0.4538801110428914, norm_dp: 2.6708267761548887
Solve time: 0.3192098140716553
5, norm_du: 0.027865264212750027, norm_dp: 0.1630714233226417
Solve time: 0.328704833984375
6, norm_du: 0.002041324778791658, norm_dp: 0.016283691403898768
Solve time: 0.3122262954711914
7, norm_du: 1.6033937733037654e-05, norm_dp: 0.0003318753774227752
Solve time: 0.33296942710876465
8, norm_du: 1.6887613490335165e-09, norm_dp: 4.315368227582554e-08
Solve time: 0.35301685333251953
9, norm_du: 4.4086266413504256e-15, norm_dp: 1.7099154835473912e-14
Total time: 98.29319977760315

SuperLU

Solve time: 19.864436626434326
1, norm_du: 45.48141002464045, norm_dp: 14.934126744945653
Solve time: 17.160115242004395
2, norm_du: 16.159267627090234, norm_dp: 20.93859584370295
Solve time: 18.916175842285156
3, norm_du: 3.247179820528735, norm_dp: 15.053533831714496
Solve time: 17.143075704574585
4, norm_du: 0.45388011104290815, norm_dp: 2.670826776154936
Solve time: 17.078906536102295
5, norm_du: 0.027865264212752802, norm_dp: 0.16307142332264873
Solve time: 17.101752281188965
6, norm_du: 0.0020413247787918446, norm_dp: 0.016283691403900905
Solve time: 17.19295907020569
7, norm_du: 1.6033937733110564e-05, norm_dp: 0.00033187537742298715
Solve time: 17.220698833465576
8, norm_du: 1.688761318114545e-09, norm_dp: 4.3153681931898745e-08
Solve time: 16.51562809944153
9, norm_du: 4.3255823949057516e-15, norm_dp: 1.5848762808515266e-14
Total time: 251.57028770446777

[kinnala]

You could try reordering the rows and the columns, e.g., using skfem.utils.rcm. This kind of reordering is done to reduce the NNZ entries in the LU/Cholesky decomposition. I guess some linear algebra packages may do that automatically.

[gdmcbain]

Yes, so far Pardiso looks better on everything except ex27 (lucky me), so I do think it’s worth persisting with, particularly as it’s so easy to use in scikit-fem via pypardiso. I’d say it was well worth including in the suite of integrations #474. I don’t know why ex27 was problematic or why Pardiso gave different results to SciPy and different results from run to run, but would be interesting in learning more if this is expected or other evidence is found.