[CPMD-list] Problem with FFT_ESSL in CPMD353 on IBM p690

[Bernd Kallies]

Dear all,
I tried to compile/use CPMD 3.5.3 on an IBM p690 (Power4, AIX 5.1L,
xlf8.1). I linked with my own LAPACK_CCI and IBM's ESSL. The
preprocessor directives I used were -D__IBM -DESSL -DPARALLEL
-DMP_LIBRARY=__MPI -DFFT_ESSL. Compiler flags for mpxlf_r were -O3
-qstrict -qmaxmem=-1 -qxlf77=leadzero -qintsize=4 -qrealsize=4 -qdpc=e
-qarch=auto -qtune=auto

I ran into problems when gradients of the density have to be calculated.
Problems became clearly visible in geometry optimizations, when ZHEEV of
LAPACK was entered with a matrix that contained NaNQ only, which caused
crazy LANCZOS iterations with always the same results:
 ================================================================
 ==                     FORCES INITIALIZATION                  ==
 ================================================================
 EWALD SUM IN REAL SPACE OVER  9* 9* 9 CELLS

 << 1:10<<<<<<<<<<<< LANCZOS DIAGONALIZATION <<<<<<<<<<<<<<<<<<<<
 >> TIME FOR INITIAL SUBSPACE DIAGONALIZATION:               2.26
 >> CYCLE     NCONV        B2MAX        B2MIN     #HPSI      TIME
        1         0    0.000E+00    1.000E+30      8.00     19.53
        2         0    0.000E+00    1.000E+30      7.00     18.62
        3         0    0.000E+00    1.000E+30      7.00     17.99
... forever ...
Problems disappear when I replace -DFFT_ESSL by -DFFT_DEFAULT. 

As far as I figured out, the problems begin already after the first call
of INVFFT during the initialization of a run. An inspection of the in-
and output of the first call of MLTFFT from INVFFT showed that it seems
to return another and probably wrong FFT for the same input, when DCFT
from IBM's ESSL is used.

An example (ldax=81,lday=3281,n=80,m=3281,naux1=naux2=50000),
result B at the end of the first call of MLTFFT:

 i     j  B(i,j) with -DFFT_DEFAULT  B(i,j) with -DFFT_ESSL
         ( real        imag       ) ( real        imag       )
--------------------------------------------------------------
 ...
 473   1 (  .10164E+00  .70343E-17) (  .10164E+00  .70343E-17)
 473   2 ( -.10241E+00  .15902E-16) ( -.10241E+00 -.70343E-17)
 473   3 (  .10471E+00 -.16883E-16) (  .10471E+00  .70343E-17)
 473   4 ( -.10865E+00 -.19796E-17) ( -.10865E+00 -.70343E-17)
 473   5 (  .11441E+00 -.98143E-17) (  .11441E+00  .70343E-17)
 473   6 ( -.12201E+00 -.54733E-17) ( -.12201E+00 -.70343E-17)
 473   7 (  .13087E+00 -.13232E-16) (  .13087E+00  .70343E-17)
 473   8 ( -.13966E+00  .19261E-16) ( -.13966E+00 -.70343E-17)
 473   9 (  .14670E+00 -.22676E-17) (  .14670E+00  .70343E-17)
 473  10 ( -.15089E+00  .14765E-16) ( -.15089E+00 -.70343E-17)
 473  11 (  .15238E+00  .70343E-17) (  .15238E+00  .70343E-17)
 473  12 ( -.15239E+00  .12665E-16) ( -.15239E+00 -.70343E-17)
 ...
--------------------------------------------------------------

I'm not sure if this is caused by a bug in IBM's ESSL, or by a bug in
CPMD regarding use of IBM's ESSL. Since CPMD is copyrighted by IBM, I
believe the CPMD mailing list to be appropriate to post this problem to
both the CPMD team and IBM. I'd like to know if or when there will be a
fix available. An example CPMD input can be obtained from me on request,
if this helps. In the meantime we'll not use ESSL for FFT's in any
application.

Best regards, B. Kallies

-- 
Dr. Bernd Kallies
Konrad-Zuse-Zentrum für Informationstechnik Berlin
Takustr. 7
14195 Berlin
Germany
Tel: +49-30-84185-270
Fax: +49-30-84185-311
e-mail: kallies at zib.de