The LAPACK forum has moved to https://github.com/Reference-LAPACK/lapack/discussions.

problem with zheevd and gotoblas

Open discussion regarding features, bugs, issues, vendors, etc.

problem with zheevd and gotoblas

Postby gabe » Wed Aug 22, 2007 7:34 am

I am testing the subroutines ZHEEV and ZHEEVD.

If I link my test code to gotoblas, ZHEEV and ZHEEVD give different eigenvalues for the same matrix, when the order of the matrix N is > 214 ( no problem when N <= 214 !!!).

ZHEEV and ZHEEVD give good results if I link to a standard non-optimized blas library... but it is much slower.

So apparently, there is a problem when I link ZHEEVD to gotoblas.
Is it a known bug or am I doing something wrong??

thx
gabe
 
Posts: 3
Joined: Tue Aug 21, 2007 4:22 am
Location: Paris, France

Re: problem with zheevd and gotoblas

Postby buttari » Wed Aug 22, 2007 11:42 am

gabe wrote:I am testing the subroutines ZHEEV and ZHEEVD.

If I link my test code to gotoblas, ZHEEV and ZHEEVD give different eigenvalues for the same matrix, when the order of the matrix N is > 214 ( no problem when N <= 214 !!!).

ZHEEV and ZHEEVD give good results if I link to a standard non-optimized blas library... but it is much slower.

So apparently, there is a problem when I link ZHEEVD to gotoblas.
Is it a known bug or am I doing something wrong??

thx


Gabe,
we can do some investigations on this problem. In order to do this we need some more informations though:
1) what is the architecture?
2) what is the GotoBLAS version?
3) what compilers are you using?
4) can we have you test program?
It is possible that there is a bug somewhere (either your code or LAPACK code) that turns into an error only when GotoBLAS is used or it may be that there is a bug in GotoBLAS.
Also, I would suggest you to post your message on the GotoBLAS mailing list too.

Thanks

alfredo
buttari
 
Posts: 51
Joined: Tue Jul 11, 2006 2:11 pm

Postby gabe » Thu Aug 23, 2007 3:28 am

Thanks for your reply.

Apparently the problem appears when I link to a multi threaded BLAS.
I made some test using ACML (AMD BLAS Library, version 3.6.0). The same problem appears when I use the multiprocessor version of ACML. I have no problem when I use the single processor version of ACML.


1) what is the architecture?

AMD opteron 64 bit quadriprocessor

2) what is the GotoBLAS version?

1.09

3) what compilers are you using?

INTEL ifort 9.1

4) can we have you test program?

yep!
Code: Select all
  implicit none
  integer ierr,i,j,n
  integer INFO,LWORK,LRWORK,LIWORK
  double precision zero,rtemp,itemp
  complex(KIND(0D0)), dimension(:,:), allocatable ::  mat,mattemp,eigen_vect
  double precision, dimension(:), allocatable :: eigen_vald, eigen_val, RWORK
  complex(KIND(0D0)),dimension(:),allocatable :: WORK
  integer, dimension(:), allocatable :: IWORK

!========================================================================
!
!Creating random matrix
!
 write(*,*) 'Taille de la matrice à diagonaliser (n):'
 read(*,*) n
 write(*,*) '========= Création de la matrice ============'
 write(*,*)

 allocate(mat(n,n),mattemp(n,n),eigen_val(n),eigen_vald(n))

 mat(:,:)=0
 CALL random_seed()
 do i=1,n
 do j=i,n
    CALL random_number(rtemp)
    CALL random_number(itemp)
    mat(i,j)=cmplx(rtemp,itemp)
    mat(j,i)=conjg(mat(i,j))
    if(i==j) then
    mat(i,i)=rtemp
    endif
 end do
 end do

!========================================================================
!
!Diagonalize with ZHEEV
!
 write(*,*)
 write(*,*) '======== Diagonalisation avec ZHEEV  ========'
 write(*,*)

 LWORK=max(1,2*n-1)

 allocate(WORK(LWORK),RWORK(3*n-2))
 mattemp(:,:)=mat(:,:)
 CALL ZHEEV( 'V', 'U', n, mattemp, n, eigen_val, WORK, LWORK, RWORK,INFO )
 deallocate(WORK,RWORK)
! write(*,*) eigen_val

!===================================================================
!
!Diagonalize with ZHEEVD
!
 write(*,*)
 write(*,*) '======== Diagonalisation avec ZHEEVD ========'
 write(*,*)

 mattemp(:,:)=mat(:,:)
 LWORK = 2*N + N*N
 LIWORK= 3   + 5*N
 LRWORK= 1   + 5*N + 2*N*N

 allocate(WORK(LWORK),RWORK(LRWORK),IWORK(LIWORK))
 CALL ZHEEVD( 'V', 'U', N, mattemp, n, eigen_vald, WORK, LWORK, RWORK,&
                        LRWORK, IWORK, LIWORK, INFO )
 deallocate(WORK,RWORK,IWORK)
! write(*,*) eigen_vald



!====================================================================
!
!Compare eigen_values
!
write(*,*)
write(*,*) '====== Comparaison des valeurs propres ======'
write(*,*)

ierr=0
zero=1.0d-6
do i=1,n

if (abs(eigen_val(i)-eigen_vald(i)).gt.zero)  then
 write(*,*) i , eigen_val(i) , eigen_vald(i)
 ierr=ierr+1
end if
end do
write(*,*) "Nombre d'erreurs: "
write(*,*) ierr


 END


thx
gabe
 
Posts: 3
Joined: Tue Aug 21, 2007 4:22 am
Location: Paris, France

Postby Julien Langou » Thu Aug 23, 2007 11:15 am

Hello,
for information I have run your code with
gfortran 4.3.0
GotoBLAS 1.10
LAPACK 3.1.0
on a dual Pentium III with
GOTO_NUM_THREADS = 1 or = 2
and both output are OK
Julien.
Julien Langou
 
Posts: 835
Joined: Thu Dec 09, 2004 12:32 pm
Location: Denver, CO, USA

Postby buttari » Thu Aug 23, 2007 11:34 am

Gabe,
I could reproduce the problem with GotoBLAS-1.17 but not with MKL-8.1. I'll have to spend some more time on this but this is not going to happen before next week.

Thanks

Alfredo
buttari
 
Posts: 51
Joined: Tue Jul 11, 2006 2:11 pm

Postby gabe » Tue Aug 28, 2007 3:40 am

Julien Langou wrote:Hello,
for information I have run your code with
gfortran 4.3.0
GotoBLAS 1.10
LAPACK 3.1.0
on a dual Pentium III with
GOTO_NUM_THREADS = 1 or = 2
and both output are OK


Did you try with large values of N?
I run the test on a another computer (AMD bi processor) and the error did not appears for N > 214 but for N > 2000.

thx
gabe
gabe
 
Posts: 3
Joined: Tue Aug 21, 2007 4:22 am
Location: Paris, France


Return to User Discussion

Who is online

Users browsing this forum: No registered users and 4 guests