I'm running Pardiso with the out-of-core (OOC) option. When I'm done I call the PARDISO function with phase = -1. Most files generated during the out-of-core process are deleted, but 2 files remain: ABC.sin and ABC.sle, where "ABC" is what I set in MKL_PARDISO_OOC_PATH.
Why aren't these files also deleted? Is there a way to have them automatically deleted along with the other files?
I built a Win32 version - still calling from C, though. I have the same problem: the files *.sin and *.sle are not deleted, but the files *.ind, *.jal, *lnz, and *.lup - which were created while the problem was running - were all deleted by Pardiso.
This is the version information I have:
Major Version= 10
Minor Version= 3
Update Version= 3
Product Status= Product
Processor Optimization= Intel Pentium 4 processor with SSE3
It appears I'm using the proper version, but I'll go ahead and download a new version - if my evaluation status allows it.
I clicked on my evaluation link in my email and I'm being prompted to download w_mkl_p_10.2.7.040.exe.
But when I first clicked on that link the file I downloaded was w_mkl_10.3.3.175; this is what I have installed. So it appears to me that I have the proper version installed and if I click on my email link I will end up installing an older, rather than newer version.
Can you let me know where I can download the very latest version from?
Do you at least see the .sin and .sle files before they are deleted?
I guess I don't know what else to try now. With MKL_PARDISO_OOC_KEEP_FILE set to 0 I see lots of other files left on the disk. If I set it o 1 then the .sin and .sle files still remain, while all others are gone.
Could it be that, in addition to MKL_PARDISO_OOC_KEEP_FILE set to 0 I need an additional flag to have these 2 files deleted and I'm missing this information?
We faced with similar problem in past. Now it should be resolved. Could you provide as with following info: What does input parameter iparm(60) equal? How much number of threads (MKL_NUM_THREADS) do you use? Please, print out the iparm(57) and iparm(64) after reordering step.Additionally it would be nice if you set msglvl=1 before reordering and provide us with output information.
I ran with MKL_NUM_THREADS=2 (although I got a message #processors = 1; I have another thread here on this topic). Also,
iparm(60) = 2 on input
On output, iparm(57) = 0 and iparm(64) = 103000115
Here is a bug tracking number for your reference: DPD200210337.
Thanks for getting to the bottom of this. I appreciate your help and patience throughout this process.
Should I get an update on this thread when the bug is fixed, or what is the procedure for tracking this bug?