pardiso C# "not enough memory"

[Gianluca_G_1]

I'm trying to use pardiso in C#, in order to resolve a unsymmetric matrix of complex numbers.

I started executing an example I've found in internet, that works fine.

By the way when I replace the data with others, taken from my examples, it fails at the first step: factorization, with an error related to a memory "-2: not enough memory".

This is obviouslly not possible, because the matrix is quite small. 

I suppose it should be related to some parameter, but there are many and it is possible that I've missed something.

Is there any one that can help me?

I attach the example, the system has 24 equations.

Thank you
Gianluca

[mecej4]

Your CSR format data in PardisoProgComplex.cs for the matrix is incorrect. If n=24 (your matrix is 24 X 24), the array IA should have n+1, i.e., 25 elements; you should probably have an additional element at the end in ia[], with value nnz+1 = 49.

[Gianluca_G_1]

Thank you for your help, I've missed this details.

But now I need a new little help. 

In order to verify the algotithm and the results, I'm using LAPACKE_zgesvxx(), that is a function I've used many times in our programs. 

As you can see from the attached image, pardiso and zgesvxx provide different results.

So maybe I have to work on refinement procedure steps. 

Do you have tips for this issue?

Thankyou again

[Gennady_F_Intel]

yes, these results are very different. Do you know if this is generated matrix or not? 

[Gianluca_G_1]

what do you mean?

[mecej4]

Gianluca G. wrote:

In order to verify the algorithm and the results, I'm using LAPACKE_zgesvxx(), that is a function I've used many times in our programs.

You did not have to do that. To test whether the solution is correct and reasonably accurate, once you obtain the solution x, compute the 2-norm of A.x - b. Using the solution returned by Pardiso, I find that 18 of the 24 elements of (A.x - b) are exactly (0.0, 0.0). The remaining 6 elements have real and imaginary parts that are < 1e-16 in magnitude. Can one expect a more accurate answer?

can see from the attached image, pardiso and zgesvxx provide different results.

Yes; I can see the difference; however, you have not shown the code that calls zgesvxx. Lapack is used by millions of people, and Pardiso/MKL is used by thousands of people. The probability is nearly zero that one or both have bugs that can yield grossly wrong solutions for such a simple problem as yours.

A simple explanation of the difference is that you have not solved the same problem with the two solvers, or have made some mistake in the arguments that you passed to zgesvxx. When you post only the output of a program whose source you have not shown us, and the output is itself suspect, there is not much that we can do to help until you provide more details of what you did.

So maybe I have to work on refinement procedure steps.

No. Refinement is appropriate when the differences in the two solutions are small. Refinement can never compensate for blunders.

I suggest that you obtain a solution using the simple driver routine zgesv() and compare the results to those from Pardiso. Later on, you may consider iterative refinement if you think that it is warranted.

[Gianluca_G_1]

I'm making tests, I give you news as soon as I can.

[Gianluca_G_1]

we have used zgesvxx for years, so it can't be a parameters error on it, moreover zgesv gives the same result of zgesvxx .

I'm incline to think that I miss something in pardiso parameters.

[Gianluca_G_1]

I got the solution!

it was the b array non properly setted.

Sorry for my distraction.

By the way I have some consideration, in order to improve the pardiso documentation.

It is non clear if to use CSR or CSR3 format, and when use one or the other.

Also the ia and ja seems zero based defined, by default, but this is not true.

iparm[34] = 0; 
iparm[35] = 0; 

But the example works only if one-based indexing is used.

Thank you very much

BR
Gianluca