Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

Problem with Pardiso matrix checker: matrix type is not real

Anja_I_
Beginner
443 Views

Hello,

I want to use Pardiso to solve a linear equation system with a real unsymmetric matrix. I adapted the example pardiso_unsym.f to my Fortran90-code. It runs for the linear equation system in the example, but not with my values, unfortunately.
Pardiso creates the following output during the chec files.tar.gzking of the right hand side and the matrix:

 [PARDISO]: License check was successful ...
 Check rhs was successfull
[PARDISO]: CHK Given matrix type is not real: 0
 The following ERROR was detected:           10

The matrix is sparse. Here are the other parameters:

iparm(1) = 0
iparm(3) = 1
nrhs = 1
maxfct = 1
mnum = 1
mtype = 11
solver =  0
n = 7776
number of matrix entries: 38496

For the computation of the matrix I only use real values and I do not divide by zero.
Especially, when I set all matrix values to the maximum of row and column index, the same error occurs.
So the exact values of the matrix entries are not problematic. I can not find anything wrong in ia and ja.

What can be the error in creating this matrix?
What does ERROR=10 mean?

It would be great if you have any ideas to solve this problem.
Thank you very much!

Regards,
Anja

0 Kudos
7 Replies
mecej4
Honored Contributor III
443 Views

I modified the program pardiso_unsym_f.f that is distributed with MKL to read your data files. The program yielded the solution without any problems.

Please, therefore, provide the source code for a complete example which exhibits the problems that you described.

 

0 Kudos
Anja_I_
Beginner
443 Views

Thank you very much for your help and your program!
It helped me a lot, so that now, I can solve my equations with PARDISO.

I tried to figure out the exact problem and the important difference seems to be that you do not use pardiso_init in your code.
If I use it, the matrix checker or the right-hand-side-checker has problems, depends on what is executed first.
If I do not use pardiso_init, everything works fine.
Using pardiso_init with your code, then it works, but I can't find the difference to my code (please see the attachment).

It would be interesting to know the answer, if you want to look at it.
Thank you!

0 Kudos
mecej4
Honored Contributor III
443 Views

The single source code file in code.tar_0.gz appears to make Pardiso calls for the Lugano/Basel versions of Pardiso, not the version included in MKL. Although there are many similarities between the two versions, they are not interchangeable and it would be better to discuss usage of only the Intel MKL version.of Pardiso in this forum.

Nevertheless, your subroutine pardiso_kaputt , when invoked with the data for the A, IA, JA arrays that you posted earlier, works correctly with Pardiso 4.1.2 and with the recently released Pardiso 5.0.

0 Kudos
Anja_I_
Beginner
443 Views

Thank you for your last answer. However, it is not clear to me, why you can solve my system with my code and I can't, although I downloaded Pardiso and the examples from the webpage http://www.pardiso-project.org, which seems to be the Lugano/Basel version you mean. If I would use the Pardiso MKL version, it would be clear...

At the moment, another problem is occured, namely that the solution is wrong. If the right-hand-side is a vector of zeros, the solution is not full of zeros, as it should be. The condition number is circa E05 and I found in the topic http://software.intel.com/en-us/forums/topic/295450
that I could change the parameters
iparm[9] - perturbation value
iparm[10] - scaling
iparm[12] - matching

If I do this (with my pardiso version, iparm(i) is iparm(i+1), if you look into the code), and test different values, nothing changes.
For example I use
iparm(9) = 1.0E-10
iparm(10) = 1
iparm(12) = 2
n = 3936
number of matrix entries : 19296.

All needed files are attached. I would be glad if you have some ideas, even if it is the other version of Pardiso. Thank you.

0 Kudos
mecej4
Honored Contributor III
443 Views

Anja I.: The files in filesuncorrectsolution.tar.gz are insufficient to build and run your test case; the only source file, "code", contains only a subroutine. Errors could have been made in reading the data from files into the arrays which were then passed as arguments to that subroutine.  If you wish that I should look at this example, please provide the rest of the code which calls the subroutine -- without that available, I can do little.

However, I have something else that may help. I took the test program for solving an unsymmetric set of equations from the MKL distribution, modified it to read your data from the rows, columns and entries files in  filesuncorrectsolution.tar.gz. This program runs with the MKL version of Pardiso and, for b = 0, gives the expected solution x = 0. The program is attached. 

I suspect that your difficulties in obtaining correct solutions have origins in parts of you code that you have not shared with us. However, as I have shown, there is no problem with obtaining correct solutions if Pardiso calls are made correctly, so it should be possible to find the errors in your code with a little work. Please let me know how I can help.

0 Kudos
Anja_I_
Beginner
443 Views

Thank you for the answer. I think for this problem I found the solution in that I did not look correctly for all the entries of the right hand side... In my case they are not all equal to zero as I know now. If I set them to zero, the solution is correct. So I hope that it is all right now.
Thank you for all your effort!

0 Kudos
mecej4
Honored Contributor III
443 Views

Anja I. wrote:
Thank you for the answer. I think for this problem I found the solution in that I did not look correctly for all the entries of the right hand side... In my case they are not all equal to zero as I know now. If I set them to zero, the solution is correct. 

Uninitialized variables in Fortran programs can be difficult to detect and fix, but they are likely to surface especially when code that was developed on older mainframes is reused on today's microcomputers.

It is good that you have found the problem and fixed it.

0 Kudos
Reply