[CPMD-list] Platform-dependent wave function optimization results

Tue May 1 17:29:04 CEST 2007

Dear Axel,

thank you for your comments!

> the simplest tests are swapping libraries, turning off compiler 
> optimization (-O0) and swapping compilers. the risk of miscompilation
> increases with higher optimization level.

I have checked two case with no optimization:
    1. cpmd compiled with IFC v. 8.0 and libatlas_p4.a (the bochum atlas binary)
    2. cpmd compiled with IFC v. 9.1 and MKL 8.1
No warnings. The results are identical. 

However that figures differ from the other case
    3. cpmd compiled with IFC v. 9.0 and MKL 8.0.1, -O3 optimization

For example, the output from the very first lanczos diagonalization step
in the 1st and 2nd case is
 <<1:4<<<<<<<<<<<<<< LANCZOS DIAGONALIZATION <<<<<<<<<<<<<<<<<<<<
 >> TIME FOR INITIAL SUBSPACE DIAGONALIZATION:              21.98
 >> CYCLE     NCONV        B2MAX        B2MIN     #HPSI      TIME
        1         0    3.367E-07    2.547E-11      6.00     77.39

in the 3rd case is
<<1:4<<<<<<<<<<<<<< LANCZOS DIAGONALIZATION <<<<<<<<<<<<<<<<<<<<
 >> TIME FOR INITIAL SUBSPACE DIAGONALIZATION:               0.61
 >> CYCLE     NCONV        B2MAX        B2MIN     #HPSI      TIME
        1         0    3.360E-07    2.475E-11      6.00      2.18

In the 3rd case WFO goes without warnings as well. 

Should I consider this difference in the output from the -O0 and -O3 binaries as an error?
Is it acceptable that the output changes slightly (on the round-off errors level) when the optimization level is increased?

> not a good sign. please note that the FEMD code is not thoroughly
> tested on linux compilers.
Please could you specify on which compilers the FEMD code was tested: xlf, PGI fortran ... ? 

Thank you.

Kind regards,
Vladimir

----- Original Message ----- 
From: "Axel Kohlmeyer" <akohlmey at cmm.chem.upenn.edu>
To: "Vladimir Stegailov" <stegailov at ihed.ras.ru>
Cc: <cpmd-list at cpmd.org>
Sent: Thursday, April 26, 2007 9:47 PM
Subject: Re: [CPMD-list] Platform-dependent wave function optimization results

> On Thu, 26 Apr 2007, Vladimir Stegailov wrote:
> 
> vladimir,
> 
> 
> VS> Dear colleagues,
> VS> 
> 
> VS> is it normal to get essentially different WFO processes on different
> VS> platforms using the same input script?
> 
> how different is different. there are some small differences
> possible, but within the accuracy of the method and parameters
> you should get the same results.
> 
> it is most likely, that you have a miscompiled binary
> or a library with errors or numerical instabilities.
> 
> VS> I use the 3.11 version and compare two platforms:
> VS> 1. cpmd compiled with IFC v. 8.0 and libatlas_p4.a 
> 
> intel fortran 8.0 had a lot of problems, particularly 
> the original release. you have to upgrade to the latest 
> patchlevel, best to the latest patchlevel of 8.1, which 
> works quite reliable. if this is the bochum atlas binary,
> please keep in mind, that it is now very old and has not
> been tested thoroughly tested against less frequently 
> used parts of cpmd. it should be easy to cross check
> against a different BLAS/LAPACK, e.g. mkl to see if 
> it the problem is in the compiler or the BLAS support.
> 
> VS> 2. cpmd compiled with IFC v. 9.0 and MKL 8.0.1
> 
> intel 9.0 in the original release was also very problematic,
> though not as bad as 8.0. but please make sure you upgraded 
> to the latest patchlevel.
> 
> VS> The input script is given below.
> 
> VS> In the 1st case the WFO process initially gives several "FRIESNER_C|
> VS> EIGENVECTOR 4 IS VERY BAD!" warnings, but eventually goes well and
> VS> stops at NFI=179.
> 
> not a good sign. please note that the FEMD code is not thoroughly
> tested on linux compilers. i would recommend a cross-check compiling
> everthing with -zero to make sure everthing is initialized. it appears
> that some parts of the code (still) rely on the fact that the compiler
> does this for you.
> 
> VS> In the 2nd case there are no warnings and WFO stops much quicker at NFI=44. 
> 
> VS> Is the reason just the difference in FFT libraries? Could it be
> VS> specific to the FEMD simulations?
> 
> there is no indication that you have a different FFT. but also different
> BLAS implementations can use (slightly) different algorithms and thus
> produce differences that may direct the wavefunction optimization into
> a different direction. since the FEMD code is used infrequently, there 
> is a much higher chance that some of it gets miscompiled. it can also
> be more sensitive to small differences in the libraries or compiler 
> optimizations.
> 
> the simplest tests are swapping libraries, turning off compiler 
> optimization (-O0) and swapping compilers. the risk of miscompilation
> increases with higher optimization level.
> 
> cheers,
>    axel.
> 
> VS> 
> VS> I would appreciate any comments!
> VS> 
> VS> Vladimir
> VS> 
> VS> 
> VS> &CPMD
> VS> 
> VS>     FILEPATH
> VS> 
> VS>       /home/stegailov/testing/cpmd/md3/
> VS> 
> VS>     OPTIMIZE WAVEFUNCTION
> VS> 
> VS>     UNIT HESSIAN
> VS> 
> VS>     BFGS
> VS> 
> VS>     FREE ENERGY FUNCTIONAL
> VS> 
> VS>     LANCZOS DIAGONALISATION 
> VS> 
> VS>     LANCZOS PARAMETERS
> VS> 
> VS>       1   6 10   1.D-18
> VS> 
> VS>     TROTTER FACTOR
> VS> 
> VS>       0.001
> VS> 
> VS>     BOGOLIUBOV CORRECTION OFF 
> VS> 
> VS>     GRAM-SCHMIDT ORTHOGONALISATION
> VS> 
> VS>     CONVERGENCE
> VS> 
> VS>       1.D-6  5.D-6
> VS> 
> VS>     MAXSTEP
> VS> 
> VS>       5000
> VS> 
> VS>     BROYDEN MIXING
> VS> 
> VS>       0.15 200   0.01  0   8
> VS> 
> VS>     ALEXANDER MIXING
> VS> 
> VS>       1.1 
> VS> 
> VS>     TEMPERATURE
> VS> 
> VS>       400.
> VS> 
> VS>     ELECTRON TEMPERATURE
> VS> 
> VS>       10000.
> VS> 
> VS>     COMPRESS WRITE32
> VS> 
> VS>     STRUCTURE BONDS
> VS> 
> VS>     ENERGYBANDS
> VS> 
> VS>     ELECTROSTATIC POTENTIAL
> VS> 
> VS>     RHOOUT
> VS> 
> VS>  &END
> VS> 
> VS>  
> VS> 
> VS>  &SYSTEM
> VS> 
> VS>    POINT GROUP
> VS> 
> VS>     AUTO
> VS> 
> VS>    SYMMETRY
> VS> 
> VS>     1
> VS> 
> VS>    CELL
> VS> 
> VS>     8.064    1.0    1.0   0.0 0.0 0.0   (8.064=2*4.032, 4.032A is the eq lattice const of Al)
> VS> 
> VS>    CUTOFF
> VS> 
> VS>     15.000
> VS> 
> VS>    ANGSTROMS
> VS> 
> VS>    STATES
> VS> 
> VS>     250
> VS> 
> VS>    SCALE
> VS> 
> VS>    TESR
> VS> 
> VS>      1
> VS> 
> VS>    KPOINTS MONKHORST-PACK FULL
> VS> 
> VS>    2  2  2   
> VS> 
> VS>  &END
> VS> 
> VS>  
> VS> 
> VS>  &ATOMS
> VS> 
> VS> *AL_SGS KLEINMAN-BYLANDER
> VS> 
> VS>    LMAX=D
> VS> 
> VS>    32
> VS> 
> VS> 0.0178998 -0.0197471 0.0145112
> VS> 
> VS> ...
> VS> 
> VS> 0.500011 0.750491 0.756745
> VS> 
> VS>  
> VS> 
> VS>  
> VS> 
> VS> VELOCITIES
> VS> 
> VS> 32 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
> VS> 
> VS> -5.10982 0.101812 -1.43574
> VS> 
> VS> ...
> VS> 
> VS> 7.04835 2.96887 2.84766
> VS> 
> VS> END VELOCITIES
> VS> 
> VS>  
> VS> 
> VS>   &END
> VS> 
> VS>  
> VS> 
> VS>  &BASIS
> VS> 
> VS>      PSEUDO AO 2
> VS> 
> VS>       0  1   
> VS> 
> VS>  &END
> VS> 
> VS>  
> VS> 
> VS>  &DFT
> VS> 
> VS>    NEWCODE
> VS> 
> VS>  &END
> VS> 
> VS>  
> VS> 
> VS>  
> VS> 
> 
> -- 
> =======================================================================
> Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
>   Center for Molecular Modeling   --   University of Pennsylvania
> Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
> tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
> =======================================================================
> If you make something idiot-proof, the universe creates a better idiot.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cpmd.org/pipermail/cpmd-list/attachments/20070501/95e2ebd9/attachment.html 