I have just started using MKL on Macintosh for its LAPACK implementation, which seems to be better than the one in Apple's Accelerate framework. I'm using the MKL that came with the Fortran compiler, 11.1.88. I call it from C/C++ code.
In the past we've had troubles with LAPACK's annoying default of calling EXIT on an error, so I followed the MKL documentation and created my own version of xerbla. Then I created a test case with an intentional error. My xerbla() gets called as expected.If I don't provide my own xerbla(), nothing happens except that the info parameter gets set to a non-zero value. I think that's wonderful, but it is non-standard.Finally, my question- is the observed behavior intended for MKL? Can it be counted on?I scanned the MKL documentation and can't find anything that says MKL xerbla is in any way non-standard.Thanks!-John WeeksWaveMetrics, Inc.
If an issue is found with an input parameter, xerbla prints a message similar to the following:
MKL ERROR: Parameter 6 was incorrect on entry to DGEMM
and then returns to the user application.
* Installers may consider modifying the STOP statement in order to
* call system-specific exception-handling facilities.
Using one's own XERBLA may not work if the routine is called by another routine in the MKL (.DLL or .so version), because calls within the shared library (DLL) are directed to routines that are already in the DLL. In other words, if you use the shared version of MKL, calls to XERBLA go to the routine already in MKL, so your XERBLA may never get called.
2. Use a global flag which is consulted in XERBLA to select between stopping and continuing after setting an error number, with a default to stop and provide a way for the user to to set the global flag so that no stopping occurs. It may also be useful to let the user allow XERBLA to stop after some n errors occur, where n has a default value of, say 1 or 10, but may be set to another value by the user.
Oh well, if you are using a custom-built library (a fact which you had not divulged earlier) my comments about not being able to use a curstom XERBLA with a shared,standardMKL library no longer apply.
The default set-up should work safely for the majority of users, many of whom may be casual, non-expert users.
TheLapack user guidespecifically says:
Your statement that "the LAPACK standard is just plain wrong" is rather harsh, and dismissive of historical perspective.
I'm an MKL LAPACK engineer. Let me say a couple of words about LAPACK behavior w.r.t. XERBLA and INFO.
LAPACK routines call XERBLA on two conditions: 1) wrong parameter (actually it's a user-supplied parameter, internally all parameters are passed correctly) in full accordance with standard, 2) not enough memory to allocate - some routines acquire extra memory - this is MKL-specific behaviour.
No XERBLA is invoked on singular matrix condition, or when an algorithm diverges and fails to compute the output correctly, that is, when INFO returned is positive.
To sum up, XERBLA is called onlywhen theuser may encounter some fatal error if theexecution flowisn'tback to the user program immediately. We use RETURN instead of STOP in MKL supplied XERBLAso thatthe user can do something with it, have a chance to understand what happened and make another route.
I agreeit would benice to document a deviation from de-facto standard behavior, even though 'standard' behavior can be easily overridden.
We use RETURN instead of STOP in MKL supplied XERBLAso thatthe user can do something with it, have a chance to understand what happened and make another route.