- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page