ENH: update SuperLU to version 6.0.1#19284
Conversation
We enforce a minimum version of MSVC, and that version does have the stdint.h header. This reverts commit c93a509
Note that this includes a few patches on top of 6.0.1. The exact upstream commit from https://github.com/xiaoyeli/superlu/ that this upgrades to is 2c8ef7da153e87745f04f968eb2a995d735e64ec.
The complex changes have been upstreamed and hence we drop the patch file. The patches didn't cleanly apply, hence we dropped the non-essential ones. Those correspond to the "fix uninitialized warnings" from PR 14442.
This replaces the fixes from scipygh-14442 and scipygh-14602, which are too annoying to maintain as patches. Instead, those fixes should be upstreamed to SuperLU.
|
Recording the refguide check failure for future reference: DetailsThe results are correct; the decomposition still reconstructs, but the numerical values have all changed. Adding a |
|
This is a huge PR, but most of it is changes pulled in from upstream that don't need review. I'd suggest reviewing only the last four commits (which are small and self-contained), and only briefly browsing the rest for really obvious issues like in the README. Can I tempt someone to hit the Merge button here (don't squash-merge please)? This was a pain to unravel, so I'd much prefer for it not to accumulate merge conflicts. |
|
Ok, I spent some time looking over the diff and it seems like this moves us in a desirable direction re: 64-bit stuff/upstreaming patches. If this does cause problems you'll likely help me with it at release time anyway. I will ping on the testing change as a precaution after merging, just because there's a type coercion in there that wasn't there before. |
| LU.solve(np.array([1, 2, 3, 4])), | ||
| np.asarray([1, 0, 0, 0], dtype=np.float64), | ||
| rtol=1e-14, atol=3e-16 | ||
| ) |
There was a problem hiding this comment.
@stefanv @perimosocordiae I merged this PR to move things along for i.e., eventual 64-bit SuperLU support, patch upstreaming, etc. The testing shims don't look too controversial to me, but if there is something that worries you can you ping me? It was just the new coercion that made me slightly nervous as non-expert reviewer on sparse linalg.
There was a problem hiding this comment.
IIRC this was a matter of the result from LU.solve being on the order of 1e-17 rather than exactly zero, and the default atol=0 not working for that. It's been a few weeks, but IIRC this is business as usual with minor differences in floating-point results.
This was quite a pain to untangle. This updates to the latest commit in the
masterbranch of https://github.com/xiaoyeli/superlu, which has a few fixes on top of the 6.0.1 tag. Some of our patches have been upstreamed, others are still to be upstreamed - this is easier now that SuperLU is actively maintained on GitHub.Closes gh-19092
Potential follow-ups:
setup.pybuild)EDIT: for reference, here are the previous SuperLU update PRs: gh-7554, gh-12243