Problem with MKL DSS single precision version

[Zhanghong_T_]

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

[mecej4]

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.

[Zhanghong_T_]

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

[mecej4]

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.

[Zhanghong_T_]

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

[TimP]

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.

[Zhanghong_T_]

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

[mecej4]

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.

[Zhanghong_T_]

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

[Konstantin_A_Intel]

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

[Zhanghong_T_]

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

[Gennady_F_Intel]

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

[Gennady_F_Intel]

I have attached the modified mkl_dss.f90 file I told about into the previous thread.

--Gennady

[Zhanghong_T_]

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

[Gennady_F_Intel]

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

[Gennady_F_Intel]

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