Pardiso gives different solutions whenever runs

Pardiso gives different solutions whenever runs

hi

i am working on pardiso sparse solver on WINDOWs.

i have a problem on a small test sample.

whenever i runs the program it returns different solutions on 2 thread condition

1 thread condition 1 it's OK. (i changed the thread with function mkl_set_num_threads())

i used the matrix which have size of 54 and 909 nonzeros.

i attached the sample codes.

joon

AttachmentSize
Download PardisoDiff.zip18.97 KB
17 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - Joon Yoon
hi

i am working on pardiso sparse solver on WINDOWs.

i have a problem on a small test sample.

whenever i runs the program it returns different solutions on 2 thread condition

1 thread condition 1 it's OK. (i changed the thread with function mkl_set_num_threads())

i used the matrix which have size of 54 and 909 nonzeros.

i attached the sample codes.

joon

Hi Joon,
What MKL version you are using?
--Gennady

Quoting - Gennady Fedorov (Intel)

Hi Joon,
What MKL version you are using?
--Gennady

Hi Gennady

im using MKL 10.1.0.018

i added one file which i am using now. :)

Joon

Attachments: 

AttachmentSize
Download mkl_c.lib228 bytes

Joon,
Thanks for the project.
The linking dependencies you are using "mkl_c_dll.lib" are not compatible with version mkl 10.1.
I'd like recommend you the following:
1) to read the MKL User Guide chapter 5 "How to link Your Application with Intel MKL". You can find there a lot of Linking example
2) Please see the MKL Linking Adviser (http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/) .
Please let me know if further problem.
--Gennady

Quoting - Gennady Fedorov (Intel)

Joon,
Thanks for the project.
The linking dependencies you are using "mkl_c_dll.lib" are not compatible with version mkl 10.1.
I'd like recommend you the following:
1) to read the MKL User Guide chapter 5 "How to link Your Application with Intel MKL". You can find there a lot of Linking example
2) Please see the MKL Linking Adviser (http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/) .
Please let me know if further problem.
--Gennady

Gennady

i have retry with latest version 10.1.3.028 now.

i get this evaluation version 10min's ago.

BUT it has same problem. It gives different solution again

i attach same file with the result.

i just run it twice (acually, sometimes 3 or 4 times gives difference.)

fort_1 and fort_2 is different. :(

-- joon

Attachments: 

AttachmentSize
Download PardisoDiff_282_29.zip18.75 KB

Joon,
this update 3 includes some fixes for SGEMM and DGEMM for large matrices but not for Pardiso.
Nevertheless, as I guess, that the cause of the problem you encountered is the linking dependencies you are using.
See my recommendations into the previous tread.
--Gennady

Quoting - Gennady Fedorov (Intel)

Joon,
this update 3 includes some fixes for SGEMM and DGEMM for large matrices but not for Pardiso.
Nevertheless, as I guess, that the cause of the problem you encountered is the linking dependencies you are using.
See my recommendations into the previous tread.
--Gennady

Gennady,

I tried what you recommanded. but it doesnt work. :(

I am now using Visual Studio 6.0 and Compaq Fortran 6.1 and i just added the path

"C:Program FilesIntelMKL10.1.3.028ia32lib"

and added the library "mkl_solver.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib" as you said,

And i have tried it with Visual Studio 2005 with Intel Fortran 11.0.066 also but it gives same results.

I think the thread 2 gives a problem of this because with thread 1 it's fine.

It's kind of thread safe problem, i think.

can i ask you to find somthing more with this?

i know Pardiso is developed university of basel. do you know they know about this kind of problem?

-- joon

Out of curiosity I tried to build your project and got errors of mistmatch in data sizes, like this one:

error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [B]

Did you get the same? How did you build your project? Do you have all run-time and compile time checks on? Especially interfaces? I don't quite believe that Pardiso has a problem with multi-threads, it's more likely that there are coding/building errors in the sample you have.

I'm using VS2008 Pro and latest IVF Pro. I think you copied the interface from an old version, DF suggests Compaq, so my (wild) guess is you mixed with new version and old interface and made MKL confused.

And my suggestion is, do not go back to CVF, it's already 10 years dead, so even if you make it working doesn't give you a good prospect.

A.

Edit: I actually took example you're using (but took it from examples dir), addedcall mkl_set_num_threads(3) as you did, and build it, whatever number of threads I'm setting (1, 2, 3, 4) always get the same answer. So... strange.

Quoting - ArturGuzik
Out of curiosity I tried to build your project and got errors of mistmatch in data sizes, like this one:

error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [B]

Did you get the same? How did you build your project? Do you have all run-time and compile time checks on? Especially interfaces? I don't quite believe that Pardiso has a problem with multi-threads, it's more likely that there are coding/building errors in the sample you have.

I'm using VS2008 Pro and latest IVF Pro. I think you copied the interface from an old version, DF suggests Compaq, so my (wild) guess is you mixed with new version and old interface and made MKL confused.

And my suggestion is, do not go back to CVF, it's already 10 years dead, so even if you make it working doesn't give you a good prospect.

A.

Edit: I actually took example you're using (but took it from examples dir), addedcall mkl_set_num_threads(3) as you did, and build it, whatever number of threads I'm setting (1, 2, 3, 4) always get the same answer. So... strange.

hi ArturGuzik

I worked with Visual Studio 6.0 so there wasnt error #7836

I tried same code with Visual Studio 2005 and i found the error you mentioned

I fixed the compiler error and add the project and file now.

could you try with this one please.

and if it is possible, could you give me the files you have succeded with?

thanks for your reply.

-- joon

Attachments: 

AttachmentSize
Download PardisoDiff_2005.zip6.37 MB

I wrote the long aswer but this file attachment (terrible) process lost it somewhere.

In short. Your new version is OK. I believe your linking and memmory goes wrong somewhere. Also example you use produce results (repeatable, though) within range E-8 to E-32, so..

See the example files. Whatever number you set, the anwser is the same.

Or maybe I didn't understand something. Please post more details. I always see the same results (mine or your new version).

Statistics:
===========
< Parallel Direct Factorization with #processors: > 2
< Numerical Factorization with BLAS3 and O(n) synchronization >

Solve completed ...
The solution of the system is
x( 1 ) = -4.186020128680939E-002
x( 2 ) = -3.413124159279098E-003
x( 3 ) = 0.117250376805018
x( 4 ) = -0.112639579923180
x( 5 ) = 2.417224446137141E-002
x( 6 ) = -0.107633340356223
x( 7 ) = 0.198719673273585
x( 8 ) = 0.190382963551205

Statistics:
===========
< Parallel Direct Factorization with #processors: > 4
< Numerical Factorization with BLAS3 and O(n) synchronization >

Solve completed ...
The solution of the system is
x( 1 ) = -4.186020128680939E-002
x( 2 ) = -3.413124159279098E-003
x( 3 ) = 0.117250376805018
x( 4 ) = -0.112639579923180
x( 5 ) = 2.417224446137141E-002
x( 6 ) = -0.107633340356223
x( 7 ) = 0.198719673273585
x( 8 ) = 0.190382963551205
Press any key to continue . . .

why you use all that windows libs in the linking command? As you don't specify the command explicitely I'm not sure which threading libs are actually used.

A.

Attachments: 

AttachmentSize
Download PARDISO_example.zip2.12 KB

The sample ia, ja, a is my real problem. So i need to solve THE values.

The problem is this. I run 2 thread one time it gives solution like below.

==============================================
Solve completed ...
The solution of the system is
x( 1) = -1.121432626508370E-019
x( 2) = -2.182959175624419E-005
x( 3) = -7.942977891377918E-019
x( 4) = -9.840228231082713E-017
x( 5) = -8.630128527932650E-023
x( 6) = 3.437064893581743E-017
x( 7) = 1.901482409446912E-022
x( 8) = -2.182959179645067E-005
x( 9) = -1.504139255172472E-018
x( 10) = -1.166895245007158E-016
x( 11) = 9.377555502114475E-038
x( 12) = -5.260653048089519E-032
x( 13) = 1.125103482252695E-019
...
x( 52) = 2.440428144088812E-012
x( 53) = 3.683127023899231E-022
x( 54) = -1.115503065539322E-012
Press any key to continue
==============================================

and do it again.

==============================================
Solve completed ...
The solution of the system is
x( 1) = -1.121432626508370E-019
x( 2) = -2.182959175624419E-005
x( 3) = -7.942977891377917E-019
x( 4) = -9.840228231082713E-017
x( 5) = -8.630128527932650E-023
x( 6) = 3.437064893581743E-017
x( 7) = 1.901482409446002E-022
x( 8) = -2.182959179645067E-005
x( 9) = -1.504139255172473E-018
x( 10) = -1.166895245007158E-016
x( 11) = 9.377555502142054E-038
x( 12) = -5.260653048096753E-032
x( 13) = 1.125103482252696E-019
...
x( 52) = 2.440428144088812E-012
x( 53) = 3.683127023899231E-022
x( 54) = -1.115503065539322E-012
Press any key to continue
==============================================

For example, as you see x(3) is different // -7.942977891377918E-019 vs -7.942977891377917E-019
(other values are different too slightly.)
I havewritten it with hexa form but it's still different (INPUT is same but OUTPUT is different)
this occurs when just 2 run, somtimes within 5 run.
in my experience, it always happens within 10 times.

the digit is very small but it have significant difference on my project.

and for the linkage i think i am using the standard form which is guided in user's guide.
now i choose // mkl_solver.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib
because i am now using the Compaq Fortran
(i have done it with intel fortran and VS2005 but there is same problem.)

ifthere is any comments on the linkage, talk to me to accept your opinion.

-- joon

Quoting - Jo
For example, as you see x(3) is different // -7.942977891377918E-019 vs -7.942977891377917E-019
(other values are different too slightly.)
and for the linkage i think i am using the standard form which is guided in user's guide.
now i choose // mkl_solver.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib
because i am now using the Compaq Fortran
(i have done it with intel fortran and VS2005 but there is same problem.)

ifthere is any comments on the linkage, talk to me to accept your opinion.

-- joon

wow! Sure you'll get differences like these:-). You're expecting too much. You're operation/instructions are very different, reduction for example. You need to fix (reformulate) your problem and not the code. What kind of problem is that -7.942977891377918E-019 vs -7.942977891377917E-019 makes a difference? Are you dealing with ill-conditioned matrices later on??? Going to quadruple precision? Remember the performance will suffer!

Your linking is now OK. Using mkl_c and mkl_s manages the calling conventions (IVF CDECL, CVF STDCALL).

A.

Quoting - ArturGuzik

wow! Sure you'll get differences like these:-). You're expecting too much. You're operation/instructions are very different, reduction for example. You need to fix (reformulate) your problem and not the code. What kind of problem is that -7.942977891377918E-019 vs -7.942977891377917E-019 makes a difference? Are you dealing with ill-conditioned matrices later on??? Going to quadruple precision? Remember the performance will suffer!

Your linking is now OK. Using mkl_c and mkl_s manages the calling conventions (IVF CDECL, CVF STDCALL).

A.

I know it's quite small values.

http://www.intel.com/software/products/mkl/docs/linux/webhelp/MKL_UG_cod...

But the site says MKL gives bit-for-bit identical outputs when input is same.

So I expected the same result on this problem.

I think it could be a Pardiso's own problem not on MKL.

But i don't have connection with Pardiso but with intel so i am using this page now.

Can i ask you to find another possibility to figure it out?

-- joon

Quoting - Joon Yoon

I know it's quite small values.

http://www.intel.com/software/products/mkl/docs/linux/webhelp/MKL_UG_cod...

But the site says MKL gives bit-for-bit identical outputs when input is same.

So I expected the same result on this problem.

I think it could be a Pardiso's own problem not on MKL.

But i don't have connection with Pardiso but with intel so i am using this page now.

Can i ask you to find another possibility to figure it out?

-- joon

Hi Joon Yoon

I have tested your data in my environment (Win XP 32 bit. Intel Core2. Visaul Fortran 11.0. 072)
I also got a same problem with solutions; there aresmall differences

Would you send me email?
I would like to discuss more detail

jh.lee2@hotmail.com

you may email yourown mother tongue

Jong Hwa

Quoting - Joon Yoon

http://www.intel.com/software/products/mkl/docs/linux/webhelp/MKL_UG_cod...

But the site says MKL gives bit-for-bit identical outputs when input is same.

So I expected the same result on this problem.

The docs read that it's for LAPACK, BLAS. I don't think it applies to PARDISO. And morever, in your example you never use MKL_malloc() to align data, so .... it's not aligned.

A.

Quoting - ArturGuzik

The docs read that it's for LAPACK, BLAS. I don't think it applies to PARDISO. And morever, in your example you never use MKL_malloc() to align data, so .... it's not aligned.

A.

I agree with you. It doesn't say PARDISO gives identical results. And I have tried MKL_malloc() with may sample. But it doesn't affect to it. So I uploaded the sample which have no MKL_malloc().

Is the allignment can be affact to this matter? Then I'll try it again.

-- joon

Quoting - Joon Yoon

I agree with you. It doesn't say PARDISO gives identical results. And I have tried MKL_malloc() with may sample. But it doesn't affect to it. So I uploaded the sample which have no MKL_malloc().

Is the allignment can be affact to this matter? Then I'll try it again.

-- joon

No. If you tried and didn't help then there is nothing you can do about it. But out of curiosity, what's type of problem you're dealing with that requires such precision? Did you try to attack it using quadruple precision?

A.

Leave a Comment

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