Pardiso sparse right hand side iparm(31) = 1 (or iparm[30]=1 in C++)

Pardiso sparse right hand side iparm(31) = 1 (or iparm[30]=1 in C++)

Dear All

I am testing an example with sparse right hand side and sparse solution iparm[30 ]=1 in my C++.

What I have noticed that

the solution of (perm[0] = 0, b[0] !=0) and (perm[0], b[0]=0) are different.

But I expected that the solution should be the same since perm[0]= 0,

Furthermore the solution x[0] is 0th entry of the solution vectro.

However, from the pardiso manul of iparm(31), x[0] should be a random number, since I did't request to caculate it.

http://software.intel.com/sites/products/documentation/hpc/mkl/mklman/GU...

The attachment is my C++ code.

Could you tell me why this happened?

Hailong

AttachmentSize
Downloadtext/x-csrc main.c2.67 KB
7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

There is one problem in your code. On line 76, you set iparm[0] = 0. You should have set iparm[0] = 1, which guarantees you all iparm paramenters are not taking default values.

With this fixed, I don't see difference in x[2] (this is the only result you'd care about because perm[2] = 1), no matter what value given to b[0].

Other minor problems: You do not need iparm[2] and iparm[51]. These are not used by MKL PARDISO at present.

Hi Zhang

Thanks for your suggestions.

I have one more question. If I am running a program with 1 node 16 cores, how many cores will pardiso use?

I just need everything is serial not multi-threaded.

Hailong

Hi Zhang

I just tested with iparm[0]=1. Now b[0] has no effect on the solution. However, x[0] and x[1] seems to be caculated with iparm[30]=1.

From 

http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mklman/GUID-264E311E-ACED-4D56-AC31-E9D3B11D1CBF.htm

x[0] and x[1] will be caculated only with iparm[30]=2 instead of iparm[30]=1 (which is the case in my code).

Hailong

For this real tiny problem, it might be easier for MKL to just compute the whole x vector. It doesn't do any harm by giving you more than you asked, I believe :) You can always discard x[0] and x[1] if you do not need them.

To answer your earlier question, MKL by default automatically adjusts the number of threads at run time. For tiny/small problems, an MKL function uses only 1 thread (i.e. 1 core). For large problems, it uses more cores available on the system. If you want it to be serial, you should link with the sequential MKL (Use this tool to determine the exact link line). Or, you can call function mkl_set_num_threads() to set the number of threads to 1. You can also use env-variables like MKL_NUM_THREADS or OMP_NUM_THREADS.

Hi Zhang

Thanks a lot for your help.

I just tested another problem with the same matrix, but the only nonzero rhs at the 0th entry (b[0]), then x[1] and x[2] are not caculated as I hoped. With iparm[30] = 2, x[1] and x[2] are caculated. Since this functionality is crucial for my real and big application, I need to make sure it is working as I expected.

Here is another question, If my OMP_NUM_THREADS = 1, can I make sure it is serial? 

Hailong

Quote:

Hailong X. wrote:

Here is another question, If my OMP_NUM_THREADS = 1, can I make sure it is serial? 

Yes.

Leave a Comment

Please sign in to add a comment. Not a member? Join today