- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Hi
Just wonder if the source code was in fortran interface?
If yes, the link command line, may need
-Wl,-rpath,/opt/intel/mkl/lib -lmkl_gf_lp64 -lmkl_sequential -lmkl_core -lpthread -lm
or
is it possible to use Intel fortran compiler to build the scalapack?
Best Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ying,
Thanks for your prompt reply. I checked Link advisor on Linux with GNU fortran and indeed -lmkl_gf_lp64 should be used instead of -lmkl_intel_lp64.
The problem is: this lib is not there in OS-X MKL distribution! :-( Thus, i can not really check if this is indeed the reason for the segmentation fault.
Could you please pass the message for this lib to be included and the updated OS-X bundled to be created?
Otherwise it seems one can only use MKL for C, which is very unfortunate.
Sincerely, Denis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Denis,
MKL has not been supporting gfortran on OS X. Linux interface library libmkl_gf_lp64 differs from libmkl_intel_lp64 in the conventions how functions return complex numbers. Intel Fortran and gfortran have different conventions. Since you build ScaLAPACK on your own, you could try to tweak the build to make functions returning complex follow Intel conventions. For that, could you try to check if the gfortran you use supports -ff2c flag and if yes then add this flag for building ScaLAPACK and your application. You should link libmkl_intel_lp64 then.
Thanks
Dima
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dima,
Thanks a lot for your suggestion. After doing a quick search I found out that one should use -ff2c -fno-second-underscore .
Unfortunately, i still have some unit test failures:
The following tests FAILED:
77 - xssep (Timeout)
79 - xcsep (Timeout)
81 - xsgsep (Timeout)
83 - xcgsep (Failed)
91 - xssyevr (Timeout)
93 - xcheevr (Timeout)
95 - xshseqr (Timeout)
all unit tests are run with 4 MPI cores. At least xcgsep is related to Eigendecomposition routines:
SCALAPACK Hermitian Eigendecomposition routines.
' '
Running tests of the parallel generalized Hermitian eigenvalue routine: PCHEGVX.
A scaled residual check, will be computed
An explanation of the input/output parameters follows:
RESULT : passed; or an indication of which eigen request test failed
N : The number of rows and columns of the matrix A.
P : The number of process rows.
Q : The number of process columns.
NB : The size of the square blocks the matrix A is split into.
THRESH : If a residual value is less than THRESH, RESULT is flagged as PASSED.
: the QTQ norm is allowed to exceed THRESH for those eigenvectors
: which could not be reorthogonalized for lack of workspace.
TYP : matrix type (see pCGSEPtst.f).
IBTYPE : Generalized eigenproblem type (see pCHEGVx.f)
SUB : Subtests (see pCGSEPtst).f
CHK : The scaled residual
N NB P Q TYP IBTYPE SUB WALL CPU CHK CHECK
----- --- --- --- --- ------ --- -------- -------- --------- -----
'TEST 1 - test tiny matrices - different process configurations'
C
ISEED( 1 ) = 139
ISEED( 2 ) = 1139
ISEED( 3 ) = 2139
ISEED( 4 ) = 3139
UPLO= 'L'
SUBTESTS= 'N'
N= 0
NPROW= 1
NPCOL= 2
NB= 1
MATTYPE= 8
IBTYPE= 1
ABSTOL= 0.000000D+00
THRESH= 0.400000D+03
C
0 1 1 2 8 1 N 0.00 -1.00 NaN FAILED
[---the-rest-is-cut---]
At this point I don't know whether or not these NaNs in scaled residual are related to MKL. At least there are no segmentation faults... Will keep searching, but if you have any advices, i would be grateful.
Regards,
Denis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
p.s. during compilation i see a lot type mismatch warnings in test driver programs like:
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/TESTING/LIN/psqrdriver.f:691:38:
$ MEM( IPPIV ) )
1
Warning: Type mismatch in argument 'ipiv' at (1); passed REAL(4) to INTEGER(4)
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/TESTING/LIN/pdqrdriver.f:690:38:
$ MEM( IPPIV ) )
1
Warning: Type mismatch in argument 'ipiv' at (1); passed REAL(8) to INTEGER(4)
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/TESTING/LIN/pcqrdriver.f:709:38:
$ MEM( IPPIV ) )
1
Warning: Type mismatch in argument 'ipiv' at (1); passed COMPLEX(4) to INTEGER(4)
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/TESTING/LIN/pzqrdriver.f:709:38:
$ MEM( IPPIV ) )
1
Warning: Type mismatch in argument 'ipiv' at (1); passed COMPLEX(8) to INTEGER(4)
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/PBLAS/TESTING/pzblas1tst.f:227:41:
$ NPROCS, ALPHA, MEM )
1
Warning: Type mismatch in argument 'work' at (1); passed COMPLEX(8) to INTEGER(4)
/tmp/scalapack20160315-68539-ggklj5/scalapack-2.0.2/BLACS/TESTING/blacstest.f:2818:30:
$ MEM(ERRIPTR), MEM(ERRDPTR) )
1
Warning: Type mismatch in argument 'erribuf' at (1); passed REAL(4) to INTEGER(4)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On Ubuntu with system provided Blas/Lapack it is all good and all tests pass if I do not specify -ff2c -fno-second-underscore flags. Otherwise it is broken.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Denis,
Your last comments "On Ubuntu with system provided Blas/Lapack" , so is it another issue, not related to intel MKL,right?
"if I do not specify -ff2c -fno-second-underscore flags", is it with gfortran.
Regarding the original issue on OS X, beside of the -ff2c -fno-second-underscore , here are other two ways for your reference.
1. try Intel fotran compiler, https://software.intel.com/en-us/intel-compilers/, which should provide 30-days free try.
2) Possible workaround is to compile CLADIV, CDOTU, CDOTC, ZLADIV, ZDOTU, ZDOTC, xxx from NETLIB using GFortran and link these functions before Intel MKL. So that all functions expecting complex values are not calling MKL, but using a code compiled with GFortran.
Best Regards
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ying,
I mentioned Ubuntu only to make a point that the problem is not in Scalapack itself as it does compile fine and all tests pass.
Thanks for your suggestions. I will think about it.
Regards, Denis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just realised that Scalapack and Blacs are also provided within the MKL OS-X bundle. Given the discussion in the above, could there be any issues when using those with GNU Fortran + Clang?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Denis,
What function in scalapack do you need to use?
We have not been supporting gfortran on OS X for years, so just speculate:
In most of case, GFortran + Intel MKL with libmkl_scalapack_lp64 and libmkl_intel_lp64 linked) should work unless you will call an MKL function which returns a complex value. Such a call may cause a crash or incorrect behavior.
Most of BLAS, LAPACK, ScaLAPACK functions are procedures which return no any value, so there will be no problems with such problem. And the problem with those functions which return a complex value could be workarounded by calling their C counterparts, like cblas_cdotu instead of cdotu, or LAPACKE_zlange instead of zlange.
Best Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ying,
I don't use ScaLAPACK directly, i compile other libraries which are used in other libraries which are used in other libraries which I use. So it's like ScaLAPACK -> MUMPS -> PETSc & Trilinos -> deal.II -> my code.
I guess in this usage scenario I can only hope that i never deal with complex numbers.. :-(
Regards, Denis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI Denis,
Option -ff2c is not a solution indeed, because it makes Fortran functions declared as real be interpreted as returning double. That explains failures of single-precision tests. I am sorry for having misguided you.
It looks like gfortran on OS X can be used with MKL but in a very limited way. I therefore second Ying's suggestion " try Intel fotran compiler, https://software.intel.com/en-us/intel-compilers/".
Thanks
Dima
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page