- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear all,
I am trying to use ZGETRF+ZGETRS function to solve a square matrix equation in form of Ax=b but the results are totally different comparign with results from GMM++. I use the code below in C++ and Linux:
// MKL solution to solve "YV=I" matrix equation
int info;
int ipiv[nNodes];
int nrhs=1;
char transa='N';
zgetrf(&nNodes, &nNodes, MKL_Y, &nNodes, ipiv, &info);
zgetrs(&transa, &nNodes, &nrhs, MKL_Y, &nNodes, ipiv, &I[0], &nNodes, &info);
where I is defined as
vector > I(nNodes);
and filled before above functions are called. nNodes also indicates the dimension of "A" which is square.
Have you had same experience before? Any help would be appreciated.
Thanks,
D.
I am trying to use ZGETRF+ZGETRS function to solve a square matrix equation in form of Ax=b but the results are totally different comparign with results from GMM++. I use the code below in C++ and Linux:
// MKL solution to solve "YV=I" matrix equation
int info;
int ipiv[nNodes];
int nrhs=1;
char transa='N';
zgetrf(&nNodes, &nNodes, MKL_Y, &nNodes, ipiv, &info);
zgetrs(&transa, &nNodes, &nrhs, MKL_Y, &nNodes, ipiv, &I[0], &nNodes, &info);
where I is defined as
vector
and filled before above functions are called. nNodes also indicates the dimension of "A" which is square.
Have you had same experience before? Any help would be appreciated.
Thanks,
D.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have to use the same double complex type as that used in building MKL, that is, the MKL_Complex16. Other conventions for representing complex numbers in C++ may not be type-compatible.
You are more likely to get help if you show a small complete example with source code and particulars about your environment (OS, compiler and special library versions).
Here is a small example that works with ICPC 11.1.072. Please note that ZGETRF and ZGETRS are to be called using the expected Fortran calling convention.
You are more likely to get help if you show a small complete example with source code and particulars about your environment (OS, compiler and special library versions).
Here is a small example that works with ICPC 11.1.072. Please note that ZGETRF and ZGETRS are to be called using the expected Fortran calling convention.
[cpp]#includeWhen compiled and run with the input data
extern "C" {
#include
#include"mkl_lapack.h"
}
using namespace std;
main(){
int i,j,N=2;
MKL_Complex16 *A,*B; int info,*ipiv,nrhs=1;
double x,y;
A = new MKL_Complex16[N*N];
B = new MKL_Complex16;
ipiv = new int;
for(i=0; iscanf("%lf,%lf",&x,&y);
A.real=x; A.imag=y;
}
for(i=0; iscanf("%lf,%lf",&x,&y);
B.real=x; B.imag=y;
}
zgetrf(&N,&N,A,&N,ipiv,&info);
zgetrs("N",&N,&nrhs,A,&N,ipiv,B,&N,&info);
for(i=0; i.real,B.imag);
}
[/cpp]
[bash]4,1 -2,-1 -1,-1 7,1it gives the expected result
5,-4 17,-4
[/bash]
[bash] 2.000e+00 + -1.000e+00 i
3.000e+00 + -1.000e+00 i
[/bash]
- 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
Well, I guess I did a big mistake! MKL's results are completely correct! The reason that they were different from GMM++ was that the equation Ax=b consisted of very small numbers which usually (not always) put the solvers into numerical instabilities. In this case, the results of GMM++ showed unwanted oscillations which can easily be detected as an instability, but MKL seems to be more accurate and stable and results are more reliable than other libraries, as far as I have tested. Since I am solving a problem in several steps, so the equation Ax=b should be solved in each iteration with new values. Therefore, when values become bigger (further steps), the results from MKL and GMM++ are exactly same.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page