Pardiso now fails after upgrading from 11.0.5.1 to 11.1.3.1

[euan]

Hi,

I just upgraded my Mkl library from 11.0.5.1 to 11.1.3.1 and now Pardiso crashes.  All I'm doing is running a solve on a 4x4 matrix for 3 vectors, it used to work fine but now gets a weird crash.  The matrices are normally much bigger, but this is this simplest case I could recreate.  Can someone have a look please?  I'm using the C# wrapper and have attached a Visual Studio solution.  Once I've built the example if I place it in a folder with all the binaries from 11.0.5.1 it runs fine, but if I place it in a folder with the binaries from 11.1.3.1 it crashes.

Incidentally, when I make my release build, which binaries do I need to ship with it?  I assumed it was the content of the "redist\ia32\mkl" folder, but it seems I also need some files from "\redist\ia32\compiler".  What is the meaning of the "compiler" folder? Why not put everything you need for distribution in one folder?

Thanks,

Euan

[Gennady_F_Intel]

Euan, as You may know, MKL doesn't validate #C environment. there are few examples ( you can find these example into KB article ) only. I would recommend to check if the problem exist with C code to be sure that all are ok with usage model. Very probably some issues would much clear after that stage. 

[Ying_H_Intel]

Hi Euan, 

1. As I happen to investigate one bug report about Pardiso failed when upgrade 11.1.3.  We will  fix it in next nearest version. but the bug i mentioned only can be reproduced in large cases.

I try your test case. In your code, the original matrix is  

  * Matrix:
                    0    1    2    3
                0    1    0    0    0
                1    0.296296296296302    0.444444444444445    0.222222222222218    0.0370370370370356
                2    0.0370370370370355    0.222222222222218    0.444444444444444    0.296296296296302
                3    0    0    0    1

         */

but the code is 

   double[] matrixAElements = new double[] 
                       {
                        0.29629629629630233,
                        0.44444444444444453,
                        0.22222222222221777,
                        0.03703703703703555,
                        0.037037037037035536,
                        0.22222222222221771,
                        0.44444444444444442,
                        0.29629629629630233,
                        1.0
                       };

Why was the first non-zero 1 removed?  is there any special reason? 

Then  I did the below

a. change the project configuration from Any CPU  to x86  (I'm try ia32bit, if 64bit, change to X64). rebuild the code.

b. copy all needed dynamic library:  mkl_rt.dll, mkl_intel_thread.dll, mkl_avx2.dll mkl_core.dll libiomp5md.dll in the Debug directory : \Desktop\MklTest\MklTest\ConsoleApplication1\bin\x86\Debug

It seems run fine with MKL 11.1.3.  

Pardiso phase 12 done
Pardiso phase 33 done
0.00399128086609691  (  Console.WriteLine(resultVector[0]); i print the first result)
Finished
Press any key to continue . . .

What error do you see when your run the code?  

2.  The pardiso C# sample Gennady mentioned  is available at  

https://software.intel.com/en-us/articles/using-intel-mkl-in-your-c-program

https://software.intel.com/en-us/articles/some-more-additional-tips-how-to-call-mkl-from-your-c-code/

3. Regarding the redistribution and MKL library directory structure,  we release Intel Parallel Studio XE for software development.  And Composer XE is one of component.  Then MKL is sub-component of Composer XE. As MKL library depends on some compiler library (mainly OpenMP Runtime library). In order to align the components, the structure become the one you are seeing. 

my MKL 11.1.3 is from Composer XE 2013 SP1 update 3.  you can check the version information from Composer XE 2013 SP1\Documentation\MKLsupport.txt

Best Regards,

Ying 

[euan]

Hi Ying,

Thanks for your response.

You are correct that I was missing the initial 1.0 at the start of the matrix elements. Unfortunately this does not fix the problem. The solve step occurs successfully and I get the same result as you. However, on the final pardiso call to free the memory the program terminates. In the output window in Visual Studio I get:
    The program '[4772] ConsoleApplication1.vshost.exe: Managed (v4.0.30319)' has exited with code 1073741855 (0x4000001f).

Looking up this error it was suggested that turning on native code debugging may help. Doing this the program now stops when the error occurs and I get the following in the output window:
    HEAP[ConsoleApplication1.exe]: Heap block at 059BB2C0 modified at 059BB338 past requested size of 70
    Windows has triggered a breakpoint in ConsoleApplication1.exe.

    This may be due to a corruption of the heap, which indicates a bug in ConsoleApplication1.exe or any of the DLLs it has loaded.

    This may also be due to the user pressing F12 while ConsoleApplication1.exe has focus.

    The output window may have more diagnostic information.

I am also using MKL 11.1.3 from Composer XE 2013 SP1 update 3. Previously we were using MKL 11.0 update 5, which works fine.

Strangly if I set the number of right hand sides during the initialisation phase (12) to 3 rather than zero then the error does not occur.

I've attached the updated program with the fixed matrix.

Regards,

Euan

[Ying_H_Intel]

Hi Euan, 

How about your real case. if with right nrhs, does it work correctly?  

generally, we recommend to set correct nrhs on initial step .. becaue we allocate internally arrays for iterative refinement on reordering step with size of 2*nrhs*neqns, and deallocate the memory when phase = -1. If nrhs on reordering step was smaller than correct nrhs, we allocated smaller memory, But we need to deallocate the bigger memory which is supposed for correct nrhs. It seems the reason of the memory error. 

Best Regards,

Ying 

[euan]

Hi Ying,

In version 11.1.3 it seems to work correctly if I make sure that nrhs is the same for all phases.

Previously in our code we would perform the initialisation and factorization steps (phase=12) with nrhs=0 and then set nrhs to the correct number of rhs in the solve step (phase=33). This allows flexibility in the number of right hand sides solved for without redoing the factorization. We would deallocate the memory using nrhs=0 again. In version 11.0.5 and in previous versions this was not a problem.

Am I correct that in version 11.1.3 if we want to solve for a different number of rhs on the same matrix we need to deallocate the memory (phase=-1) and then redo the factorization (phase=12)? It seems to me that this shouldn't be necessary.

Regards,

Euan

[Ying_H_Intel]

Hi Euan, 

Right, the restriction shouldn't necessary. The behaviors are unexpected. I have escalated this to our developer to further investigation.  We will update you if any findings. 

For workaround, you may initialize one max nrhs, thus don't need recall the phase 12.

Best Regards,

Ying  

[euan]

Hi Ying,

Thanks for escalating this.

It would also be useful for some clarification in the reference manual for what the value should be in the various phases as I previously assumed it would not be used outside of phase 33.

Thanks,

Euan