Closed jgostick closed 2 years ago
and #2273
I'm thinking we should reconsider this.
This is not the first time that pardiso has bit us. At the moment I literally cannot get openpnm to work with pardiso...I've tried everything to no avail. It makes me think...we really should use the scipy solver as the default. We can make it very clear that users should use pardiso if they can (maybe even issue a warning?)...but having a literally unusable package is not acceptable obviously.
Also, this may call for a hotfix on the 2.8 branch since any new install will also be broken.
Do you have any more context about what's not working with pypardiso? Are you using windows? See https://github.com/haasad/PyPardisoProject/issues/36 and https://github.com/conda-forge/intel_repack-feedstock/issues/33
@jgostick Here's an idea: like porespy, we introduce a global settings object, which includes the preferred linear solver/integrator. Then, inside the settings class, test pypardiso on a 3x3 matrix and see if works, if for whatever reason it doesn't, the settings class falls back to some other solver (like scipy's spsolve). What do you think?
Firstly, I love the idea of putting the default solver in the project settings. A little 3x3 test is a fun idea too.
Regarding the error I was getting...the code would actually run sometimes! We have about 6 calls to run
in our example script, and I realized it was failing at different points. It would an "error code" of -3, which I admittedly have not looked up. After this error I would get an OS error with some exception about failing to write data to memory. So, it seems that the error code only occurs sometimes, but once it happens, pardiso fails in a bad way that prevents it from running again.
To answer @haasad, yes I am using Windows with a fresh download of Anaconda. I tried all manner of 'older' version of everything, but I guess I was alwasy getting the broken mkl.
I wrote a summary here of what happened and possible solutions. Let me know if you have a preference (i.e. waiting for upstream fixes or going for something like 4.)
In this specific case, a 3x3 test matrix most likely wouldn't have uncovered the problem, because it only occurs for larger matrices (see my comment here).
We have added the ability to see the default solver in the Workspace now, so people who run into this issue can workaround it more easily. We could update the requirements file to specify the correct versions of the solvers, but that causes other problems. I think the best bet is to create a 'discussion' item with the solution on it (install specific version of these packages) the pin it to the top of the page for now.
Discussed in https://github.com/PMEAL/OpenPNM/discussions/2272