Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
6956 Discussions

Problem with MKL DSS single precision version

Zhanghong_T_
Novice
1,104 Views
Dear all,

I have problem to call the MKL DSS in single precision. I have the following code:
...
COMPLEX*8::X8(1),B8(1),A8(1)
...
OPT = MKL_DSS_SINGLE_PRECISION

ierror = dss_create( handle, OPT )

ierror = dss_define_structure(handle,MKL_DSS_SYMMETRIC_COMPLEX,IROW,N,N,ICOL,NK)

ierror = dss_reorder( handle, MKL_DSS_DEFAULTS, perm )

ierror = dss_factor_complex( handle,MKL_DSS_INDEFINITE, A8)

ierror = dss_solve_complex( handle, MKL_DSS_REFINEMENT_OFF,B8, NRHS, X8)

...


When compiling, the following errors displayed:
error #6633: The type of the actual argument differs from the type of the dummy argument. [A8]
error #6633: The type of the actual argument differs from the type of the dummy argument. [B8]
error #6633: The type of the actual argument differs from the type of the dummy argument. [X8]


I built the code in Win7 x64 + VS2008 + Intel Visual Fortran 11.1.065 + Intel MKL 10.2.6.037.



Could anyone tell me what did I miss?


Thanks,
Zhanghong Tang

0 Kudos
15 Replies
mecej4
Honored Contributor III
1,104 Views
As the documentation of DSS states, DSS_FACTOR_COMPLEX and DSS_SOLVE_COMPLEX take complex array arguments only of type COMPLEX(KIND=8), which is the same as COMPLEX*16. There appear to be no single precision (23-bit-significand) versions of the routines.

The error messages are the result of your attempting to use COMPLEX*8 (which is equivalent to COMPLEX(KIND=4)) argument arrays.
0 Kudos
Zhanghong_T_
Novice
1,104 Views
Hi Mecej4,

Thank you very much for your kindly reply. Do you mean that the DSS changed the data type for Pardiso solver automatically? I tried to modify the code to declare the data as COMPLEX*16, the program crashed in the subroutine "dss_factor_complex".


Thanks,
Zhanghong Tang
0 Kudos
mecej4
Honored Contributor III
1,104 Views
DSS and PARDISO are alternatives. Therefore, there is no reason for a choice made with reference to one package to affect the other package.

It is not surprising that a crash occurred, if you called the DSS routines with improperly set arguments. For example, you declare the arrays with

COMPLEX*8::X8(1),B8(1),A8(1)

If N, NK, etc., happen to be different from 1, this declaration could be in error.

Please post a small, complete example code demonstrating the problem. The MKL installation has an example, dss_sym_f90.f90, that you may want to try first and adapt to your purposes next.
0 Kudos
Zhanghong_T_
Novice
1,104 Views
There is no problem to declare X8(1), etc.

For the example case, if I change the code from
error = DSS_CREATE( handle, MKL_DSS_DEFAULTS )
to
error = DSS_CREATE( handle, MKL_DSS_SINGLE_PRECISION )

The following error displayed:
MKL-DSS-DSS-Error, Zero Pivot detected

0 Kudos
TimP
Honored Contributor III
1,104 Views
Did you check how the arguments are declared in the include files? I don't know how you can be sure that mixing non-standard declaration idioms from 40 years ago will be accepted under modern syntax checking.
0 Kudos
Zhanghong_T_
Novice
1,104 Views
Hi Tim,

Thank you very much for your kindly reply.
Even I declare the X8(N), B8(N), the program still crash.

For the example program "dss_sym_f90.f90", what should I do to let it work on single precision? I modified the following code:
error = DSS_CREATE( handle, MKL_DSS_SINGLE_PRECISION )

or
error = DSS_CREATE( handle, MKL_DSS_SINGLE_PRECISION+MKL_DSS_MSG_LVL_WARNING + MKL_DSS_TERM_LVL_ERROR )


Both give the same error I shown above.


Thanks,
Zhanghong Tang
0 Kudos
mecej4
Honored Contributor III
1,104 Views
Library routines have well-defined specifications and established protocols for calling them. Merely changing subroutine arguments (for example, MKL_DSS_DEFAULTS to MKL_DSS_SINGLE_PRECISION) without regard for the specifications and protocols is not likely to succeed.

When a library provides only a double-precision version of a routine, you cannot expect the routine work with arguments of the wrong type (single-precision). Specifying single-precision with a flag (MKL_DSS_SINGLE_PRECISION) is of no use when the library has no capability for obeying that demand.

0 Kudos
Zhanghong_T_
Novice
1,104 Views
I think that the MKL DSS can be called by setting 'MKL_DSS_SINGLE_PRECISION'.



Dear all,

Could you please help me to modify the attached sample code to let it work correctly?



Thanks,
Zhanghong Tang
0 Kudos
Konstantin_A_Intel
1,104 Views
HiZhanghong Tang,
To run your program in single precision mode you should declare all your REAL data as REAL*4, but in your example all arrays are double precision.
So, you may simply use
INTEGER, PARAMETER :: dp = KIND(1.0E0)
instead of
INTEGER, PARAMETER :: dp = KIND(1.0D0)
Regards,
Konstantin
0 Kudos
Zhanghong_T_
Novice
1,103 Views
Hi Konstantin,

Thank you very much for your kindly reply. After I changed the code as you said, the following errors displayed:

dss_sym_f90.f90(78): error #6633: The type of the actual argument differs from the type of the dummy argument. [VALUES]
dss_sym_f90.f90(82): error #6633: The type of the actual argument differs from the type of the dummy argument. [RHS]
dss_sym_f90.f90(82): error #6633: The type of the actual argument differs from the type of the dummy argument. [SOLUTION]
dss_sym_f90.f90(89): error #6633: The type of the actual argument differs from the type of the dummy argument. [STATOUT]

Could you please provide me a whole project that you have successfully run?

Thanks,
Zhanghong Tang
0 Kudos
Gennady_F_Intel
Moderator
1,103 Views
Zhanghong Tang.
Yes, this is a known problem with support single precision of f90 interfaces for DSS function. We are working on that problem at this moment.

As a temporarily workaround, I 'd recommend you to manually change the API of these functions by replacingREAL(KIND=8) byREAL(KIND=4).

I mean the following list of functions:DSS_FACTOR_REAL,DSS_SOLVE_REAL,DSS_STATISTICS

and if you call DSS_CREATE( handle, MKL_DSS_SINGLE_PRECISION)

then all stuff should be Compliable and run well.

--Gennady

0 Kudos
Gennady_F_Intel
Moderator
1,103 Views
I have attached the modified mkl_dss.f90 file I told about into the previous thread.
--Gennady
0 Kudos
Zhanghong_T_
Novice
1,103 Views
Hi Gennady,

Thank you very much for your kindly reply. It seems that the problem can be solved by defining a 'preprocessor definitions' in the file . I have attached the mkl_dss.f90 (you only attached the example file).

Thanks,
Zhanghong Tang
0 Kudos
Gennady_F_Intel
Moderator
1,103 Views
just for the info -This issue has been submitted to our internal development tracking database for further investigation, we will inform you once a new update becomes available.
Here is a bug tracking number for your reference:DPD200192258
0 Kudos
Gennady_F_Intel
Moderator
1,103 Views
HiZhanghong Tang,
the problem has been fixed in the latest version of MKL 10.2 Update 7. Could you please check if the problem is still there and let us know.
--Gennady
0 Kudos
Reply