Strange error in Zheevr with Studio Express 6/10

Question

I have found a strange anomaly exposed by my code while testing Studio Express 6/10.
At runtime I was seeing a large number of copies of the error message
** On entry to ZHEEVR, parameter number 22 has an illegal value.
** On entry to ZHEEVR, parameter number 22 has an illegal value.
On closer investigation this arose in execution of the code
    ! Workspace query -- set "size(cwork,1)" to -1; this is stored in optimal_size
    optimal_size = -1
    call zheevr('v','a','u',N,matrix,size(matrix,1),1.0_dp,1.0_dp,1,1, &
       &        abs_tol,num_eigval,eigenvalues,eigenvectors,size(eigenvectors,1),isupp,cwork,optimal_size, &
       &        rwork,optimal_size,iwork,optimal_size, status)
    optimal_size = iwork(1)
    deallocate(iwork,stat=status)
    if (status/=0) call io_abort('Error in deallocating iwork in algor_diagonalise_hermitian')
    allocate(iwork(optimal_size),stat=status)
    if (status/=0) call io_allocate_abort('iwork','algor_diagonalise_hermitian')
  [.. deallocate and reallocate cwork and rwork similarly to iwork .]
    call zheevr('v','a','u',N,matrix,size(matrix,1),1.0_dp,1.0_dp,1,1, &
       &        abs_tol,num_eigval,eigenvalues,eigenvectors,size(eigenvectors,1),isupp,cwork,size(cwork,1), &
       &        rwork,size(rwork,1),iwork,size(iwork,1),status)
   On return status=-22, corresponding to a size error in the "iwork" argument.
So in other words, the code makes an enquiry of the size to use for the iwork array, allocates an array
of that size. However the computational call rejects the size that the enquiry call advised!
If I allocate a larger array (size > 40*N) then the call succeeds and no error is generated. I should point out
that this code works well with Intel MKL, AMD ACML, GotoBLAS, and other LAPACK implementations, and
only fails with sunperf. If I link the Sun f95-compiled code against GotoBLAS instead of sunperf it also works
correctly.
Is there some anomaly in the Sunperf implementation of zheevr?
The platform is x86_64 linux (Mandriva 2010) with 32-bit integer memory model. The matrix size of one
failing case was 4 and the first call of zheevr returned iwork(1)=32, though it fails for other small sizes too.

Answer 1

Yes, there are formulas for figuring out the optimal workspaces. For Studio Express 6/10, this is based on LAPACK version 3.1.1. The ZHEEVR interface
and workspace formulas are :
SUBROUTINE ZHEEVR( JOBZ, RANGE, UPLO, N, A, LDA, VL, VU, IL, IU, ABSTOL, M, W, Z, LDZ, ISUPPZ, WORK, LWORK,
$ RWORK, LRWORK, IWORK, LIWORK, INFO )
WORK (workspace/output) COMPLEX*16 array, dimension (MAX(1,LWORK))
LWORK (input) INTEGER
The length of the array WORK. LWORK >= max(1,2*N)
For optimal efficiency, LWORK >= (NB+1)*N, where NB is the max of the blocksize for CHETRD and for CUNMTR as returned by ILAENV
You could just use MAX(1, 2*N) for the size of WORK. But this is sub-optimal. To get the optimal size, this is more work since it involves calls to
ILAENV. But it should give you better performance. Here is what calculating the optimal WORK size should look like :
INTEGER ILAENV
EXTERNAL ILAENV
INTEGER LWMIN, NB
LWMIN = MAX(1, 2*N)
NB = ILAENV( 1, 'CHETRD', UPLO, N, -1, -1, -1 )
NB = MAX( NB, ILAENV( 1, 'CUNMTR', UPLO, N, -1, -1, -1 ) )
LWKOPT = MAX( ( NB+1 )*N, LWMIN )
RWORK (workspace/output) REAL*8 array, dimension (MAX(1,LRWORK))
LRWORK (input) INTEGER
The length of the array RWORK. LRWORK >= max(1,24*N)
So for RWORK, this is much simpler. Just make it MAX(1, 24*N)
IWORK (workspace/output) INTEGER array, dimension (MAX(1,LIWORK))
LIWORK (input) INTEGER
The dimension of the array IWORK. LIWORK >= max(1,10*N)
IWORK is also simple. Just make it MAX(1, 10*N)
You can also view the source code for this at www.netlib.org if you need further details. Hope this helps.
-Jeremy